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.
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.
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.
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.
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.
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.
> I find the promises of Unity’s new Data Oriented Tech Stack
... 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!
The good news is they don't seem to be forcing everyone into a buggy paradigm. You can still use C# 7 and the monobehavior stack at least. ECS is overrated anyway. Just skip the hype, let it bake and ship games.
the real danger of Unity currently is that they seem to start a lot of things but not finish them. don't necessarily hitch your wagon to the idea that any particular thing they do will ever completely manifest itself or be feature complete.
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, ...
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.
"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.
Net 5 looks great, but it's unlikely to land in Unity any time soon. Unity runs on its own fork of mono, and if you're trying to build for mobile you'll need to use the il2cpp backend. Official support is for some versions of C#, not all of dotnet (eg, F# and VB are not supported).
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.
The IL2CPP backend removes the need for the mono fork and is available in all modern compile targets. The Rosyln compiler also ensures unity's c# is quite modern and features such as C# 8 are on their way!
Tangentially, you can use C# 8 now, or even F# or VB in Unity if you choose to first compile them as a DLLs.
I do use F# as compiled dlls, but like I said it is not supported. Only C# compiled IL is officially supported with il2cpp, and issues related to other languages are liable to be closed as won't fix. There also is no good NuGet story for Unity, which may catch a dotnet dev off guard.
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.
As a long-time .NET developer (since it was invented), getting into Unity (have been doing it professionally, full-time for the last 4 years) was a huge exercise in pain and suffering. They have their own ideas on how projects and their dependencies should be organized that don't align with the rest of the .NET ecosystem and, quite frankly, it's maddening.
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.
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.
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++.
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".
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.
It is an IDE, but whose main target are designers, artists, gameplay developers.
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.
31 comments
[ 1.7 ms ] story [ 65.6 ms ] threadThe engine itself is really mostly a huge automatic templating system.
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.
... 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!
https://garry.tv/unity-2020
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.
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.