Unreal Engine 4 .NET Core integration
github.com
github.com
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.
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++.
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".
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.
Software developers in AAA are just putting the infrastructure in place, the real show is driven by others, so game development IDEs are tailored for those skillsets, not writing barebones C++ code.
You have a foundamental misunderstanding of what UE actually is.
The engine itself is really mostly a huge automatic templating system.
... unfortunately, DOTS is a) a dumpster fire and b) not going to hit 1.0 in 2020, or I guess, 2021 at this point.
The totally broken and unstable API and utter inability of the team to use their own package manager has left me with zero confidence in their ability to deliver a meaningful product with DOTS.
...but hey, .Net 5 will be great (of course, don't hold your breath for that either, "It is very unlikely that any .NET Core or .NET 5 support will land in 2020 LTS." https://forum.unity.com/threads/net-5-support.839890/), but I agree it'll be great when it does!
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.
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.
I haven't played with it yet, but I think Stride3d is an open source engine that's actually built on dotnet - I'd expect newer versions would land earlier and wider language support.
Tangentially, you can use C# 8 now, or even F# or VB in Unity if you choose to first compile them as a DLLs.
On one hand, a lot of things work surprisingly well. On the other, if you're going into it thinking you're going to get the same dotnet development experience in Unity - that's not the experience I've had.
It took me probably two solid years before I was making things in Unity that were any "good" (not dropping frames because of stupid stuff that Unity does like decoding textures on the render thread, not taking forever to load on startup, being able to cross-compile to different VR and AR systems without making massive changes to the application, etc.). After the third year, I had written workarounds for so many of Unity's built in stuff that I wish I had just started with my own game framework and skipped Unity completely.
Well, I guess that's not entirely true. I wouldn't have gotten my first well-paying, fulltime job VR without Unity. But from just a technology standpoint, it's been a major impediment.
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.
So if you want to use Unreal, consider just learning C++ as you go. That's my only point.