Home Critical engine Unity game engine adopting .NET Core

Unity game engine adopting .NET Core

Unity game engine

Unity Technologies is migrating to .NET Core, a move that will bring modern .NET to Unity developers and also promises to improve technology for .NET developers in general.

In a post this week, the Unity software team mentioned it embarked on a “multi-year initiative…to migrate from the Mono .NET Runtime to CoreCLR, the modern .NET (Core) Runtime.”

The Unity game engine is used by more than 50% of games on mobile, PC and consoles according to to the company. The engine is written in native code but can be scripted using C#, forming a large community of C# developers. The version of .NET used in Unity, however, is based on .NET in its cross-platform mono form, rather than .NET Core.

Unity developers have complained about a lack of access to new C# features and performance improvements, as well as non-standard approaches in areas such as asynchronous coding and package management. Part of the problem lies with the Unity runtime API, rather than .NET itself, and the constraints it places on interop code.

That Unity has fallen behind in this way might seem odd, as the company has been a vital part in advancing .NET from Windows-only to cross-platform execution.

Unity was an early adopter of Mono, as without it the open source implementation of .NET would have progressed more slowly or might not have survived. This legacy, however, has become a burden. At GDC (Game Development Conference) 2022 earlier this year, VM Team Leader Josh Peterson explained how Unity was tightly tied to the Mono runtime, preventing migration to .NET Core CLR ( Common Language Runtime), and developed its own package manager and . asmdef package definition files and does not use MSBuild, the .NET build tool.

Even the Mono runtime is a fork of the official version. The consequence is that people who have learned .NET elsewhere find that in Unity they cannot use familiar tools or C# language features such as asynchronous and pending instructions for asynchronous coding.

Another big issue is that Mono has an integration API that doesn’t exist in .NET Core. The way it works is that the native Unity C++ application hosts the .NET runtime. In order to overcome this, Peterson said Unity is “implementing the Mono Integration API on the .NET Core CLR” and that work will be submitted to the .NET Open Source Project so that it is available to everyone.

The team had to solve tricky problems, he said, in the area of ​​native code interoperability, and wrote its own layer of marshalling to overcome issues like managed code objects that can get move to different memory locations and break native code that references those objects.

The intent is to bring Unity’s work on .NET to the general public. “We need to make sure we’re not building our own solutions…building on top of it, instead of branching off,” Peterson said.

The migration is already underway but complex. It starts with .NET CoreCLR support on desktop platforms, due in 2023, after which “we will port the Unity editor to .NET CoreCLR and remove runtime support .NET Mono at the same time,” the team said, with this new editor expected in 2024.

Unity’s move was welcomed by game developers, although there are still limitations. Asked if Unity will be decoupled from specific .NET versions, Peterson said in a post that “the .NET version will be tied to the Unity version just as it is today…it’s pretty tightly coupled to the .NET runtime”.

There will also be breaking changes for existing code, and the long migration time is another source of frustration.

That said, Unity remains important to the .NET ecosystem and feeding it more fully into the wider .NET ecosystem will be helpful for a project that in some ways remains dominated by Microsoft’s platform and has struggled. to attract a wider community of developers.