
Mono for Unreal Engine - markatkinson
https://mono-ue.github.io/
======
TazeTSchnitzel
C# is Unity's main programming language, now there's this for Unreal, and
Godot 3.0 will also have C# support.

Is C# becoming the lingua franca of modern game engines?

~~~
thehardsphere
I would certainly hope not. C# implementations are terrible for lots of games
on not-Windows. The version of Mono that has been included with Unity is
particularly bad with respect to stop-the-world garbage collection pauses.

~~~
nialo
Do you know if this is still true with the newer "concurrent" garbage
collector in more recent Mono versions? I work on an audio player app rather
than games, but also have problems with the GC in Mono on IOS. We're hopeful
that eventually they'll go away, but haven't tried again recently.

~~~
danbolt
I'm willing to bet that Mono GC has improved a lot, but I don't think that
Unity frequently updates the runtime. It's kind of painful, from what I've
been told.

~~~
migueldeicaza
We are collaborating with Unity to assist on upgrading not only their runtime
but also to adopt the latest and greatest GC.

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)

------
Nelkins
The lead for this project[1] recently gave a great talk[2] at .NET Fringe on
some of the interesting things coming up for Mono. Definitely worth a watch.

[1] [https://github.com/mhutch](https://github.com/mhutch)

[2] [https://www.youtube.com/watch?v=uxzS-
grpN4c](https://www.youtube.com/watch?v=uxzS-grpN4c)

------
0xFFC
A little bit unrelated, but serious question. Mono and .net core are not going
to converge? I mean that would be awesome. Since most of game developers
nagging about Mono's bad performance

~~~
tracker1
They're not strictly converging, but there is ever increasing code reuse where
it makes sense. Mono supports a lot more in the box than .Net Core currently
does. I could see a point where .Net Core covers as much as Mono does within
reason, and the rest of Mono eventually becomes separate packages in Nuget.

But wouldn't expect that in under 3-5 years. Just an observer from the
sidelines.

------
org3432
Would be interesting if the author could comment on the memory footprint and
performance of having an additional GC'ed language running alongside the
engine. It seems like it could lead to complex hitching issues.

~~~
Drakim
Wouldn't it be roughly like when games embed Lua?

~~~
org3432
I think the difference would be that UE is used more in AAA games that have
high performance requirements, which can be non-trival.

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](https://www.youtube.com/watch?v=RE04LQffZfs)

~~~
pmalynin
Crysis & CryEngine used LUA so I don't think the AAA argument makes sense.

~~~
org3432
UE didn't go that route as you'll notice though, that was one of the reasons
if I'm remembering correctly.

------
ivanbakel
A good thing. The C# bindings for Unity are great for scripting - the language
is surprisingly suited to lightweight logic. This should be a nice gift to
developers not yet familiar with C++.

~~~
garaetjjte
For 'lightweight logic' maybe, but using GCed language for almost all logic
executing every frame is bad idea.

~~~
apk-d
Just because it's GC'd doesn't mean it's constantly allocating memory.
Optimizing the most common heap allocation sources isn't very difficult
(especially compared to the nightmare of manual memory management).

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).

~~~
psyc
I wrote games and engines in C++ for 15 years, and Unity for about 5. I
strongly prefer manual mem management, hands down. Optimizing for Unity's GC,
in pathological situations, is the nightmare.

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.

~~~
pjmlp
Unity GC is a bad example, because it is widely known that their
implementation is pretty crappy, frozen in 2007 implementation.

The majority of GC implementations out there are generations ahead of what
Unity's GC is capable of.

------
Nelkins
Hmm...looks like the repo is not available?[1]

[1] [https://github.com/mono-ue/UnrealEngine](https://github.com/mono-
ue/UnrealEngine)

~~~
squeeeeeeeeeee
It's forked from EpicGames/UnrealEngine, you have to be logged in and have
access. [https://www.unrealengine.com/ue4-on-
github](https://www.unrealengine.com/ue4-on-github)

------
markatkinson
Been waiting a long while for this. Super keen to get stuck in. Huge thanks to
the whole team.

------
protomyth
Is there something wrong since it seems to be missing and a lot of the links
don't work?

~~~
paste0x78
You will need source access to Unreal Engine on GitHub to get access to the
MonoUE fork.

------
cantorRuth
Why is this interesting.?

~~~
Blaaguuu
Previously you could only write code for the Unreal Engine with C++ or the
visual scripting system, Blueprints. This allows people to use C# for
everything that they would normally need C++ to add to their games - which
will particularly help with people who are trying to transition from Unity to
Unreal.

~~~
Arwill
UE3 had UnrealScript, a VM based scripting language, similar to Java or C#. It
is odd, that Epic removed it in UE4, and now someone makes it as plugin.

~~~
SXX
There was one good podcast (that sadly not in English with) Nick Atamas
(senior engine programmer in Epic).

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++.

