.Net 5 support

You mean the smooth migration to DOTS lol? Focusing on RyuJIT would have been a much faster and easier win for the entire community compared to that.

7 Likes

I’m gonna rephrase previous statement to get the point across: DOTS was created as a means to have something competitive against UE, which currently leads on every single field where Unity DOTS would be applicable (medium and big gamedev studios). On the other hand, very prevailing majority of Unity indie devs dont need DOTS and probably will never need (unless they grew into a bigger studio naturally and would want to use Unity for some reason for bigger projects), so for them, moving AND syncing scripting backend to .NET ecosystem would be way more beneficial and useful.
Unity tries to sit on both chairs here but it does not seems to be working well.

7 Likes

If I were Unity, I would start a clean branch. There is no such thing as a “smooth transition” on such a scale as this one. It will take decades if not more at this rate. Remember what happened to the DOTS fiasco, and it’s still ongoing. It would’ve been much “smoother” if DOTS had its own branch to avoid all kinds of regression bugs. And let people who really need DOTS opt-in. 90% of projects out there don’t need DOTS and Monobehaviour is the better choice for faster and easier development. Please don’t make the same mistake again.

My recommended plan of attack is to branch off .NET and let people play with it ASAP. I believe many will choose to migrate voluntarily and it’s all up to them. I believe the majority of the projects will just require recompilation or simple changes.

And at the same time, guide exiting users to prepare for the changes, i.e., making their project compatible for fast-enter-to-play mode and etc.

If you really want to help the migration easier, you can add optional Mono compatibility packages after .NET version releases. But then that depends on how much effort it requires vs benefits and you can worry about it after .NET releases. This will be the easiest path for Unity and let’s see how long it takes to get there. ^^

Cheers!

2 Likes

Forking a complex codebase like Unity’s is a monumental effort, even more so keeping both forks up to date, across the many versions they would have to maintain for a long time.
We might see some experimental builds to gather feedback at some point, but I wouldn’t expect an actual fork to ever happen at this scale.

That’s not to say I’m not interested in newer runtimes and wouldn’t jump straight out if I could. I definitely would.
I’ve been using alternative compilers for Unity to at least have newer C# features since Unity 4 or 5, and just finally stopped when they switched to their Bee system (which broke my entry point to replace the compiler). But, now we can have C# 9 and I’m satisfied with that.

For years now, the thing that hurts me the most is editor iteration performance. I’ve worked on some javascript games and having next to 0 iteration delay is absolutely incredible. Time just flows and I rarely procrastinate because of the delays. 5-10 seconds might not be much, but it adds up when you’re doing heavy iterative coding for 10+ hours straight.

Sadly, I don’t think even a full CORE editor would eliminate --or even significantly reduce-- iteration delays for everyone, as some (most?) of those delays would be coming from user code (but would be more than happy to be proven wrong!).
But, if we have the capacity to reload only relevant assemblies, we at least would not have to reload most packages and at maybe some of Unity’s internal assemblies (where about 80% of my iteration times comes from).
For example, IDE integration assemblies would almost never need to actually be reloaded.

All in all, I’m happy to see work being done on Editor iteration performance. Also very happy to see some communication too. For real, keep talking to us, please.
Hoping to see great progress in the future!

2 Likes

Thanks for the great discussion everyone! I appreciate the feedback.

I won’t be able to address everything here, but I’ll try to do my best.

Regarding DOTS and UPM, these are both outside of my team and experience, so I can’t speak too much to their past or future. Regarding future .NET work, I don’t expect any changes to them to happen or to impact the move to .NET 6 though.

Regarding the Unity Roadmap, we’re trying to do a better job of getting things on there as we have confidence when they will ship. That should include future .NET work. I’m still looking to start a forum thread which is kind of a “developer log” where we will try to post non-binding updates more frequently. There was a question about the internal hurdles to moving to CoreCLR/RyuJIT earlier in the thread. This is the kind of thing that I would to discuss on that thread. Hopefully we will be able to start it soon.

In general, I like to think of the .NET ecosystem on three vectors, hopefully this will help others understand where we are going. The three vectors are:

  • .NET base class libraries
  • .NET runtime
  • .NET reference profiles

