5 ms·

The uses cases for Unity haven't changed. While development has stagnated, It's still the best tool for many small teams wanting to avoid the pain of Unreal's C

The uses cases for Unity haven't changed. While development has stagnated, It's still the best tool for many small teams wanting to avoid the pain of Unreal's C++ or the downsides of Godot (less mature, non-standard scripting language, console support) The problem is that it's become a much riskier business decision. What if Unity just disappears, or is bought out by another company, or hikes up fees again? What if there's unfixed crash bugs in the big black box of that closed-source engine, bugs that may go unresolved for far longer since the mass redundances and could sink an entire project?

jncfhnb 2y ago
I’m curious about the C++ issues with Unreal. I am a hobbyist game dev. I did a couple years with Unity, learning C# on the fly; and a few years with Unreal more recently learning mostly blueprints but a decent chunk of C++ where needed. My day job is python based and I never really did OOP aside from AP computer science in Java a decade ago. I definitely have not felt like the language was a top of mind issue for either engine. Much more important is just the built in features that the engine has for things like movement and what not. I tend to assume that dedicated developers are more skilled than I am. So why do people care so much about cpp? Imo it’s just been a tiny bit of extra boilerplate and a sprinkling of macros.
- bluescrn 2y ago
  It's not as much the language itself as the build process and iteration time (although C++ enables nasty types of bugs that are mostly avoided in C# - memory leaks, heap corruption, etc) While I'm very new to UE but experienced with Unity, one of the first things I ran into with Unreal was the complexity of implementing a ComponentVisualiser in UE vs using OnDrawGizmos (or a custom inspector) in Unity. Drawing a couple of lines in editor mode involved dealing with build scripts to add an editor module to the project. While live coding/hot reload works for minor edits, some code chanfes require closing+reopening the editor. In Unity, it'd have been a few lines of code in an OnDrawGizmos function and no editor reloading or messing with build setup.
- tom_ 2y ago
  It's C++, which is rarely good. The language is large and complicated and you generally need to be extra careful when using it. There's a lot of features that interact with one another in surprising ways. UE5 does its best not to make things worse, but it's not always successful. (Are you certain you've tagged everything as UPROPERTY/UCLASS/USTRUCT that needs to be? Are you definitely always capturing your UObject pointers correctly? Are you definitely never using UObjects outside the game thread? Is your TSharedPtr structure acyclic? Are you certain they're all getting cleaned up? Have you tagged each one with the correct multithreading mode? Are you keeping an eye on FName creation? Etc., etc. - perhaps some of these are fixed now, this is just some stuff I've had to fix in the past that stuck in my mind.) C++ build times are often terrible and UE5 does not buck this trend. Editor startup and on-the-fly cooking can also adds to the iteration time. (If you're part of a larger team you'll also spend a lot of time waiting for Perforce and watching it compile shaders and recook. OK, so you can't lay the blame for this bit at C++'s feet, but if you're anything like me then this will give you additional time to spend thinking about how much the iteration time sucks.) The debugging experience is also subpar, because you pretty much always have to run an optimised build, which makes debugging tedious. Missing variables, wonky single stepping, inlined functions that are impossible to breakpoint, all the usual problems. It's no fun having to work with C++ code using the disassembly. Having an enormous pile of engine code to carry around also does not help when trying to get the game into a shippable state. Eliminating all the minor hitches and surprising crashes is a huge pain, simply because there's so many places they could be coming from, and even when it's obvious what the problem actually is, actually fixing it is another matter. The build times (which towards the end of the project are as bad as will ever be) really don't help; you'll be working largely with code you've never seen before, and the issue could be anywhere, so header changes aren't uncommon and spending time deep in thought while waiting for builds is not as helpful as it might be if working with your own stuff.
  - jncfhnb 2y ago
    I would be curious to know if you think what you’re saying is niche or not. Not arguing or doubting but it seems foreign against my experience. > Are you certain you've tagged everything as UPROPERTY/UCLASS/USTRUCT that needs to be? Pretty much everything seems to need this? > Are you definitely always capturing your UObject pointers correctly? Idk what this means > Are you definitely never using UObjects outside the game thread? Just… don’t? The engine is not safe for multi threaded operations on game state. Why would this come up? > Is your TSharedPtr structure acyclic? Idk what this means > Are you certain they're all getting cleaned up? Like garbage collected? I haven’t run into anything on that…? > Have you tagged each one with the correct multithreading mode? Why would you be doing significant multi threading?
- jarsin 2y ago
  Unreal was really designed to be blueprint first then only move the messy parts to C++. So if you are using it like that you won't hate the C++ side of things. I think a lot of ppl that come from Unity want to go all in on C++ and run into issue after issue after issue. Then end up hating the living hell out of it.
TillE 2y ago
> non-standard scripting language I agree with the other reasons, but Godot fully supports C# and C++; GDScript is something you can ignore entirely if you feel like it. Indeed, one good reason to use Godot over Unity is that you can write (and debug) your game using the latest .NET SDK.
- gopher_space 2y ago
  The non-standard scripting language is really easy to pick up and kind of fun.
- wokwokwok 2y ago
  Mm. I like godot, but c# is second class citizen in that ecosystem, which they are open about (1) and despite improving (2), it still a bit rough. “Fully supports”? I’d say more like “works mostly”. /shrug Gdscript is a weird stupid custom language. I feel like in most cases you shouldn’t write a new programming language for your application unless there’s no viable alternative. I know, unreal did it with blueprint, but that’s because there are no good open visual scripting languages; and they had a lot of existing infrastructure from their previous (also stupid, for the same reasons) unreal script. What they’re doing with verse is arguably also stupid, but I’ll give them the benefit of the doubt on the basis of a) having done it before, b) having unusual requirements for their metaverse ambitions. Anyway. Godot did have any good excuse; gdscript was not something people asked for or wanted; it was a lazy version of python because actually embedding python was too hard. Other options existed. …but, instead the time and effort went to building a new language. One thing you can look back at in Unitys history that is interesting is their aborted attempt to have js, c# and boo as scripting targets. …but over time, it became clear that having feature parity in all of them wasn’t plausible. I guess we’ll see where godot ends up, but my $0.02 is that as the api surface increases, feature parity is difficult to maintain, and gd supoort for other languages will wane with community interest. The only language they are committed to is gdscript. [1] - https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/index.html https://docs.godotengine.org/en/stable/tutorials/scripting/c... [2] - https://github.com/godotengine/godot-proposals/discussions/4007 https://github.com/godotengine/godot-proposals/discussions/4...
- d13 2y ago
patrick451 2y ago
I see the c# of unity as a major downside vs the c++ of Unreal. We have tried both for simulation engines and have had a much better time getting the performance we need out of Unreal than Unity.
- neonsunset 2y ago
  Keep in mind that it speaks more about Unity-specific behavior of C# rather than the way it performs outside of it, like in Stride3D or Godot. There is an absolutely massive performance rift between Unity's Mono and .NET 8's CoreCLR. Unity fixes this by using a subset of C# as DSL for its Burst compiler which is LLVM-based for specific hot paths, but it's something you don't need to do with "vanilla" .NET where all code has good codegen or offers really good SIMD API. Also if your application is bottlenecked by allocation and collection throughput, you might see even greater difference in performance.
moi2388 2y ago
You can write c# with unreal as well, there is a plug-in which works surprisingly well

jncfhnb 2y ago

I’m curious about the C++ issues with Unreal. I am a hobbyist game dev. I did a couple years with Unity, learning C# on the fly; and a few years with Unreal more recently learning mostly blueprints but a decent chunk of C++ where needed. My day job is python based and I never really did OOP aside from AP computer science in Java a decade ago. I definitely have not felt like the language was a top of mind issue for either engine. Much more important is just the built in features that the engine has for things like movement and what not. I tend to assume that dedicated developers are more skilled than I am. So why do people care so much about cpp? Imo it’s just been a tiny bit of extra boilerplate and a sprinkling of macros.

bluescrn 2y ago
It's not as much the language itself as the build process and iteration time (although C++ enables nasty types of bugs that are mostly avoided in C# - memory leaks, heap corruption, etc) While I'm very new to UE but experienced with Unity, one of the first things I ran into with Unreal was the complexity of implementing a ComponentVisualiser in UE vs using OnDrawGizmos (or a custom inspector) in Unity. Drawing a couple of lines in editor mode involved dealing with build scripts to add an editor module to the project. While live coding/hot reload works for minor edits, some code chanfes require closing+reopening the editor. In Unity, it'd have been a few lines of code in an OnDrawGizmos function and no editor reloading or messing with build setup.
tom_ 2y ago
It's C++, which is rarely good. The language is large and complicated and you generally need to be extra careful when using it. There's a lot of features that interact with one another in surprising ways. UE5 does its best not to make things worse, but it's not always successful. (Are you certain you've tagged everything as UPROPERTY/UCLASS/USTRUCT that needs to be? Are you definitely always capturing your UObject pointers correctly? Are you definitely never using UObjects outside the game thread? Is your TSharedPtr structure acyclic? Are you certain they're all getting cleaned up? Have you tagged each one with the correct multithreading mode? Are you keeping an eye on FName creation? Etc., etc. - perhaps some of these are fixed now, this is just some stuff I've had to fix in the past that stuck in my mind.) C++ build times are often terrible and UE5 does not buck this trend. Editor startup and on-the-fly cooking can also adds to the iteration time. (If you're part of a larger team you'll also spend a lot of time waiting for Perforce and watching it compile shaders and recook. OK, so you can't lay the blame for this bit at C++'s feet, but if you're anything like me then this will give you additional time to spend thinking about how much the iteration time sucks.) The debugging experience is also subpar, because you pretty much always have to run an optimised build, which makes debugging tedious. Missing variables, wonky single stepping, inlined functions that are impossible to breakpoint, all the usual problems. It's no fun having to work with C++ code using the disassembly. Having an enormous pile of engine code to carry around also does not help when trying to get the game into a shippable state. Eliminating all the minor hitches and surprising crashes is a huge pain, simply because there's so many places they could be coming from, and even when it's obvious what the problem actually is, actually fixing it is another matter. The build times (which towards the end of the project are as bad as will ever be) really don't help; you'll be working largely with code you've never seen before, and the issue could be anywhere, so header changes aren't uncommon and spending time deep in thought while waiting for builds is not as helpful as it might be if working with your own stuff.
- jncfhnb 2y ago
  I would be curious to know if you think what you’re saying is niche or not. Not arguing or doubting but it seems foreign against my experience. > Are you certain you've tagged everything as UPROPERTY/UCLASS/USTRUCT that needs to be? Pretty much everything seems to need this? > Are you definitely always capturing your UObject pointers correctly? Idk what this means > Are you definitely never using UObjects outside the game thread? Just… don’t? The engine is not safe for multi threaded operations on game state. Why would this come up? > Is your TSharedPtr structure acyclic? Idk what this means > Are you certain they're all getting cleaned up? Like garbage collected? I haven’t run into anything on that…? > Have you tagged each one with the correct multithreading mode? Why would you be doing significant multi threading?
jarsin 2y ago
Unreal was really designed to be blueprint first then only move the messy parts to C++. So if you are using it like that you won't hate the C++ side of things. I think a lot of ppl that come from Unity want to go all in on C++ and run into issue after issue after issue. Then end up hating the living hell out of it.

TillE 2y ago

> non-standard scripting language I agree with the other reasons, but Godot fully supports C# and C++; GDScript is something you can ignore entirely if you feel like it. Indeed, one good reason to use Godot over Unity is that you can write (and debug) your game using the latest .NET SDK.

gopher_space 2y ago
The non-standard scripting language is really easy to pick up and kind of fun.
wokwokwok 2y ago
Mm. I like godot, but c# is second class citizen in that ecosystem, which they are open about (1) and despite improving (2), it still a bit rough. “Fully supports”? I’d say more like “works mostly”. /shrug Gdscript is a weird stupid custom language. I feel like in most cases you shouldn’t write a new programming language for your application unless there’s no viable alternative. I know, unreal did it with blueprint, but that’s because there are no good open visual scripting languages; and they had a lot of existing infrastructure from their previous (also stupid, for the same reasons) unreal script. What they’re doing with verse is arguably also stupid, but I’ll give them the benefit of the doubt on the basis of a) having done it before, b) having unusual requirements for their metaverse ambitions. Anyway. Godot did have any good excuse; gdscript was not something people asked for or wanted; it was a lazy version of python because actually embedding python was too hard. Other options existed. …but, instead the time and effort went to building a new language. One thing you can look back at in Unitys history that is interesting is their aborted attempt to have js, c# and boo as scripting targets. …but over time, it became clear that having feature parity in all of them wasn’t plausible. I guess we’ll see where godot ends up, but my $0.02 is that as the api surface increases, feature parity is difficult to maintain, and gd supoort for other languages will wane with community interest. The only language they are committed to is gdscript. [1] - https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/index.html https://docs.godotengine.org/en/stable/tutorials/scripting/c... [2] - https://github.com/godotengine/godot-proposals/discussions/4007 https://github.com/godotengine/godot-proposals/discussions/4...
d13 2y ago

patrick451 2y ago

I see the c# of unity as a major downside vs the c++ of Unreal. We have tried both for simulation engines and have had a much better time getting the performance we need out of Unreal than Unity.

neonsunset 2y ago
Keep in mind that it speaks more about Unity-specific behavior of C# rather than the way it performs outside of it, like in Stride3D or Godot. There is an absolutely massive performance rift between Unity's Mono and .NET 8's CoreCLR. Unity fixes this by using a subset of C# as DSL for its Burst compiler which is LLVM-based for specific hot paths, but it's something you don't need to do with "vanilla" .NET where all code has good codegen or offers really good SIMD API. Also if your application is bottlenecked by allocation and collection throughput, you might see even greater difference in performance.

moi2388 2y ago

You can write c# with unreal as well, there is a plug-in which works surprisingly well