
Unreal Engine 4 .NET Core integration - Stevvo
https://github.com/nxrighthere/UnrealCLR
======
russellbeattie
Here's a warning: Unreal Engine is a haphazardly designed (at best) GUI bolted
onto a hardcore low-level game engine. It looks sort of like an IDE that you
could sit down and get comfortable with in a few hours, but it's just an
illusion. The whole UI is really just a thin graphical control layer over low-
level C++ objects for which there is little to no explanation. Instead, you
have menus within menus within menus...

Anyone trying to transition from standard Microsoft/Apple/Google developer
tools to UE is going to be in for a shock. The documentation is ludicrously
sparse, there's almost no "discoverability" in the UI, and even the sample
projects will have you staring at the screen asking yourself, "How the fuck
did they connect that to that?? Crap, did this thing hang again??". You'll end
up reading blog posts and watching YouTube videos filled with screenshots of
blueprints and step-by-step instructions for which switches to toggle and
which values to put where. After a few _weeks_ , you'll be completely
astounded that you still have almost no idea really of what's going on.

So! For anyone thinking, "Hey, I like games and know C#! Now I can make a
game!" Well, you probably should prepare yourself for disappointment.

~~~
dogma1138
I think you have had a severe misunderstanding of what the UE engine IDE is or
how to use it.

In any case for C# to easy game dev you have Unity which used C# as it’s base
language.

Almost all game engines are written as bunch of scripts being called from a
main loop so yes anything in UE regardless of what it is if it’s a graphical
element or some piece of logic that changes the world state will be a self
contained C++ “script” even the parts of UE that support higher level
scripting languages are still then compiled to C++.

~~~
russellbeattie
Yes. That was my point.

The warning was for others like myself who might blunder into UE thinking it
was an IDE, and not realizing it's really just "a bunch of scripts being
called from a main loop".

~~~
dogma1138
It is an IDE but it’s just might be different than what you used too, although
if you are used to visual component based IDEs like Visual Studio (not code)
or Visual Basic it won’t be that unfamiliar.

The whole point of blueprints is that the provide a visual interface to link
the underlying classes together in a fairly easy manner you can actually make
a game with using blueprints only now you’ll be limited in various ways from
not having the exact functionality you want in a given blueprint to having
performance issues if you are linking too many blueprints together to perform
a relatively simple action but they serve their purpose and that is to detach
much of the high level game/level design implementation from the low level
code implementation.

------
tootie
Pretty neat. As I'm reading, this basically lets you embed Unreal in a CLR and
play nicely with C# (and presumably F# and whatever else). That's going to be
very appealing for any Unity devs who have been thinking about switching over.

~~~
moron4hire
My reading was that it was the opposite direction: integrating the CLR into
Unreal.

~~~
cchance
Yes but same result Unity dev poaching

~~~
thatwasunusual
Probably, but mostly because a lot of people think that good graphics equals a
good game. The people who "convert" will learn the hard way.

------
_bxg1
Pretty exciting. I've tried to get into Unreal before due to its graphics
system, but gotten scared away by modern C++. This could seriously undercut
one of Unity's last major advantages.

~~~
keyle
Don't be... Unreal's C++ and libraries are so high level it's basically Baby#.

------
lwansbrough
As a .NET programmer who is new to the gaming space, I find the promises of
Unity’s new Data Oriented Tech Stack and the future of .NET (5.0) perhaps too
compelling to consider anything that isn’t officially supported. That future
just sounds too good to me as a back end .NET dev getting into gaming. I
think, too, as a beginner the dead simplicity of Unity’s old game object
system is very compelling for getting started if you’re brand new to
development. I haven’t spent any time with UE4 though so I can’t compare.

~~~
cpeterso
I haven't used Unity, but from what I've read, Unity has a reputation for
promising shiny new APIs and then neglecting/deprecating the old API before
the new one is production-ready. This blog post describes some examples: URP
or HDRP Render Pipeline, current UI system vs new UIElements, current UNet
multiplayer support vs new system that will require integration with DOTS, ...

[https://garry.tv/unity-2020](https://garry.tv/unity-2020)

~~~
chrisdirkis
I don't disagree with everything in the linked post, but some of the
commentary is just "make it better", which really feels like it needs more
nuance.

Render pipelines: URP and HDRP are the two Unity-supplied render pipelines,
but they're part of a broader Scriptable Render Pipeline project, which allows
Unity or other devs to write render pipelines that interface with the engine
in ways that non-core code couldn't previously. The "Standard"/old render
pipeline is the default now because most assets are built on it, but iirc
either soon or now you'll get the option to select the render pipeline when
making a project. "Just make swapping free/nondestructive" isn't really a
solution for swapping between arbitrary render pipelines, and not even
necessarily a solution for swapping between the two Unity supplied ones.

UI: Mostly agree. The layout systems should be better, the masking should be
better, the fonts should have been improved in the background as well as
buying TMP. Hopefully UIElements is a good solution. Tried to write a React
style renderer for UIElements once, but was stymied by the lack of duck typing
in C# (without dynamic, anyway).

Multiplayer: Totally a mess.

Demos: Agree that there's often too much reliance on beta features or engine
customisations. The SRP approach mentioned above alleviates some of that.
Disagree with "don't make rendered videos out of Unity", I work in ArchViz and
it's definitely a direction we're pursuing, due to cost and ease of iteration.
There's a very cool DOTS/networking example that Unity has been using
internally in Unite talks, and I'm waiting for that to come to stable, because
it has a really cool editor interaction story for DOTS, networking, remote
devices, etc.

DOTS: Lots of the iteration appears to be addressing the author's last point,
making the fast solution the simple solution. Transitioning to DOTS with a
cleaner API should also help future backwards compatibility, which is a pain
point the author identified earlier. Unity's current C# APIs are limited from
changing in many ways due to an attempt at backwards compatibility, but a
clean break allows you to have better architecture from the start.

I guess the TLDR is that I actually do agree with the author in many ways,
though I think they're also being unnecessarily harsh and acerbic in places.
Lots of things are in a transitionary state, and have been for the past two
years, and that's frustrating as a professional working in Unity. That said,
if you're building a game using the capabilities and systems in place now,
those won't fall out from under you unless you choose to try follow an upgrade
path.

~~~
Stevvo
"they're also being unnecessarily harsh and acerbic in places"

That's just Garry Newman's writing style. He is harsh and acerbic about
_everything_.

I don't see the constant changes as much of a problem, because if you have any
sense, once you start a project you are locked in to the engine version you
started on unless you want to cause yourself headaches. The same applies to
Unreal.

------
bonestormii_
And yet, aren't we nearly on to Unreal 5?

I'd much rather write C# than C++, but I'm a big believer in just adopting
whatever is standard practice for the space your in. It's a great opportunity
to learn the language, and you'll benefit more from a community's collective
wisdom.

Edit: But this is still really cool and potentially useful.

~~~
drak0n1c
Unreal Engine 5 won't arrive until late 2021. They're going to keep releasing
major features to UE4 until at least then. I'm sure there will be a migration
process for existing projects, as long as you're on a recent UE4 version.

~~~
bonestormii_
Right, but an integration of a dotnet like this is going to need to be
maintained across versions, and 2021 is just 6 months from now. It is unlikely
that a big version increment like this will be less than painful for such an
integration, while standard code bases of C++ code probably will have
relatively straight forward upgrade paths, though not necessarily trivial.

So if you want to use Unreal, consider just learning C++ as you go. That's my
only point.

------
yodon
Aside from this being LGPL, can someone explain how this differs from USharp?