The .NET base class libraries (BCL) provide the implementation of common types, like List, string, Dictionary, etc. Historically there have been three implementations:

There are five major .NET runtimes that I know of, each consists of a code generated engine and runtime code (GC, thread, file, socket access, etc.).

  • CLR - .NET Framework’s JIT runtime, I’m not sure what the code generation engine is called
  • CoreCLR - .NET Core’s JIT runtime, using RyuJIT for code generation
  • Mono - JIT and AOT runtime based on .NET Framework (and now .NET Core), using Mono’s JIT and AOT for code generation, as well as an IL interpreter used for Wasm
  • IL2CPP - Unity’s AOT runtime, based on Mono, using a transpiler from IL to C++ and then native C++ compilers for code generation
  • CoreRT - Microsoft’s experimental AOT runtime, based on CoreCLR, I’m not sure how code generation works here.

.NET reference profiles are an API surface without implementation used to compile C# code to IL code. The most important one here is .NET Standard, which is a “bridge” from .NET Framework BCL to .NET Core BCL.

  • .NET Standard 2.0 is supported by .NET Framework, .NET Core, Mono, and IL2CPP
  • .NET Standard 2.1 is supported by .NET Core, Mono, and soon Unity’s Mono and IL2CPP

The idea here is that any assembly compiled against .NET Standard 2.0 will work with .NET Framework or .NET Core BCLs.

Ok, so with that in mind, Unity’s plan is to first exposed .NET Standard 2.1 support, then .NET 6 support later, likely using Mono as a JIT solution and IL2CPP as an AOT solution. Then we plan to expose CoreCLR as a JIT solution, and possibly replace Mono.

I’ll have more to say about this in detail later as plans become clearer, but hopefully this gives some color.

35 Likes

They’ve actually been using RyuJIT for quite a while, per this 2013 post.

Thanks for clarifying that!

2 Likes

Also https://devblogs.microsoft.com/dotnet/the-ryujit-transition-is-complete/

I’ve opened the thread to provide .NET FW status updates: Unity Future .NET Development Status

14 Likes

I’m recalling now a thread somewhere here where one of the devs posted benchmarks of his monogame ported to CoreRt and getting 10x speedup on Switch. Stuff’s insane when it works.

1 Like

Okay, that’s understandable, and thanks very much for the rundown. The last part is the big one we kind of wanted to hear, even if it’s not set in stone. It lets us have a mental map of “Oh okay, so when they finish .NET Standard 2.1, then we’ll get more details on how .NET 6 is going to work out.”

Awesome.

As a response for those asking for a fork. Bear in mind that fork or not, the app domain reload issue has to solved before 95% of us can even start a new project on a new fork. Without the app domain reload thingy in order, only games compatible with the fast enter play mode would work, and I think only very very very few projects are actually compatible (I think it’s only pure DOTs based ones).
For example, in my project, the gRPC library I use is completely incompatible (has static state) and I can’t just fix/replace it.

1 Like

Which one it is?

The official .net gRPC library from nuget/github with an extra layer for protobuf-net (https://github.com/protobuf-net/protobuf-net.Grpc)

Question: Given that as Microsofts .net teams has recently put it; “over 50% of all games published, use Unity”; is Microsoft not interested in putting resources towards lifting Unity up to .net 6? To brag about game performance, drag over big studios, or even just get more marketing buzz statistics? “Unity is now .net 6 compatible! Look guys! Jump in, the water is great!”

3 Likes

That would show a glimmer of competence in Microsofts marketing team and that’s just not on-brand.

1 Like

This is simply not true. I can account first hand, that there are games currently in production at AAA studios which use DOTs almost entirely.

1 Like

DOTS is Unity’s Data Oriented Tech Stack not DOD

When I say DOTS I mean specifically the Unity packages in DOTS. I’m sure varying degrees of DOD happens in gameobject-Unity-land all the time (although these systems would have to be really isolated from the Unity Engine as gameobject’s and components aren’t
DOD-friendly).

I can confirm that specifically the JOBS system (w/BURST) and the Entities(/ECS) system are used. I can’t confirm about any of the other packages, as I haven’t personally worked on these teams.

You mean aren’t, I presume.

1 Like