Unity devs warned of breaking changes ahead in video game engine as team gets to grips with mutating face of .NET 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 survey late last year, but its use in Unity is somewhat messy. The C# scripting engine is based on Mono but …
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... ;)
We would have far preferred a C++ 3D engine. Bouncing data in and out of the managed framework is a pain and costs us performance.
However, Unreal licence terms are simply unacceptable for anyone selling physical appliances, and were unwilling to talk.
Rather sad, especially as Unreal now uses quite a bit of our open-sourced code...
Try ... Finally is not the same as RAII.
It's not as performant, and far harder to use.
You can't accidentally forget to call a destructor, but you can very easily forget something from the Finally
GCs do have their place though. There's a good argument for putting resource reclamation into its own special timeslice. Spreading memory reclamation and compaction over multiple frames instead of trying to do a whole lot in one go can certainly give benefits.
"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.
Yes, they do. Or are my friends who have been in the business 40 years, some whose work you and everyone else are still using, telling me lies?
Perhaps this very article has nothing to with bloat and it's just sour grapes? Yeah, that's it right? Because despite every single program in the world being affected by bloat, games are inviolate?
Now pull my other one.
Basically, I have a solution to that problem. https://meshpage.org/ has some gameapi builder tool which has nicely working user interface that doesn't slow down when plugins insert their code to key event handlers and thus it's not possible for a plugin to slow down the tool's key presses. :-)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
