but one-time cost in terms of learning may be too much
If a slow startup of the editor the first time you start it is enough to end your career in game dev: you never had one.
And any good tutorial resource will do something like “Okay. Now start up that engine. Yes, do it now. Okay. It might look like it is unresponsive but that is because it is compiling shaders. Just leave that running and let’s start talking about some core concepts…”
If you’re going to use 5% of its features, having to go through the rest 95% when learning how to do things is a big distraction and productivity killer
It is a philosophical difference. But the reason I still suggest folk “learn with” UE is that it is, mostly, consistent between all the different kinds of games you may want to make. Which… is a leading cause of said performance issues when you start pushing things but more on that in…
Also, there is a surge of AAA games made in UE5 that have critical performance issues that developers struggle to fix for extended periods of time after release
Now. First and foremost: That means nothing for a hobbyist learning and making a game with their kids or spending a few hours a week for a few months until they give up.
As for the A-AA space (AAA means something, god damn it): That is not something that an individual developer is going to have any say in. That is going to be a corporate decision and it is almost exclusively going to be that company’s engine (ha, Frostbite) or Unreal because UE is the industry standard and there is a lot of value in being able to rapidly onboard a new hire or a contractor.
As for performance for those corporate games? That is really no concern for the hobbyist scale and is a much more complicated question related to allocating resources and time. But if there being poorly performant games made with an engine disqualified that engine: NO engines would exist.
Why though? Just use other engine and you’re good.
This gets back to the optimization side of things. You should not need to go through and migrate the critical path from gdscript to c# or even c++ just to test out your game. You want your development system to be significantly beefier than your target system so that you can rapidly iterate and debug. Get it working, profile it, and then optimize it. And… get a new respect for all the devs with “Unreal Engine games run like shit” games because you now realize that the optimization step might be months or even years of your life and you ain’t got time for that.
Other engines may or may not be more performant for debugging a specific “level” of fidelity. If you are at the point where your engine’s editor’s system requirements are limiting your ability to develop: You and your users are going to have a very bad time.
Arguing about UE5 feels just as bloated and convoluted as using the engine itself! Sorry, I couldn’t resist 😅
If a slow startup of the editor the first time
By “one-time learning cost” I meant that to learn how to do a thing in UE5 you will have to spend 95% of time learning things you won’t ever need to understand that 5% that you actually want. Yes, it’s also a one-time cost, but it’s not one-time cost most developers want to pay unless they really need all that compexity.
It is a philosophical difference.
It’s a personal productivity difference. If you are able to allocate N hours to make a game and you don’t need most of those features, you will be much more likely to finish that game in time in a simpler engine.
By “one-time learning cost” I meant that to learn how to do a thing in UE5 you will have to spend 95% of time learning things you won’t ever need to understand that 5% that you actually want.
That is learning anything that isn’t just “ChatGPT, how do I do X?”. Also, once you learn how to use blueprints you know how to do basically anything a hobbyist game dev would want.
Which is not dissimilar to Unity or Godot. You learn the basic concepts and then it is mostly a matter of experimenting or looking up how to do isometric camera angles or whatever.
But honestly? it sounds like you don’t want a game engine. You want a framework. In that case, RPG Maker is great for making a top down square style JRPG. Unreal is great for an FPS. And so forth.
Don’t underestimate what hobbyists want in their games. It’s actually AAA games that don’t want to risk and do fairly standard stuff while indies/hobbyists like to experiment and implement unorthodox mechanics and visuals. I think that, for example, writing your own 3rd person character controller (with stuff like snappy raw input movement, walljumps and also properly handling moving/rotating platforms) and cartoonish NPR rendering requires going through a lot more irrelevant systems in UE5 than doing the same in many other engines including Unity, Godot, and UPBGE. In Unity there actually is a similar kind of bloat (like URP), but it’s optional and you can just hack “good old” built-in render pipeline (also has tons of ready-to-use snippets and shaders open-sourced by community through years). In other words for me UE5 vs other engines is more like Java EE vs Python (or NodeJS) than Java EE vs Wordpress. UE5’s complexity is more of too many abstraction layers and lengthy workflows rather than being too low-level and flexible. Lightweight and flexible engines are great for hobbyists, game constructors are fine too for those who really want something very basic.
If a slow startup of the editor the first time you start it is enough to end your career in game dev: you never had one.
And any good tutorial resource will do something like “Okay. Now start up that engine. Yes, do it now. Okay. It might look like it is unresponsive but that is because it is compiling shaders. Just leave that running and let’s start talking about some core concepts…”
It is a philosophical difference. But the reason I still suggest folk “learn with” UE is that it is, mostly, consistent between all the different kinds of games you may want to make. Which… is a leading cause of said performance issues when you start pushing things but more on that in…
Now. First and foremost: That means nothing for a hobbyist learning and making a game with their kids or spending a few hours a week for a few months until they give up.
As for the A-AA space (AAA means something, god damn it): That is not something that an individual developer is going to have any say in. That is going to be a corporate decision and it is almost exclusively going to be that company’s engine (ha, Frostbite) or Unreal because UE is the industry standard and there is a lot of value in being able to rapidly onboard a new hire or a contractor.
As for performance for those corporate games? That is really no concern for the hobbyist scale and is a much more complicated question related to allocating resources and time. But if there being poorly performant games made with an engine disqualified that engine: NO engines would exist.
This gets back to the optimization side of things. You should not need to go through and migrate the critical path from gdscript to c# or even c++ just to test out your game. You want your development system to be significantly beefier than your target system so that you can rapidly iterate and debug. Get it working, profile it, and then optimize it. And… get a new respect for all the devs with “Unreal Engine games run like shit” games because you now realize that the optimization step might be months or even years of your life and you ain’t got time for that.
Other engines may or may not be more performant for debugging a specific “level” of fidelity. If you are at the point where your engine’s editor’s system requirements are limiting your ability to develop: You and your users are going to have a very bad time.
Arguing about UE5 feels just as bloated and convoluted as using the engine itself! Sorry, I couldn’t resist 😅
By “one-time learning cost” I meant that to learn how to do a thing in UE5 you will have to spend 95% of time learning things you won’t ever need to understand that 5% that you actually want. Yes, it’s also a one-time cost, but it’s not one-time cost most developers want to pay unless they really need all that compexity.
It’s a personal productivity difference. If you are able to allocate N hours to make a game and you don’t need most of those features, you will be much more likely to finish that game in time in a simpler engine.
That is learning anything that isn’t just “ChatGPT, how do I do X?”. Also, once you learn how to use blueprints you know how to do basically anything a hobbyist game dev would want.
Which is not dissimilar to Unity or Godot. You learn the basic concepts and then it is mostly a matter of experimenting or looking up how to do isometric camera angles or whatever.
But honestly? it sounds like you don’t want a game engine. You want a framework. In that case, RPG Maker is great for making a top down square style JRPG. Unreal is great for an FPS. And so forth.
Don’t underestimate what hobbyists want in their games. It’s actually AAA games that don’t want to risk and do fairly standard stuff while indies/hobbyists like to experiment and implement unorthodox mechanics and visuals. I think that, for example, writing your own 3rd person character controller (with stuff like snappy raw input movement, walljumps and also properly handling moving/rotating platforms) and cartoonish NPR rendering requires going through a lot more irrelevant systems in UE5 than doing the same in many other engines including Unity, Godot, and UPBGE. In Unity there actually is a similar kind of bloat (like URP), but it’s optional and you can just hack “good old” built-in render pipeline (also has tons of ready-to-use snippets and shaders open-sourced by community through years). In other words for me UE5 vs other engines is more like Java EE vs Python (or NodeJS) than Java EE vs Wordpress. UE5’s complexity is more of too many abstraction layers and lengthy workflows rather than being too low-level and flexible. Lightweight and flexible engines are great for hobbyists, game constructors are fine too for those who really want something very basic.