Mono for Unreal Engine
mono-ue.github.io
mono-ue.github.io
Is C# becoming the lingua franca of modern game engines?
It's hard to emphasize how bad the Unity Mono GC is. It's a Mark-and-Sweep garbage collector, which is like the simplest-yet-least performant approach to GC there is. Nearly every other GC in production use in other stacks is better.
Additionally in C# 7, 7.1 and the upcoming 7.x series there are many improvements that reduce object allocation (like ref structs, value type tasks and others)
(This comes from the Unity team's explanation to the Unity community about why their runtime remains out of date. It's since become a meme to paint the Mono folks as a bunch of jerks over this. This endured for a few years. In the meantime, however, Microsoft has released .NET under permissive terms that would allow Unity to use Microsoft's own runtime royalty-free—no need for a commercial license exception. Despite the opportunity it presented, an upgraded runtime failed to materialize from Unity. Maybe the transition from Mono to .NET Core was too big of a leap? Fair point. Thing is, Mono itself is now also relicensed under MIT, by way of Microsoft's acquisition of Xamarin, so Unity is free to make commercial use of newer Mono versions on proprietary platforms, just like Unity always wanted. Still, no upgrade to the Unity runtime.)
it is marked as experimental for now, but their release notes say it will become the new default soon
I am evaluating 4.6 support now and it works okay so far for my VR Game
Xamarin and Unity never did a renewed licensing deal. That doesn't make the lovely xamarin people nor us jerks :)
Licensing issues aside, for an ecosystem like Unity to upgrade its runtime, c# language, and base class libraries is an enormous undertaking. While we are not perfect, we take backward compatibility very seriously. All of mono and coreclr has been available under MIT licensing for a very long time now. In Unity2017.1 we now ship an experimental option to use modern .net. this uses a new mono (not using sgen), new c# compiler (still mcs for now, so c#6, not c#7, and .net4.6 class libraries).
In a future unity version (won't burn my fingers on exactly which one) this new .net experience will become default. (depends on how many problems you find! :)
the xamarin (and microsoft .net) team are wonderful folks, and it's great to work closely with them to make .net in unity, and .net in general solid.
next up on the list is improving the garbage collection story, which is in the works, but we're first focussing on shipping a new runtime+c#+.net base class libraries.
While there are some very valid areas to point out that make c# challenging to be "the language of an entire game", we believe that c# is a great controlling language for Unity. We're working on some really interesting (imho) compilation pipeline for a restricted compute subset of c# that I think will completely turn around people's expectations and opinions of c# in gaming. stay tuned, this is one of the most interesting projects happnening inside of Unity today.
And they have given great feedback on the future of the language and framework that Microsoft is going to fully embrace to make Unity users happy.
Hugs and love Lucas!
Mono today has two code generators: Mono's built it one, and an LLVM one. Both generate code after Mono loads and processes the assembly.
Unity developed a different front end to the runtime that does the compilation from IL to C++, the result still requires the Mono runtime to provide services at execution time.
They are currently upgrading their Runtime and are making a version with all the greatest features available coming.
I am not up to date on the state of this in the latest Unity releases, I just know games I play on PS4 and OSX made with Unity stutter in places where they don't stutter on Windows.
As others have pointed out: the CLR has had a concurrent low-latency GC for a long time now and now that it's all open-source there is nothing preventing Unity from adopting it.
1. The GC provides a huge time-saving net over a ton of possible memory errors. Not to mention the code is so much easier to read when you aren't having to deal with memory on every line.
2. The debugging experience is brilliant - because there is always metadata available, you can literally inspect everything.
3. Compilation time is super fast.
4. Code samples are available for pretty much everything. And when there aren't, you can always interop into C++ or whatever else.
Cons:
People unfamiliar with the language forget about the GC and let it do all their dirty work. They then get angry when it bites back because of all the allocations they are doing each frame. The answer is to use pooling, and structure your code in a way that works with the GC (not against it), and all these problems go away.
Does the GC in Unreal-mono have the same problems? If not, it's a non-issue.
Invoking the GC constantly on a frame by frame basis can quickly lead to heap fragmentation, resulting in pausing, because that is considered 'working against' the GC (both stop the world and concurrent). This is where custom solutions, such as pooling, should be used to mitigate these issues.
I haven't noticed garbage collector related issues with mono, although I don't play the type of games where that would be most noticible. I have seen a number of games with memory leaks that require a restart after a while, but that is the case under windows as well. I've recently stopped buying Daedalic games because they can't manage to make a simple adventure game with almost no movement work on a system with 4GB memory, but they are by no means the only ones with this problem.
C# on top of C++ might not help that much other than encouraging more game designers to use C#.
GCC was for almost twenty years quite bad versus other commercial compilers, yet it is worshipped nowadays for its performance.
I dabbled with the Daydream Google VR NDK C++ sample app and did a demo app for myself of simple shapes moving around. While I could do simple things, I couldn't imagine doing the type of games others have done on the platform (or Oculus, or Vive) without Unity. For most people the question will be, why reinvent the wheel?
I don't know if C# will be the lingua franca of modern game engines, but for the foreseeable future, I think it will be the lingua franca of VR.
Valve's The Lab plumped for Unity because of the state of Unreal's forward renderer at the time but they wrote their own renderer. This was fair while back and both engines have moved on since then.
Who would be so stupid and learn-resistant to use C# a third time for games?? Well there are those sheeps, that believes and do everything for their PR department.
http://news.xbox.com/2016/03/14/letter-chris-charla-idxbox-u...
XNA was a victim of the usual internal wars between Windows Dev and DevTools R&D units, about which way to build software (.NET vs C++).
Hence why they are so supportive of Unity nowadays, which is the main way to develop HoloLens applications.
the reasoning behind it doesn't change the years of my life I spent learning an obsolete tech stack.
which is fine: tech moves on. Except for the fact that MS told me it was the future.
and I don't blame them, but I'm also not going to take them at face value again.
Aren't those core tenets of game production? :)
A mixed C/C++ callstack is so benign and common that it likely won't even register as being a "multi language" debugging experience. You get a single unified stack display, breakpoints, the works. There's a caveat or two around exceptions - that's about it. Everything just works.
C#/C++ isn't quite as solid, but it's still ahead of Python/C++ IME. Namely, Visual Studio will again show you a single unified callstack. There are more warts - again involving exceptions, as well as crash dumps and after the fact debugging. I've occasionally needed to break out WinDbg to deal with this.
Python/C++ is a bit harder. If you don't have a debug engine that can unify callstacks, however, there's still stuff you can do - dumping out both C++ and Python callstacks (and possibly locals) programmatically on assertions and in crash handlers, for example. I've done this for Java/C++, ActionScript/C++, Squirrel/C++, and probably more that I've forgotten.
"Own scripting language"/C++ is harder still: you must build your own everything. Debug engines are big projects - I haven't even completed my standalone one for brainfuck. If you dump your callstacks, you not only have to use the APIs that let you do so, but write them in the first place.
https://forums.unrealengine.com/showthread.php?2574-Why-C-fo...
- As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.
- As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or "interop" layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.
- Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.
- Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can't trace the C++ that code led to it, and vice-versa.
Unfortunately. It's a decent language, but it just seems a bit too heavy to use as a scripting language, but not as good as C++ for heavy lifting.
I'm doing some stuff on Godot, and will probably just end up using GDScript for basic stuff, and GDNative for more intensive stuff (It's a C/C++ API for shared libraries that you can load up through the editor).
> but it just seems a bit too heavy to use as a scripting language, but not as good as C or Pascal for heavy lifting.
Are two variations of that statement I have heard among games developers since I am in computing.
I went and looked up all the major game engines I could think of:
Blender: Python only
CryEngine: Lua and C#
Gamebryo: C++ only
Unity: C# and Java (Boo is no longer supported)
Unreal: C++ only (UnrealScript no longer supported)
Amazon Lumberyard: Lua (maybe C++ too?)
id Tech: C++
I was actually surprised at how common Lua was, but now that I think about it I have heard of it being used increasingly in games.
We are talking about the game scripting language, the game engine is always coded in C++ for triple-A games, with only a handful outliers. It's different for indies. We all know how the "Managed DirectX" and the incompatibile successor XNA turned out, the C# DirectX community is dead, end of life and last supported on the old XBox360, dead like Silverlight https://en.m.wikipedia.org/wiki/Microsoft_XNA .
http://news.xbox.com/2016/03/14/letter-chris-charla-idxbox-u...
But wouldn't expect that in under 3-5 years. Just an observer from the sidelines.
You can see an example of troubleshooting lock hitches using a 3rd party tool to get an idea of the complexity. https://www.youtube.com/watch?v=RE04LQffZfs
In both languages you have to be conscientious of types of allocations.
Building and using the tools to track down and break up circular references, dangling pointers, leaks, visualize memory fragmentation, etc. has eaten up a lot of my time.
I've considered attempting to write what would amount to a compacting GC in a C++ codebase to deal with memory fragmentation issues before - but retrofitting such a beast into an existing codebase was a huge enough undertaking, that we went for other simpler half measures instead. Being unable to control some middleware and system allocations meant any such GC would involve half measures and hacks as well anyways.
Whether that tradeoff is the one to make probably depends a lot on what kind of game you are making.
I recommend running the Roslyn Clr Heap Allocation Analyzer extension for VS for a few days - it helps to learn which language features and APIs implicitly allocate objects (or box value type objects).
Plus, modern GC implementations are super clever and efficient (as opposed to the implementation used by Unity, which unfortunately rather sucks, but I hear they're working on swapping it out).
If the game is relatively simple, and the heap relatively small, it's not a big problem. But if you're trying to make a large, complex simulation that's actually pushing boundaries, the GC becomes a constant adversary. People always talk about allocations, but not allocating during a frame is just the minimum price of admission. The real trouble is the static characteristics of the heap, like size and graph complexity. With manual alloc, at least the problem is straightforward: don't leak, and don't dangle. With a black-box GC, where you can't even hint to it about the lifetimes of objects, you have to be much, much more aware of memory management, then go through a lot of different non-idiomatic contortions regarding every single thing you put on the heap.
The majority of GC implementations out there are generations ahead of what Unity's GC is capable of.
The question: "Why is this interesting to me." Is entirely different and we cannot possibly start to answer that for you.
We can give you the executive summary though. This brings access to UE4 to people without c++ knowledge. You can compare it to any managed wrapper around an unmanaged library. Some will curse it, others love it.
They had serious reason to not provide any official scripting support in UE4. Basically there no single language and runtime that would work well across all platforms: between Python, Node.js, Mono none of them work on every platform Epic target. Some don't have good support for consoles and other for mobile platforms and maintaining fork is hard even for Epic. So instead they try to extend blueprints instead since for them there are no such problems with C++.