Unity Future .NET Development Status

This somehow depressing to see JoshPeterson still try to be normal and convincingly productive while unity as a company are ruined beyond repaired. And no matter how great the product is, if the management are not disrupted, all of it will just regrettably crumbled

And I feel a bit scared when the last active reply was sent on Thursday

 

I've read quite some people have resigned in protest. I'm curious what was the atmosphere in the .net migration team / your team?

 

Yeah. I hate seeing management do this. Just wanted to let the team know that we understand none of this is their fault, and that if Unity ends up pulling though this disaster the scripting improvements are still some of the most important and exciting things going on at Unity. Hope you guys are doing well.

 

Sadly from the latest news in Bloomberg. It seem the management still not stop their path of company destruction. And so I think there is no future for unity as development ecosystem, even dotnet migration would happen tomorrow people are not stay to use it. 4% cap might just make people with current project may continued their work for a year and may release a game they nearly finished

I would suggest development team of unity, please take your work and leave to other company. There might be better future in another game engine. Unless all the board director and CEO will disappear from unity, which might be possible only if Microsoft just acquire whole unity company

Best regards

 

Since NativeAOT will be implemented in Dotnet8, I don't think a cross-compiler such as IL2CPP is technically needed..., right?
It seems that dynamic generation can also be done via an interpreter, although at a slower speed.

Godot hosts CoreCLR from C++, but GodotAsLibrary, which hosts C++ from CoreCLR, is also being considered.

However, I am not familiar with this area, so I am not sure.
I think there was a similar question before, but I forget where it is.

 

AFAIR iOS support will be official in .NET 8 and Android one is still "unofficial" (it is supported but less of a priority, however I guess that with a customer as big as Unity it'd quickly become proritized more).
Worth noting is the fact that the support for android is tracked as "linux-bionic", which is used to differentiate from the full android support Mono has, since the NativeAOT support lacks features like JNI interop (and doesn't have plans to implement them, at least yet).

The unofficial console ports are also starting to get some use now with games like this one being published while using them.

 

A limitation of NativeAOT is that you cannot use reflection. that has to be taken into account. And in a video where someone showed it using the example of a WebAPI, it was also said that in some cases NativeAOT can even be slower than JIT, but starts much faster and has smaller executable files.
The original goal is to reduce the start times of cloud applications/APIs that start on demand.

 

You absolutely can use reflection, you just can't use dynamic code or IL emit or assembly loading. It's the same restrictions as IL2CPP.

Well yeah, of course. JIT has more information to work with to optimize, but takes longer to start up. R2R (ready-to-run) is supposed to be a middle ground there, where it's pre-jitted for fast startup, but still allows for further JIT optimizations.

 

I googled for a moment and reflection is possible, but with limitations, and there is a no-reflection mode.

 

Thanks for this! Especially the improved delegate creation is quite interesting for us, our networking solution accepts a lot of delegates.

Perhaps i'm misunderstanding, but this still creates garbage for me, using Unity 2023.1.10f1.



What version of Unity did you test with this?

 

This optimization doesn't apply to instance methods, only static ones. It will also only be applied in release configuration, not debug.

You can see it in action by inspecting the output of this sample on SharpLab. If you change

OnDrawGizmosSelected

to

static

and compile in release mode, then the delegate allocation will be cached (but of course, that solution won't work for your real use-case because it must be an instance method for Unity to call it...)

(I should also mention that the language feature list is written with the expectation that UnityRoslynUpdater has been used to update the compiler bundled with Unity)

 

Actually the `OnDrawGizmosSelected` is emitted as static automatically. But not sure why the optimization didn't kick in for a method defined outside a class (top-level statements). You can use a lambda to workaround this, see https://sharplab.io/#v2:EYLgtghglgd...MUlZBWV1dL1YkgpqOobyJuLSiqVgACtdFyUyKgpaoA===

 

This won't actually work for the use case shown earlier, unfortunately. The SharpLab sample is written as a single-file program, so the methods end up becoming static. That's why the lambda example works. If you change the code to have everything explicitly within a class though, it no longer works.

 

After all this work has been done what is the overall benefits us developers get from it as i have no idea. I presume performance boosts..but are there other things ? This seems like a lot of work to do so i presume the reward is worth it some how...

 

I'm guessing they are also looking for replacing IL2CPP with NativeAOT at some point? Standard tool instead of a home-brew one.

 

Even if the performance gain from NativeAOT would be null, there is benefit in that it is maintained by Microsoft. It may also build significantly faster because it is more tightly integrated with .NET, VS, and MS Build tools… but that remains to be seen.

Plus, build speed doesn’t really mean much anymore after the SRP team dropped the ball there.

 

The blog post (https://blog.unity.com/technology/unity-and-net-whats-next) has been removed, please tell me this isn't a sign unity is abandoning another project?

It's also not on the roadmap? https://unity.com/roadmap/unity-platform/engineering

Edit: Blog is back. ( I was getting a 404 error )

 

Logically they cannot abandon something as crucial as this. Mono and its awful GC is holding back Unity Engine in the year 2014, and they absolutely have to switch to modern .NET if they want to survive and remain competitive with Godot and its modern .NET/C#, especially now with the new influx of funding and professional developers who will contribute to Godot (thanks to John). Heck there's even a .NET team member that stepped in a Godot/C# performance improvement proposal on GitHub and gave valuable input, which means that Microsoft/.NET team is watching closely Godot evolution. Godot is generally still behind Unity in 3D performance, but this won't last if Unity doesn't get rid of Mono quickly.

But since Unity Engine belongs to Unity Corp, nothing will surprise me anymore. If they foolishly miss this crucial upgrade, Unity will be really, really dead in few years.

 

Wdym dropped the ball?

 

Shader build times

 

Good to hear, is the plan still a 2023 release? From the blog:

"First, we’ll provide support of .NET CoreCLR for standalone players on desktop platforms. ... You will still access the .NET runtime through the .NET Standard 2.1 API, and we aim to release this new runtime during 2023."

 

Interesting, I don't remember the date getting mentioned the first time I read that blog post. My memory may have failed me. Anyway, It is said in the blog that the CoreCLR runtime might be available this year. How's the timeline looking now that 1+ year have passed?

 

I'd assume we won't get CoreCLR in Unity earlier than 2025-2026, seeing current progress and how Unity has always been late on their deadlines.

 

I believe that Godot has the option now to make any node multithreaded. This is pretty exciting performance wise!

The question of course is: do you have a team skilled enough to understand how to order their workloads to benefit from it? Lord knows how long Unity has spend making ECS a developer-friendly way for interacting with the dangerously unstable world that is multithreaded computation, hell I don’t even trust myself with anything more than single operations over shared workloads.

It’s a shame too. Really all performance improvements become paltry in the face of multithreading, you can boast 1.81x performance improvements for single operations all day, but versus literally an (n - 1)x speedboost where n = cores, what are we even talking about here?

 

The same .NET team member is also here in the Unity discussions

Unity and Godot are ultimately different engines and there will always be pros/cons with each and there will always be people interested in helping make one, the other, or both better. The competition is ultimately good, healthy, and will give customers options. It will help drive innovation and help make both products better.

Performance is ultimately hard and there are many things that can improve or reduce performance. There are many things that can cause pauses, stutters, etc. It [performance] is also not linear and simply throwing more cores or instructions that can process more at once doesn't solve the issue nor does it mean an equivalent increase.

----------------

Unity is not being left behind, it is not going to suddenly fall over and be abandoned, and most importantly the use of Mono vs .NET [Core] on the backend isn't going to decide the success of your game; it isn't even going to be the biggest factor of which engine to pick.

Ultimately, factors like the tooling and ecosystem provided are much bigger factors in choice of engine. Success of your game then depends more on how engaging people find it. Things like stutters/pauses/bugs can, of course, make a difference, but you should also consider exactly how many AAA titles ship with major bugs/issues/etc that are often overlooked because the game itself is fun. How frequently "bad graphics" don't matter to the largest consumer base. How many titles ship for portable systems and run at 30 fps but still rake in record sales, etc.

The point being that we could name drop all day on various best selling titles that have all kinds of wacky problems and perf issues, even on high end hardware. We can also name drop titles that have shipped using Unity, Unreal, Godot, and various in house engines. We can name drop indie titles that are better than AAA titles, that perform better and have less bugs, etc.

There are so many more important factors to consider and Unity is clearly working towards many different fronts, one of which is moving onto modern .NET.

 

I agree with the fact that tooling, ecosystem, community... are the most important factors for a choice of a game engine (for indie games at least). I also agree with the fact that a game success is due mainly to it being fun to play (and marketing ).

BUT...

For me as a developer, given two engines with nearly the same capabilities to make my game (we're indies after all, we don't need that much), with one being totally free, having no royalties, a better and modern C#/.NET, and a decent enough ecosystem/community, the choice is extremely evident.

At the current time, there's no engine that fulfill this. Unity, for me, is still the best option, even with the new imposed royalties (I don't mind giving back as a "thank you" to the people who made it possible for me to make my game). But if Unity doesn't step up their game, I'm pretty sure other game engines will catch up. Stepping up their game, for me, means (in order of importance):

1. No more catastrophic decisions like what they did recently
2. Modern .NET/C#
3. Back to roots: More focus on the gaming side of the company (99% of their user base)
4. Faster/more stable Editor

Can I make a game in Mono/C# 8? Yes of course. I've been a .NET developer since .NET Framework 1.1/C# 1.0 and I'm releasing my upcoming game with Mono (not even IL2CPP'ed).

But if I had a choice, do I prefer to use the latest .NET 8.0/C# 12 with all its awesome features, an excellent performance rivaling even C++ in some areas, and an integration with the industry standard .NET tooling? Absolutely YES. And this will soon be possible with other engines than Unity. Hope that Unity too will do this, and quickly enough.

 

The blog also mentions a new editor in 2024, but if the 2023 deadline is going to be missed by a year that might mean no editor update till 2025.. or longer? Thats a huge wait.

 

It's funny because for me one of the most important things is steadily becoming "working with open-sourced tooling". Unity's repeated layoffs haven't helped, but this last thing, even if I'll be working with Unity still for now, has also made me cautious of relying on conglomerate engines to build my game(s) on.

Unity is still a technical marvel, but it was the community that got me here. An open source community seems closer to what I need to enjoy and believe in my work. Something that we've asked of Unity for a long time now, and we can see why management wouldn't like that decision.

 

Any news on the upcoming blog post? I'm pretty impatient for news on this subject, and apparently the content has been ready for a few days.

 

Just a small clarification. Unity currently supports C# 9 with a few limitations: https://docs.unity3d.com/Manual/CSharpCompiler.html

 

You can use C#10 syntax sugar in Unity 2022 like global usings or record structs
very nice features

 

How does it work?

 

Unity support csc.rsp file to configure compilation like change warning levels add/remove default assembly references etc.
There you can change target language to 10

drop it into Assets folder or near asmdef and rename to csc.rsp to apply

 

There's nearly no hope with current management to open source the engine. They're still in the Ballmer area. They need a Nadella, but unlike Microsoft, they don't have the luxury of time to stay longer with their Ballmer (which is a lot worse than the Microsoft's version, which had some common sense and great contributions to Microsoft after all)

Anyway, let's go back to technical discussion to not pollute the thread.

 

You cant use them on an imported dll though, as that is restricted to net standard 2.1

 

On of ‘em has to be :’)

Sorry, low hanging fruit

 

Will all these changes break any of our current scripts or will it all work as normal ?

 

How does this work with IL2CPP?

 

Will Unity use .NET Core? If so, is it going to be version 7 or 8? Because I see .NET Core 8 can compile code into native code and the RAM usage as well as the build executable size will be extremely small. The .NET Microsoft guy named Nick demonstrate this really well in his YouTube channel. That's why I curious whether Unity will support this or not. Maybe it could be another alternative to Burst+IL2CPP.

Please add the option for the developers to choose .NET Core target version if Unity is willing to use .NET Core. Also, please add the ability for the solution to add another project (of course it is vcxproj) and manage the build order. I find it hard to use different solution just to compile C/C++ code into DLL and import it in Unity C# side. That's really painful when writing external C code and export the DLL, because I have to restart Unity whenever I do changes to the C projects.

Edit: Maybe I need to explain why ability to add a vcxproj is important. I usually do codes with GPGPU, using SYCL, CUDA, and OneAPI. GPGPU programming is somewhat I find really useful, and performant compared to Unity compute shaders, even though compute shader alone is quite fast. But advancements of external project and library are also undeniable.

 

It’s literally what this whole thread is about, Unity migrating over to .NET Core.

They are also making steps to replace assembly definition with csproj. I don’t know how vcxproj. fits into that tho

 

This could be easily circumvented by using

LoadLibrary()

and

GetProcAddress()

.