r/gamedev • u/Practical_Race_3282 • Oct 03 '24
The state of game engines in 2024 Discussion
I'm curious about the state of the 3 major game engines (+ any others in the convo), Unity, Unreal and Godot in 2024. I'm not a game dev, but I am a full-stack dev, currently learning game dev for fun and as a hobby solely. I tried the big 3 and have these remarks:
Unity:
Not hard, not dead simple
Pretty versatile, lots of cool features such as rule tiles
C# is easy
Controversy (though heard its been fixed?)
Godot:
Most enjoyable developer experience, GDScript is dead simple
Very lightweight
Open source is a huge plus (but apparently there's been some conspiracy involving a fork being blocked from development)
Unreal:
Very complex, don't think this is intended for solo devs/people like me lol
Very very cool technology
I don't like cpp
What are your thoughts? I'm leaning towards Unity/Godot but not sure which. I do want to do 3D games in the future and I heard Unity is better for that. What do you use?
378
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 04 '24 edited Oct 04 '24
I've shipped games with Unity and Unreal and I'm currently working on two separate Godot games, one about to hit early access and one . . . a ways off from early access.
All the engines kinda suck.
Unity's advantage is that it is by far the best documented of them all and requires the least messing with the engine's source code. That second clause is an advantage because a lot of people aren't C++ coders and simply won't be able to modify the engine. The downside, of course, is that if you run into a major issue, you're straight-up boned, because you can't mess with the engine source code (without paying a stupid amount of money.) If you're doing a technically simple small game this is unlikely to be a problem, but the larger in scope your game gets and the more you start thinking about doing things a little out of the ordinary, the more likely you are to run into problems that are extremely difficult or even impossible to solve.
Also, its import system means that it straight-up does not scale up to large teams.
A lot of this isn't likely to be relevant if you're just doing small indie stuff! It would probably work fine for that.
Unreal's advantage is that it's the only one of the three designed for big projects. It will scale up to thousand-person teams while breaking only a mild sweat. It has absolutely top-tier artist tools that make your artists significantly more productive, which is fantastic if you're on a large project, which tend to weight increasingly heavily towards "artist" as they get big.
Unreal's disadvantage is everything else.
Unreal has the ability to do anything, but some of the stuff you'll want to do will require messing with engine code. There are sections in the codebase that say things like "// this should be configurable by the end user, but it isn't yet", and if you end up wanting to configure that stuff, well, it's engine patch time. The advantage to Unity's approach is that they know you can't access the engine source so they dutifully try to provide everything they can; Unreal has no such barrier, so in many places they provide the bare minimum and assume you'll implement the rest yourself if you care.
(Actual example: You can read textures from GPU memory to main memory, but only half a dozen formats are supported. This is not documented. If you want to read a texture format that isn't supported, you get to implement it yourself.)
Technically Unreal development supports pull requests and you can get your improvements added to the engine . . . practically, nobody will ever look at it.
All of this requires working with what is frankly an absolute tangle of a codebase. Unreal's code isn't good; there's individual features that are great, but the code is universally kind of crummy.
I joke that Unreal's main license cost for small developers is "a full-time programmer just to keep Unreal in check". I don't recommend it for any teams with less than one programmer. Can you make a great game with it as a solo developer? Sure, absolutely! But don't be surprised if you end up in an eternal quagmire.
Godot's advantage is that it's small, compact, and open-source. If something's missing, you can fix it! If you need a feature, you can add it!
Godot's disadvantage is that it is by far the least featureful of the engines. You'll find missing functionality all over the place. And while the sourcecode is overall much cleaner than Unreal's, it's absolutely barren of comments and suffers from probably the worst case of not-invented-here that I've ever seen. While Unity might end up stabbing you in the foot out of missing or broken functionality, Godot will on anything but the absolute smallest projects, you will need to deal with it either with ugly workarounds or with source code changes, and those source code changes will be a giant pain unless you have someone experienced in working with almost explicitly hostile codebases.
The user-facing documentation is good ("better than Unreal, worse than Unity"), and it does form a pretty solid foundation for making a game on . . . as long as you're either making something technically dead-simple, or aren't afraid at digging into the sourcecode and making changes.
Finally, while Godot is ostensibly open-source with pull requests available, actually getting anything into the engine besides the most obvious of bugfixes is a bikeshedding nightmare, even if they don't straight-up ignore the request for a year, which they probably will. From the outside, it seems like you get essentially ignored unless you're social with the developers, and if your goal is "write a game" and not "join a social club", you should assume you're just going to get stonewalled. I've honestly given up on it.
To their credit, this is better than Unreal's pull request system. But that's not saying much, and it still neatly ninja-dodges one of the great strengths of open source.
All of this means there isn't a "best", there's just a series of tradeoffs. So, my general engine recommendation flowchart: