UE is a beast to run (and has incredibly shitty linux support if you want to use the marketplace or any plugins…). But basically everything you listed is a one time cost or just an indicator that you probably shouldn’t be developing medium fidelity 3d games on a potato.
Honestly? For “hobbyist” 3d games, Unity is still the king. Godot is awesome but a lot of the core loops and flows are very much geared with 2D first and the performance of 3D games is a hotly contested issue. I would still say that Godot’s 3D “performance” is better than Unreal’s 2D but… that is an incredibly low bar.
And in terms of workflows? UE is more than a bit convoluted but with stuff like blueprints it is probably the most consistent tool out there (so long as you never try to do a 2D game). Unity is a distant second. And Godot is great but it also reeks of an open source project that is being designed and redesigned in real time (just look at how file IDs are handled…). Not the end of the world if you understand the core concepts but also not something people are generally going to learn without a lot of trips to the forums (or watching youtubes of people who did said trips for them).
Maybe stuff like shaders compiling isn’t a big deal in the long run, but one-time cost in terms of learning may be too much. 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. 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, killing performance even on the most top-notch hardware that most gamers could never afford.
an indicator that you probably shouldn’t be developing medium fidelity 3d games on a potato
Why though? Just use other engine and you’re good.
For “hobbyist” 3d games, Unity is still the king.
I’m doing a hobbyist 3d game and I’m using UPBGE. It’s terrible in a lot of ways, depsgraph kills performance, but it’s very convenient to just hit P and play during 3d modelling of the scene. This is what I would call an engine for “hobbyist”. Unity is a decent engine for professionals, for indies, for AAA, for AA, for a lot of things. At least, technically it’s there. Its management is a big issue though.
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.
UE is a beast to run (and has incredibly shitty linux support if you want to use the marketplace or any plugins…). But basically everything you listed is a one time cost or just an indicator that you probably shouldn’t be developing medium fidelity 3d games on a potato.
Honestly? For “hobbyist” 3d games, Unity is still the king. Godot is awesome but a lot of the core loops and flows are very much geared with 2D first and the performance of 3D games is a hotly contested issue. I would still say that Godot’s 3D “performance” is better than Unreal’s 2D but… that is an incredibly low bar.
And in terms of workflows? UE is more than a bit convoluted but with stuff like blueprints it is probably the most consistent tool out there (so long as you never try to do a 2D game). Unity is a distant second. And Godot is great but it also reeks of an open source project that is being designed and redesigned in real time (just look at how file IDs are handled…). Not the end of the world if you understand the core concepts but also not something people are generally going to learn without a lot of trips to the forums (or watching youtubes of people who did said trips for them).
Maybe stuff like shaders compiling isn’t a big deal in the long run, but one-time cost in terms of learning may be too much. 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. 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, killing performance even on the most top-notch hardware that most gamers could never afford.
Why though? Just use other engine and you’re good.
I’m doing a hobbyist 3d game and I’m using UPBGE. It’s terrible in a lot of ways, depsgraph kills performance, but it’s very convenient to just hit P and play during 3d modelling of the scene. This is what I would call an engine for “hobbyist”. Unity is a decent engine for professionals, for indies, for AAA, for AA, for a lot of things. At least, technically it’s there. Its management is a big issue though.
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.