.Net 5 support

For all these I think it raise more reason to fork unity for switching ecosystem and allow only new project to fresh start in the new ecosystem while don't need to care for existing project

Also for the argument about pre built assembly. I think it's opposite. It just extracting unitypackage in project's directory directly make everything completely a mess. And code conflict when there are many package try to use the same library

The actual problem is because UPM are too lacking. If UPM already just support git dependency or can registering their package to unity registry and be more mature, almost all packages can stop using prebuilt dll and release there library as code in git directly

Release code that need recompiling in package has more benefit to make version specific code too. And so it actually better to have raw code package

All in all those problem are the reason we should completely fresh start the new ecosystem in parallel. Unity can have Unity 2021 and Unity.net 2021. As I said I am totally fine as long as I can install both in unity hub

 

I would like to see a branch too for one year/generation. The only real issue here is the amount of retooling the editor is going to need is a lot of work and knowing Unity's track record I don't expect anything tangible until 2025+.

Also, Unity seems hell-bent on not porting over to the RyuJIT (.Core/5+) runtime. Unity can talk all they want to but it doesn't mean anything until it's in the roadmap, as their history shows. I agree that IL2CPP has its place but it's not a replacement for Mono. Unity doesn't really have a language feature-set issue, the existing C# 7-8 lang spec is more than versatile enough to handle what needs to be done when making a game (not saying that new features aren't nice).

Frankly speaking, the main thing keeping newer developers on Unity is C# because of ease of access and the simplicity from a managed runtime (memory, etc). C++ is the main issue the Unreal Engine is having in regards to getting indie teams and hobbyists to adopt it. And before you say it, there are plenty of issues with Unreal's editor workflow, etc., etc., but Unity has issues as well in the same vein so it's not really an argument. You learn the workflow of the tools you use.

The problem with the DOTS+IL2CPP replacement argument is while you may gain a slight performance advantage over the RyuJIT runtime, you lose a lot of the feature-set that makes C# attractive over C++'s development process, mainly in rapid development. Also, DOTS+IL2CPP, as a result of this, requires that you still make use of Mono's components/functions because many features are not supported in DOTS.

Also, something that Unity doesn't seem to consider is that ease-of-modding is really important for consumer-facing projects (ie. Steam games). A big example is Risk of Rain 2, the truth of the matter is that modding has added a massive amount of content to the game at no cost to the original developers. I'm not saying in an exploitative manner, modders want to do it voluntarily. Modding also extends the lifecycle of the game. Indie teams do not have a lot of money to work with so this is actually important a lot of the time. IL2CPP has actually put a giant wall in this regard because of an inability to inspect the MSIL.

Obviously, I'm not saying that Unity dev teams must cater to this, they can even explicitly stop modding attempts. The issue is that allowing this instead is not really an option for IL2CPP games without a lot of resources on the part of the developers to make it happen, which indie teams do not have a lot of.

And finally, if Unity switched over to RyuJIT, it would make supporting future changes/features to C# and the now unified .NET ecosystem much easier and faster.

Again, keep IL2CPP; Apple, Android, Console platforms, etc. all require it but, I would like to see RuyJIT or a similar vein on the Unity Roadmap. Even if it's far out, that's fine but, I don't trust Unity given their track record of reneging on things they say that aren't in the roadmap.

 

As a point of reference, creator of Tabletop Simulator here we have migrated the game over the years all the way back starting with Unity 4.3 in 2013 and we are currently on 2019 LTS (investigating moving to 2020 LTS). We have never migrated renderers (Marmoset Skyshop, but we also use the standard renderer for modding) or UI system (ngui, very early on we did use onGUI). The big system we have migrated away from was the old raknet networking and that has been replaced with a custom networking solution on top of steam p2p (not surprising with the state of Unity's networking solutions, we are also looking into Epic's online service for platform independence). Unless there is a clear benefit to a project you don't really touch it because a shiny new thing came out.

With that said, if I had to throw my hat in the ring .net 6 support is definitely our most requested improvement to Unity. From the benchmarks it has better performance than IL2CPP, without all the compatibility and build issues (we currently ship mono builds, yuck I know). Modern api and features, with hopefully better tracking of .net releases. Mono needs to be taken out back and put down for the betterment of us all lol.

 

Looks like Assembly Load Context can eliminate super long domain reload time after just change one line of code if the project supports fast enter play mode. Am I right?

 

Can someone write a simple blogpost about the aforementioned issues? Can be even a personal blog, does not matter much.

 

I just wanted to say, thank you for powering all of my social drinking activities during COVID.

Yes please! Like I've said before, Unity has made multiple broken promises. The only way the have some reassurance is an official posted statement from Unity Technologies (news/post/roadmap).

Also @JoshPeterson , I am curious as to what major issues or hurdles there are with porting over to RyuJIT (Core CLR JIT) from Mono? I actually genuinely want to know all of the pain and random non-sense that's involved in porting it over, things that we as product users would probably never be aware of otherwise.

 

Is this what you're looking for?
https://forum.unity.com/threads/net-5-support.839890/page-5#post-7021204

I actually have no idea, I know what JIT stands for but the rest is all gibberish to me :')

 

As we argue, I am more convinced that unity team put their effort in the wrong way

Smooth migration is not really what we need. There never been smooth migration without developer need to modified something along the development chain anyway. Instead the faster the release leds to earlier migration. No smooth migration can replace the time we lost for each day passed

 

That would be great for small creators, yes, but catastrophic for larger studios that have projects running over several years. Imagine if Unity's philosophy was such that every new major version would have you change your code: no deprecation or legacy support whatsoever. Unity wouldn't be an attractive solution for studios like e.g. Blizzard to create Hearthstone, which had an initially expected lifespan of 10 years.

Since Unity generates their income from these larger studios, we are all better off by their smooth integration policy. Because of it, larger studios keep coming, and small creators can enjoy the benefits of free Unity to learn, grow, and to create a career out of what was a hundred years ago a preposterous job proposition.

Regarding time loss, those studios are careful to monitor performance from the get-go anyway, so to them it is a welcome bonus, not a safety net.

 

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.

 

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.

 

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!

 

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!

 

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

 

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

 

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.

 

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.

 

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!"

 

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

 

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.

 

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.

 

thanks, edited.

 

I am trying to start the process of creating a video game. Does unity support .net5 yet and if so what version? I am also having a hard time getting my Photon Server up with the .net5 libraries. This has been a nightmare so far.

 

Unity does not support .NET 5.
Current supported API versions are .NET Standard 2.0 and NET Framework 4.7.1 (if I'm not missing).
.NET Standard 2.1 should land in Unity 2021.2.

Photon has packages specially for Unity. They are published in Assets Store (at least was published when I work with it last time). And as I remember there was no problem with setup

 

What would be the benefit of Net Framework 5.0?

Ran into an issue yesterday where my compiled version crashed every time when running the release version done in il2cpp but passed and worked fine when switching to mono using the 4.0.

Also is :https://forum.unity.com/threads/unity-future-net-development-status.1092205/ still a good link for the latest updates on 5.0?

 

Will there be anything new in terms of accessing Bluetooth devices in PC Environment? (PC/Linux/MAC)?

 

Better performance in almost all aspects since unity is still on a pretty outdated mono and in some cases not just better but huge.