Unity devs warned of breaking changes ahead in video game engine as team gets to grips with mutating face of .NET
(2021/04/13)
- Reference: 1618319710
- News link: https://www.theregister.co.uk/2021/04/13/unity_devs_mull_future_of_dotnet/
- Source link:
Unity software developer Josh Peterson has spoken about the future of .NET support in the widely used game development engine.
Use in game development is one of the bright spots for C# popularity, according to a [1]survey late last year , but its use in Unity is somewhat messy.
[2]
The C# scripting engine is based on Mono but developers may also use .NET Framework when running on Windows. Mono is the old open-source implementation of .NET, from before Microsoft itself came out with .NET Core. Microsoft acquired the stewardship of Mono with Xamarin in 2016, and Mono now shares substantial code with .NET Core, but it remains distinct and the runtime is still used in some scenarios.
Unity maintains its own fork of Mono, which Peterson [3]said is "about two years behind the latest upstream code." The team is now updating this to the latest code from the upstream Mono repository, a change he is "95 per cent confident" will make it into the next release, Unity 2021.2. He added that this exercise will improve performance and fix bugs but in itself "won't have any new .NET features" – though it lays the ground for features to be added in future.
[4]
That said, Peterson does expect to add support for .NET Standard 2.1 in Unity 2021.2, but this time with only "75 per cent confidence." The .NET Standard versions define the set of APIs that a .NET implementation must support. A tricky aspect of .NET Standard 2.1 is that .NET Framework is stuck forever on .NET Standard 2.0. Peterson said: "Although .NET Framework does not support .NET Standard 2.1, Mono's class libraries do support it, so we should be able to provide a nice bridge to a .NET Core-based ecosystem."
The upgrade cannot come soon enough for some developers frustrated with the slow progress. "Are there any strides towards ditching Mono in favour of a complete .NET integration? Especially now when .NET is becoming so cross-platform," [5]asked a user in August last year. In-demand features include Span<T>, introduced in C# 7.2, and the Range operator, introduced in C# 8.0. Microsoft released C# 8.0 in September 2019, and getting the complete set of features into Unity has taken a long while. Users are also concerned that .NET performance in Unity has fallen behind.
Peterson said that C# 8.0 support will still be based on Mono in 2021.2. He also expressed hope that C# 9.0, released by Microsoft in November 2020, will be supported, but this depends on adding features to Mono and to IL2CPP (which converts .NET code to C++ for compilation), and for this his confidence descended to 50 per cent, he said.
As for that request to migrate to .NET Core, this is not likely soon. Peterson said that Unity will probably skip .NET 5 in favour of .NET 6, which is the forthcoming long-term support release. Even then, he said that "it looks like the JIT runtime here will be Mono" but he is uncertain and added that "we may need to move directly to CoreCLR for .NET 6 support."
One of the issues is that a feature of the Unity editor called domain reloading, which resets the scripting state, depends on a feature (AppDomains) that does not exist in .NET Core. Peterson said this could be implemented another way but "will be a breaking change." For game developers, .NET 6 will be a breaking change anyway since "any assemblies compiled against mscorlib.dll from the .NET Framework ecosystem will not work, and must be recompiled."
The complexity around .NET Standard, .NET Framework, .NET Core, and Mono is a challenge for Unity's developers, and shows that Microsoft's unification of .NET is in reality a process, not something that happened overnight with the release of .NET 5.0 last year.
"The only thing I'm interested in is the .NET 6 support. The biggest problem I had was slow Editor performance and long iteration time as project size grows. I currently ditched Unity because it was too painful to use and moved to Unreal right now," [6]said another user, adding that "Mono will be history soon and it has no future."
[7]
In a [8]separate post , Peterson emphasised that "everything discussed here is subject to change. Please do not consider discussions on this thread to be official announcements." Instead, he said that they offer "insight on our progress." ®
Get our [9]Tech Resources
[1] https://www.theregister.com/2020/10/21/developer_survey_c_losing_ground/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YHXAGCXe4xbWPDmEhRr6qAAAAJA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://forum.unity.com/threads/unity-future-net-development-status.1092205/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YHXAGCXe4xbWPDmEhRr6qAAAAJA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://forum.unity.com/threads/the-road-to-2021-q-a.950158/#post-6200213
[6] https://forum.unity.com/threads/unity-future-net-development-status.1092205/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YHXAGCXe4xbWPDmEhRr6qAAAAJA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://forum.unity.com/threads/unity-future-net-development-status.1092205/
[9] https://whitepapers.theregister.com/
Use in game development is one of the bright spots for C# popularity, according to a [1]survey late last year , but its use in Unity is somewhat messy.
[2]
The C# scripting engine is based on Mono but developers may also use .NET Framework when running on Windows. Mono is the old open-source implementation of .NET, from before Microsoft itself came out with .NET Core. Microsoft acquired the stewardship of Mono with Xamarin in 2016, and Mono now shares substantial code with .NET Core, but it remains distinct and the runtime is still used in some scenarios.
Unity maintains its own fork of Mono, which Peterson [3]said is "about two years behind the latest upstream code." The team is now updating this to the latest code from the upstream Mono repository, a change he is "95 per cent confident" will make it into the next release, Unity 2021.2. He added that this exercise will improve performance and fix bugs but in itself "won't have any new .NET features" – though it lays the ground for features to be added in future.
[4]
That said, Peterson does expect to add support for .NET Standard 2.1 in Unity 2021.2, but this time with only "75 per cent confidence." The .NET Standard versions define the set of APIs that a .NET implementation must support. A tricky aspect of .NET Standard 2.1 is that .NET Framework is stuck forever on .NET Standard 2.0. Peterson said: "Although .NET Framework does not support .NET Standard 2.1, Mono's class libraries do support it, so we should be able to provide a nice bridge to a .NET Core-based ecosystem."
The upgrade cannot come soon enough for some developers frustrated with the slow progress. "Are there any strides towards ditching Mono in favour of a complete .NET integration? Especially now when .NET is becoming so cross-platform," [5]asked a user in August last year. In-demand features include Span<T>, introduced in C# 7.2, and the Range operator, introduced in C# 8.0. Microsoft released C# 8.0 in September 2019, and getting the complete set of features into Unity has taken a long while. Users are also concerned that .NET performance in Unity has fallen behind.
Peterson said that C# 8.0 support will still be based on Mono in 2021.2. He also expressed hope that C# 9.0, released by Microsoft in November 2020, will be supported, but this depends on adding features to Mono and to IL2CPP (which converts .NET code to C++ for compilation), and for this his confidence descended to 50 per cent, he said.
As for that request to migrate to .NET Core, this is not likely soon. Peterson said that Unity will probably skip .NET 5 in favour of .NET 6, which is the forthcoming long-term support release. Even then, he said that "it looks like the JIT runtime here will be Mono" but he is uncertain and added that "we may need to move directly to CoreCLR for .NET 6 support."
One of the issues is that a feature of the Unity editor called domain reloading, which resets the scripting state, depends on a feature (AppDomains) that does not exist in .NET Core. Peterson said this could be implemented another way but "will be a breaking change." For game developers, .NET 6 will be a breaking change anyway since "any assemblies compiled against mscorlib.dll from the .NET Framework ecosystem will not work, and must be recompiled."
The complexity around .NET Standard, .NET Framework, .NET Core, and Mono is a challenge for Unity's developers, and shows that Microsoft's unification of .NET is in reality a process, not something that happened overnight with the release of .NET 5.0 last year.
"The only thing I'm interested in is the .NET 6 support. The biggest problem I had was slow Editor performance and long iteration time as project size grows. I currently ditched Unity because it was too painful to use and moved to Unreal right now," [6]said another user, adding that "Mono will be history soon and it has no future."
[7]
In a [8]separate post , Peterson emphasised that "everything discussed here is subject to change. Please do not consider discussions on this thread to be official announcements." Instead, he said that they offer "insight on our progress." ®
Get our [9]Tech Resources
[1] https://www.theregister.com/2020/10/21/developer_survey_c_losing_ground/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YHXAGCXe4xbWPDmEhRr6qAAAAJA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://forum.unity.com/threads/unity-future-net-development-status.1092205/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YHXAGCXe4xbWPDmEhRr6qAAAAJA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://forum.unity.com/threads/the-road-to-2021-q-a.950158/#post-6200213
[6] https://forum.unity.com/threads/unity-future-net-development-status.1092205/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YHXAGCXe4xbWPDmEhRr6qAAAAJA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://forum.unity.com/threads/unity-future-net-development-status.1092205/
[9] https://whitepapers.theregister.com/
J27
"Microsoft's unification of .NET is in reality a process, not something that happened overnight with the release of .NET 5.0 last year."
Sort of, not really, no. Microsoft's "unification" of .NET is more about adding features to .NET Core to make it suitable to replace .NET Framework, Mono or any other .NET runtime. There will not be a point where you can compile .NET Framework code in .NET 6 or 7 or 8 etc. Microsoft has made this clear. They're providing some tools to help you migrate, but it's a big task. Skills transfer very easily between .NET Framework and Core but when it comes to software you need to migrate a lot of things. For web applications MVC Core is very different from the older MVC, the entity framework versions are different (yes, you can use 6, but it doesn't interface with MVC Core so that's also an issue, although one that might be fixed at some point).
The TLDR is that it's not so much a unification is it is a replacement. This is a big change for Unity to support.
Oh No
MrMerrymaker
NOT UNITY
*balls of hay tumble by*
The .NET architecture, just like Java's JVM is a huge monolith that is hard to maintain. Pretty much my entire thesis on digital preservation stemmed on the fact that these large virtual machines are not a solution to portability in the long run.
I used to work for a Unity software house a while back (these days I actively reject any contract with the word Unity in it). When Emscripten (pluginless web support) came out Unity was so slow to adapt their sluggish .NET scripting layer that they were stuck with that it was actually worthwhile writing a tiny "clone" of the 4.x API (https://github.com/osen/mutiny). Unity supported Emscripten more than 2 years after UE4. As a company that relied on being an early adopter, Unity really was the worst choice.
People use C and C++ for a reason. And it honestly isn't for safety or "enjoyment". It is portability and lifespan. C *is* the computing platform. Unity's il2cpp and related technologies are a good start but again, is seemingly more complex than it should be.
Obviously this is a hard problem to solve because Unity's target prosumer market do not like the complexities of C++ RAII. And smaller more portable scripting layers like Lua just don't quite have the performance. Epic's UE4 garbage collected C++ is a good balance (Blueprint is not something I would consider personally but interpreted Cling would be a nice choice to cut down those Debug / iteration build times however).
Perhaps if Unity would open up the source, the community could chip in... ;)