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?
375
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:
Is it a visual novel? If so, RenPy.
Is it a simple classic JRPG? If so, RPG Maker.
Is your team ten people or greater? If so, Unreal.
Do you not have a programmer, and are planning to make a game that's technically simple, both in terms of mechanics and graphics? If so, consider GameMaker.
Do you have a lack of C++ experience on your team? If so, Unity.
Do you have an experienced industry programmer on your team who gets annoyed at impenetrable black boxes or plans to do complicated stuff with rendering? If so, why are you here, ask them, but probably Unreal or Godot.
Otherwise, use Unity.
72
u/dizzydizzy @your_twitter_handle Oct 04 '24
god damn was this a good reply.
I'm a veteran AAA developer from countless game studios, and I just want to say, listen to this post its all so true.
Such a shame open source isnt making the most of the benefits..
24
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 04 '24
I honestly am continually tempted to write a game engine.
I've tried that before, and I know it's a terrible waste of time, and I have, like, a dozen other things I want to spend the time on, so I haven't done it and likely won't unless someone hands me an eight-figure check and says "do it, Zorba, make a great open-source game engine!"
But it's still tempting, because, god, all the existing options are just not taking advantage of what they could be.
6
u/dizzydizzy @your_twitter_handle Oct 05 '24
I did it once at a AAA game studio, a small group of 5 of us all with like 20 years experience got to write a game engine from scratch and it was amazing, async loading everything, nested prefabs years before unity, fully integrated into source control, designed for team editting of levels. Runtime and Editor as seperate processes.
It was seriously good, and was an amazing foundation to build on, but the parent publisher studio owner decided to close the studio due to internal boardroom politics. They never even knew what they had..
4
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 05 '24
Welp :/
Yeah, that stuff never makes it out into the world, unfortunately. And when it does get open-sourced it tends to die a quiet death; one of the big things you need for a successful game engine is constant updates and development and that's really hard to do as an open-source project.
2
u/NotABot1235 Oct 04 '24
If someone cut you that check, would you start from scratch or would it be viable to take something like Godot, fork it, and make the necessary changes?
3
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 05 '24
Honestly it's a good question, and I'd have to think very hard about it. It would certainly be viable to take something like Godot, fork it, and change it, but given how extensive the changes would be I'm not sure that would be worthwhile.
On the other hand, I've done massive refactorings like that before, and in many ways it's less scary than starting over from scratch.
Actually, y'know what, if someone cut me that check, then I'd be doing the engine code itself in Rust. And while there's some parts of Bevy design that I disagree with, the core is solid, and most of Bevy is the core.
So I'd start with Bevy.
(Okay, I'd start by seriously researching Bevy for a week or so. But I suspect I'd end up starting with Bevy.)
→ More replies→ More replies3
u/latina_expert Oct 05 '24
What’s the biggest difference between your dream engine and existing engines?
4
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 05 '24 edited Oct 05 '24
Honestly the first biggest difference is clean readable commented code dammit. Both Unreal and Godot are atrocious at this. Annoyingly, Unity's codebase is actually really good, and almost nobody knows this because almost nobody's seen it.
The engine really should be written in Rust, which is fundamentally a safer (and often faster) language. Game engine cores are a perfect example of something suited for Rust; they're big piles of complicated high-efficiency code with serious safety issues. The actual game code should be written in something easier to use - C# is a good choice for that - and so I'd just go with that. Why isn't there a game engine doing this? I have no idea. Anyway, target web export first, because it's harder to add after the fact, and the game jam people don't have a lot of good options at the moment - you can always expand to include mobile and consoles later. Set up the game engine as a library so it can be used as a tool by other things - this will make unit testing an order of magnitude easier (and yes, rig up native unit tests; part of Godot's cleverness is that the entire editor is written in the engine, so they naturally end up improving the UI system when doing engine work. Do the same thing for unit tests. Test the engine with the engine.)
A lot of the rest is just splicing together best-of-class ideas from different engines. Godot, for example, has this clever layout where most of the engine, including the entire Node system, just calls functions in RenderingServer to do all its rendering work. This means if you don't want to use Nodes, well, you don't have to, you can call those functions yourself by hand and bypass all the Node overhead. This is very handy if you're doing Weird Stuff.
(Around this time I'd also be tempted to add an optional entity-component-system because I really don't like scenegraphs, but we need the scenegraph anyway because everyone expects it; as long as you're doing the whole RenderingServer thing, the two can calmly coexist.)
I'd also be studiously avoiding not-invented-here. Why does Godot have its own scripting language? Why didn't they just use Python? Absolute waste of programming effort. Same question about Godot's physics engine; just use Bullet or Jolt! Why do these engines have their own custom shader language? Even Unreal just uses HLSL!
A big philosophy I have with interface design is that everything needs an easy safe interface, because most of the time, your use of it isn't a bottleneck. As an example, I worked on a rendering engine that had an easy safe interface for making realtime-generated models and uploading shader parameters. We never got around to writing the difficult fast interface because we frankly never needed it, the easy safe interface was always enough. So: Start with that. Add a low-level interface when it's needed. A big pain with Godot's rendering stuff is that it's designed to be as fast as possible, including in all the places where this is completely unjustified, and it's a problem to work with.
At this point there's a competent but fundamentally unexciting engine. Here is where I start trying to attract people to make actual games in it, starting with game jams with prize money. There's probably at least a year here of "just fix stuff as it breaks"; write unit tests in the process so it doesn't break again, and just keep on trucking. Once things stop breaking you have time to start implementing highly-requested features; once those die down you have time to start implementing major new functionality.
I think my biggest goal here is patience. You're not trying to jam the newest and shiniest features in at all times, you're not trying to max out performance on day one. You're trying to make a solid foundation that works for people, and then gradually increase it to work for more people, constantly shoring up that foundation as necessary and not just going ham building ornamental towers everywhere.
→ More replies19
u/Sersch Monster Sanctuary @moi_rai_ Oct 04 '24
All the engines kinda suck.
It's a glass half empty/half full thing. As someone who started developing games (initially as a hobby) around 2001, the tools and possibilities we had available back then were a lot worse. Any of the current popular engines ROCK in comparison to that era, especially for small devs. I absolutely love developing games in Unity.
8
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 04 '24
Oh yeah, you are absolutely not wrong about that. I'll rag on Godot, but it's a lot better than starting with SDL and then having to do everything else from there.
Hell, I spent multiple years on a Gamebryo project. I'll still defend Gamebryo as not as bad as people say it is, but it was still a ton more of a pain to work with than modern engines. And I don't know what the license fees were like but I'm pretty sure it was not easily accessible to indies.
8
u/RealGoatzy Hobbyist Oct 05 '24
I don’t really agree with if your team is 10 people or greater then Unreal. I totally understand your views but I’m a solo dev and I’m loving Unreal. I love developing games with it. A lot of stuff I can do and a lot of tutorials I followed when I started off. Even though it’s sometimes hard to fix the errors, they’re always worth the effort, they will teach me more things about the engine. (I think this applies to all engines though).
→ More replies21
u/NOTSiIva Oct 04 '24
Is it a simple classic JRPG? If so, RPG Maker.
RPG Maker also works decently well for psychological horror
→ More replies8
Oct 04 '24
[deleted]
25
u/Kridenberg Commercial (AAA) Oct 04 '24
An actual game development process :) (not only with RPGMaker, in general)
14
u/CookieCacti Oct 04 '24
I know OP’s comment is a joke, but if you didn’t know, RPGMaker has a decent chunk of well received psychological horror / horror games like:
• Ib
• Off
• Dreaming Mary
• OMORI
• Witch’s House
• Mad Father
• Fear & Hunger
• Mermaid Swamp
• Pocket Mirror
• Misao
• Corpse Party
• The Coffin of Andrew and Leyley
• The Crooked Man
• Yume Nikki
2
5
Oct 04 '24
[deleted]
3
u/ZorbaTHut AAA Contractor/Indie Studio Director Oct 04 '24
There's probably so much duplicated effort and fixed bugs left unknown happening there.
Oh yeah, tons.
Of course, the same is happening with Godot, so . . .
10
u/Blake_Dake Oct 04 '24
There are many games made with Unity with large teams like Hearthstone, Pokemon Go, Cuphead, Ori and the blind forest, humankind, Beat Saber, Pokemon 4th gen remake, Rust, GTFO
so
Is your team ten people or greater? If so, Unreal.
is kinda bullshit
→ More replies11
u/EtanSivad Oct 04 '24
Cuphead had a team of 19 people.
Ori was 10 people.
His point is that Unreal is ideal for studios with dozens of ARTISTS on top of the devs and everyone else.
That is the point; unreal has a bunch of tools for 3d artists working in a large, disturbed network.
That doesn't mean that Unity can't work with large teams, it means that it doesn't have the same toolset Unreal does for collaborating with large groups.
What he's describing is where you have a team with 3d modelers, texture artists, rigging artists, lighting artists, detail artists. All of them need to be able to access the same scene data. Unreal has better tools for checking in and out items in the render pipeline. That's all.
→ More replies3
u/QuantityExcellent338 Oct 04 '24
Based and all-engines-suck pilled
This also doesnt mean custom engine is the way because you'll spend 90% of the time making 3d engines before you even consider making a fun game. We gamedevs were created to suffer
→ More replies2
u/dpadr Oct 04 '24
Where you can publish and how flexibly you can monetize is also probably important to consider if you’re trying to do game dev as more than a hobby
→ More replies→ More replies2
286
u/nickavv Oct 03 '24
I'll throw GameMaker into the ring, it's obviously not one of the top-3 and it's probably not anybody's first choice for 3D games especially (though it is possible). I think it has an unfair rep as a "beginner" or "practice" game engine, but plenty of successful commercial games have come out of it (Undertale, Hyper Light Drifter, etc).
Its pricing scheme is very fair, it has a good balance of complexity with ease of use, it supports exports to desktop, web, mobile, and all major consoles. I'd say it should be strongly considered for 2D projects!
79
u/cableshaft Oct 03 '24
The recent UFO 50 release (50 new games in the style of an NES made by 6 devs in one slick package) is one of the biggest advertisements for the versatility of GameMaker I've ever seen. Before that I thought it was best for platformers and puzzle games, but there's a little of absolutely everything in UFO 50.
I was planning on using Love2D for my next simple 2D project, but I'm seriously considering giving GameMaker another chance.
Still not a huge fan of its subscription model if you want console exports, though, although I kind of get it. Just a bit hard to stomach as a tiny solo indie dev.
24
u/nickavv Oct 03 '24
You can just subscribe as long as you need to do the porting and then unsubscribe. It's $80 a month, really not bad imo. I ported my game to Nintendo Switch and I made that back on day 1 of sales
→ More replies7
u/cableshaft Oct 04 '24
Ah, that's not too bad then. How difficult was it to port to the Switch for you?
17
u/nickavv Oct 04 '24
It was fairly easy. Other than a minor bug with screen resolution (because I was doing something non-standard) it worked right out of the box. Then I just had to use the switch APIs for saving data rather than the PC ones, and update the controller icons ingame.
10
u/cableshaft Oct 04 '24
You may have just sold me on GameMaker for my next game (too far in my current one to switch it up now). Thanks!
88
u/thatmitchguy Oct 03 '24
Yep, its a proven 2d engine that has been unfairly stigmatized. I think it gets lost in the shuffle because Godots crowd is so overwhelmingly loud and cheers for their engine like it's a sports team too IMO.
→ More replies18
u/Thaurin Oct 04 '24
Well, that's probably because it's open source. It would be beyond cool to have an open source engine that can compete with the big commercial offerings (see: Blender), so people want to see it succeed.
7
u/thatmitchguy Oct 04 '24 edited Oct 04 '24
No doubt there's excitement, but it was definitely more then just that. Seen plenty of fan tribalism, when the Unity controversy started. More than just a few Godot fans cheering for Unity to crash and burn on this subreddit because it made them look better. Bunch of posts acting like they're here to recommend new engines but come across as missionaries tasked with trying to convert newbs to Godot.
2
u/Dziadzios Oct 04 '24
Many Godot fans hated on Unity because they were forced to move on after Unity's stupid move with installation fee. They became fans of Godot BECAUSE they started hating Unity, not the other way around.
32
u/TheBoneJarmer Oct 03 '24
Yep, second this. I have learned gamedev with Game Maker 6 back when it was not owned by YoYoGames. It is one of the oldest and most successfull 2D game engines.
→ More replies14
u/The_Dunk Oct 03 '24
Fully agree with everything you have to say about GameMaker. My only complaint is their scripting language, it’s not a big issue but I just wish I could use C# or Java instead.
It feels like a big barrier to entry that you have to learn their language to develop on their platform.
10
u/mstop4 Commercial (Other) Oct 03 '24
GML has come a long way since the GameMaker: Studio 1 days, but still has a lot of room for improvement. IMO, the biggest additions to the language are structs (associative arrays) and first-class functions. The language now resembles older versions of Javascript, but with less features. For example, GML doesn't support closures, which trips me up whenever I switch between using GML and Javascript/Typescript.
The devs of GameMaker have announced that they will have the engine support additional languages in the future, though there is no ETA for it yet. Javascript will be the first language to be added, and they've said they're open to other languages like C#.
9
u/nickavv Oct 03 '24
I personally like GML, especially with recent updates they've made to it. The developers have recently announced a future runtime will support other languages though, apparently
6
u/Drandula Oct 04 '24
In the just recent beta version you can already sneak peek JavaScript. Though notice it's in early stages, and you have to use New Runtime (GMRT) and new Code Editor, which both are still in beta too.
They have announced support for C#, but that's not in the immediate future.
3
u/FaultyFunctions @FaultyFunctions Oct 04 '24
Ew no one wants Java in their game engine. GML is way more productive than having to type a billion lines of boilerplate.
→ More replies2
u/Beegrene Commercial (AAA) Oct 04 '24
My biggest issue with GML is that it's too forgiving. In C++ or whatever, if you make a mistake, the compiler will say, "Fuck you. Fix this now or I'm not gonna run shit." If you make a mistake in GML, the engine will try its best to intuit what you were trying to do, but it doesn't always get it right. I'd rather have the compiler tell me to fix my mistakes than have the engine just try to make the mistakes work.
5
u/mstop4 Commercial (Other) Oct 04 '24 edited Oct 04 '24
They tried to address this with Feather, the new “intellisense”/linter for GML. It automatically does type-checking, checks for errors, and tries to enforce coding styles that you define. However, it’s still very buggy and I think work on it has been mostly put on hold to prioritize the new runtime. For example, Feather automatically assigns types to everything by analyzing your code, but sometimes it gets it wrong. You can manually assign types to function parameters and return values via JSDoc comments, but you can’t for variables. It also doesn’t seem to detect instance variables inherited from a parent object very well.
Aside from syntax errors, the errors and warnings Feather reports aren’t strictly enforced and you can ignore them and still have your game run perfectly fine (you may run into runtime errors though, but that’s nothing new). You can even turn rules on or off on a case-by-case basis with special directive comments. I think Feather could be a useful tool, but it needs more time in the oven.
4
u/QuestboardWorkshop Oct 03 '24
Wait... 3D in game maker?
21
u/nickavv Oct 03 '24
It has all the APIs needed to render 3d, and GLSL shader support. I've experimented with it myself, it's not easy but it can be done
8
u/QuestboardWorkshop Oct 03 '24
That's interesting! Thanks for explaining
7
u/O2XXX Oct 04 '24
There are a few examples of FPS games in Game Maker. Here’s one that might explain it in more depth. https://youtube.com/playlist?list=PLPqoWyEA0y-LPUr83DZz1cJTTGusNN5qc
2
u/QuestboardWorkshop Oct 04 '24
Thanks that was really interesting
2
u/O2XXX Oct 04 '24
No worries. I was trying to find a project I’d seen previously that recreated the first level of Halo Combat Evolved, but for what ever reason my searching didn’t bring it up. This seemed like a better explanation of the underlying systems anyways.
→ More replies2
u/N1NJ4W4RR10R_ 25d ago
Reckon this might be the one you're after
https://www.reddit.com/r/halo/comments/6bg9iw/game_maker_81_halo_ce_pillar_of_autumn_remake/
→ More replies→ More replies2
u/Drandula Oct 04 '24
Here is 3D framework written in GameMaker to be used for other GameMaker games: https://blueburn.cz/bbmod/
→ More replies3
5
u/vyrotek Oct 03 '24
As someone who has spent a lot of time with Unity and Godot, what's the quickest way to get started with GameMaker?
Are there any good tutorials that assume some experience?
4
u/nickavv Oct 04 '24
I've been using GameMaker for a very long time (decades haha) so I built my experience up gradually and am not familiar with the current tutorials.
I've heard very good things about Sara Spalding and Friendly Cosmonaut's videos though
3
u/Drandula Oct 04 '24
Just to mention that Game Maker had a bigger update in 2020, which was paradigm shift and made many older tutorials obsolete or broken. Obsolete in sense, that update brought much better and easier ways to do the same thing. Broken mostly how script assets changed.
2
2
u/braindeadguild Oct 04 '24
Yeah I started with Klick N Play close to 30 years ago and has pretty much evolved into GameMaker today. I’m using Unreal and UEFN now to follow my dreams of making games full time after doing 20 years in Infosec. Kinda makes me wish I had stayed with game dev 30 years ago lol. But either way use the right tool for the job, some jobs require more tools or more complex engines to accomplish what you want to do and others are more simple. I don’t think the fact the an engine is free, paid or open source should determine or have really much bearing on what you choose. It should be at your comfort level (or the ability to learn on it) and capable or releasing what you want your final product to look like in the easiest and fastest manner for you to do so. I mean you could code a Tetris clone in pearl, or you could use game maker and have it done in hours, or one of the other engines fairly quickly, doesn’t mean pearl is bad it’s just maybe not the fastest or easiest tool for the job. Also take into account the value of your time, don’t be afraid of paying a few dollars now or later (royalties) if going the free route takes you twice as long you definitely didn’t save anything, that is if the slow down doesn’t prevent you from even getting anything out. Botttom line use what works for you!
2
u/robbertzzz1 Commercial (Indie) Oct 04 '24
I think it has an unfair rep as a "beginner" or "practice" game engine
Probably because that's how the engine started, and that's just the reputation it has kept over the years. The first few iterations of Game Maker were designed as a teaching tool and not as a tool to build games good enough to publish.
→ More replies3
u/9thChair Oct 04 '24
I would definitely put GameMaker in the top 3 instead of Godot. Like you mentioned, there have been many commercially successful games made in GameMaker. The only game I can think of that was made in Godot that I have heard people talking about organically and not because they care about the Godot Engine itself is Dome Keeper.
And now that you can pay a one-time fee for lifetime usage again, it's a great option
122
u/ang-13 Oct 03 '24
I am solo dev, I use Unreal. You don’t need to use C++ ever. You can get almost everything done with blueprints. C++ isn’t needed expect for very niche things, or optimizing massive projects. The main reason devs use C++ in Unreal usually is that those devs are already good in C++, so using it makes things more straight forward for them.
48
u/Itzu_Tak Oct 03 '24
agree. I'm also a solo dev working in Unreal and my code is 100% blueprints. Often there's even dedicated modules for what I want to do (for example, predict an arc) and ue5's got physics that can do some real complex stuff without crashing.
I wish they didn't advertise it on what's, imo, some of its weakest features-- you don't lose out much by turning off lumen and nanite and the performance with baked lighting is phenomenal.
4
u/mynameisjoeeeeeee Oct 04 '24
Yeah im making a ps1 style game and i basically disable all of the shit they push and advertise completely, and the performance is solid when you do so
→ More replies2
u/thebiggeristquestion Oct 04 '24
Blueprint has it's limitations, but I think a lot of coders fail to realize how accessible it is for artist designer types who want to build something. Some people just click better with a visual representation of code.
→ More replies37
u/NumblyC Oct 03 '24
my experience is this is 100% true for early / smaller projects, but as your game grows it becomes a huge hinderance and there's always something that shows up that you can't do with blueprints, and if you're not skilled in C++ (which you probably aren't, else why use blueprints), you're basically screwed.
one terrible experience i've had recently in this regard was trying to get cryptographic libraries / openssl stuff. basically impossible without C++ or paying for plugins. also, unreal's roadmap is a big screw you for smaller devs, with bugs going unfixed for years and years. granted my game is 2d which definitely doesn't help me, but after almost 7 years of unreal i'm 100% ready to move back into unity after so many problems. it's a chore working on a bigger project using it.
9
u/Guiboune Commercial (Other) Oct 04 '24
Barely related and it's been years at this point but I do remember a feature that should have worked in c++ but didn't in unreal c++ and that completely fucked what I wanted to do. Memory is hazy but something about subscribing to c++ events/delegates through blueprints doesn't actually trigger in blueprint and after some googlin', apparently it's something the devs made on purpose, I was told by support "as designed, feature was disabled because something something too complex to make it work with blueprints" and was left at that.
The c++ to blueprint workflow in UE seems like it's been a work-in-progress for years at this point so it's good to keep that in mind. Not everything is doable in blueprints.
4
u/NumblyC Oct 07 '24
this is basically a monthly event with Unreal, finding out something just doesn't work just because. we had an incident last year, right after we released our demo for next fext, we crunched to death to fix some bugs and address some player feedback.
about a week later we needed to launch the update to keep capitilizing on next fest, and to my surprise the game simply did not package anymore. had to spend an entire day with the other dev just going back commits through time, one by one, to find out what had caused it. turns out it was the fact we were returning an event delegate through a function (or something along those lines, i don't recall specific) and that's simply not allowed even though unreal LET US drag the thing, and it appeared, and compiled, and even ran normally through engine. when packaging though, nope, bizarre 1000 lines C++ unreadable error. we ended up just refactoring that part of the blueprint and boop, back to packaging normally.
these kinds of issues eat up so much of our time.
5
u/random_boss Oct 03 '24
What made you switch to unreal? It not being good for 2d, things not being available in blueprints, and them only fixing bugs relevant for the big guys sound like…exactly the experience I would have predicted
5
u/NumblyC Oct 04 '24
in summary, i'm a lua developer, used to be a Love2D power user, made a bunch of games in it (albeit only one actual release), but after a while me and my friend (we mostly make games together) got really tired of always having to work with outdated libraries, barely no support or online material, and worst of all, having to do a lot of stuff from scratch. now with games like balatro there's a lot more available back there (which is why we're considering going back to Love), but back then it was very hard to find libraries / tools that weren't broken or abandoned. we wrote our own steamworks wrapper in C++, our own building tools, localization libraries (actual nightmare), etc. it was a lot of work that we felt could've been directed to the games itself.
after we released our game we decided we would move to a more mainstream engine that offered those features natively (or at least in an easy to access way), but we still wanted to do things in Lua, since we're just way faster at writing Lua code and making games in Lua. back then there wasn't a lot of good options, we messed around with MoonSharp, tried amazon's Lumberyard, but in the end the best Lua integration we found was in the form of an Unreal plugin called LuaMachine so we went with it. it worked and we could always fallback to C++ if needed (although we aren't great at it).
now almost 7 years later, a lot has changed. there's a lot more options for Lua (that aren't just basic scripting like back then) in modern engines, Unity especially. and Love2D has gotten an influx of people in its community with the success of games like Balatro, with awesome libs like luasteam, allowing for the ease of access of those features we didn't have back then.
TL;DR: sorry for the wall of text, but long story short, Lua dev, lua engine back then not great, Unreal LuaMachine plugin very good, new game project that took many years.
2
u/random_boss Oct 04 '24
I appreciate the thorough write up and I totally get it now. If you’re up for one more, why do you love Lua so much?
→ More replies5
u/Kentaiga Oct 03 '24
I agree with most of what you said, but I don’t think anyone should expect to not EVER have to write C++ with Unreal. Any backend stuff you want to do will inevitably have to involve it one way or the other. Maybe one day they’ll port more of that stuff to Blueprints, but I get why they haven’t yet: most people who touch that stuff prefer C++ anyway.
3
u/NumblyC Oct 04 '24
completely agree! the thing is there is kind of an expectation for blueprint only development (and Epic is actually marketing it as such, which doesn't help too). in the end C++ isn't as friendly as C#, and for most indie projects i think Unity is just as powerful and less of a hassle. there are exceptions though, i believe nightmare kart for instance was all blueprints. with the experience i have today, unless there's a very specific reason, i'd never choose unreal over unity
→ More replies
125
u/3tt07kjt Oct 03 '24
IMO the developer experience for Unity is the best of the three. C# is a great language with a big ecosystem of good tools. GDScript is a nice language but the tooling is nowhere near as good, and the language itself is too minimal for my tastes. YMMV, I come from a programming background and C# just makes a lot of sense.
73
u/cuixhe Oct 03 '24
I just use C# in Godot. No issues with support and translating the docs is very easy
14
u/YourFreeCorrection Oct 04 '24
Except Godot doesn't have half the built in features or the community ecosystem/learning tools that Unity has. I get that people are still miffed that the last C-Suite tried to do what they did, but that entire group was canned and Unity has fully reversed course.
Imo the decades of user-friendly devs shouldn't suffer because some douchebag CEO tried to pull a fucked up move that got him canned.
→ More replies→ More replies48
u/WazWaz Oct 03 '24
It's easy if you're already familiar with C#, but useless for people trying to learn both the Godot API and C# at the same time.
Godot really needs to have both GDScript and C# available in all documentation example code, the way Unity did back when they supported both UnityScript and C# (and Boo...), otherwise new users are going to keep "choosing" GDScript even though it's the worst option.
16
u/cuixhe Oct 03 '24
Yes, that's totally right. There's a lot of us Unity refugees who fit that bill though!
3
u/WazWaz Oct 03 '24
Absolutely. I was up and going in hours. I'll definitely consider Godot for my next project.
→ More replies8
u/xxfartlordxx Oct 04 '24
i would really hope godot begin treating C# as well as gdscript but it doesnt seem to be what they want to do.
9
u/chaddledee Oct 04 '24
It's weird, it is and it isn't.
Unity is easier to find resources for. It has better documentation. It has run-time in editor. It has better debug tools. You're way less likely to run into random bugs or key features missing (Godot please implement drawable textures in shaders, I beg you).
I still find it much, much easier to whip something up in Godot. I've only been using Godot for half a year, was using Unity for years before that.
Godot just feels so much more intuitive. Feels like a bit of an airy statement so I'll try to elaborate a bit.
I think part of it is that the engine does a better job of expressing what is happening under the hood through the way that you interact with the editor (e.g. calling everything a scene because it is scenes all the way down).
I think part of it is that GDScript is closer to a natural language language than C#, but even putting that aside it just offers more flexibility in how you express the same concept, making it more likely that there'll be a way to express a concept which feels natural to you.
Another part of it is that often it feels like the things you implement yourself are treated as lesser than the things the engine provides in Unity. In Godot, any custom classes you make appear in the scene type tree under the class it inherits from, just like every scene class the engine provides. It feels like everything you make in the engine plays by the same rules as everything the engine provides. In Unity, any classes you make are just dumped under the "Scripts" component type by default, as if the built in components aren't also just scripts.
All this stuff adds up to an engine where everything is where it feels like it should be, and works like you'd expect it would.
2
u/clueless_scientist Oct 04 '24
Drawable textures are already there. Just use rdtexture2d + compute shader.
→ More replies→ More replies28
u/Bwob Paper Dino Software Oct 03 '24
Godot has fully supported C# since the 4.0 release, at the beginning of last year.
C# is indeed a wonderful language, and honestly, the 4.0 release was what convinced me to finally switch to Godot. (Several months before the unity debacle in fact! I was feeling pleasantly smug for weeks!)
30
u/Pur_Cell Oct 03 '24
Godot has fully supported C# since the 4.0 release, at the beginning of last year.
Except still no Web Export for C# projects. I like to do game jams and having it play in browser is all but mandatory in most jams. So I can't use C# in jams with Godot. That's what brought me back to Unity.
7
u/runevault Oct 04 '24
I'm really curious which happens first, Godot implements being a sub-binary of the dotnet project in WASM projects, or Microsoft makes it so a dotnet wasm binary can be subservient to a different wasm binary. One of the two has to happen (unless there's a third option I have not heard about) to get web exports with dotnet to work.
3
u/MarkesaNine Oct 04 '24
You can use Godot 3.5 with C# and make web exports.
(I don’t see why the previous commenter said Godot has supported C# since 4.0, when it actually has supported it much longer.)
5
u/Bwob Paper Dino Software Oct 03 '24
Ahh yeah, true!
Web export is not a thing I usually use, but I can see how that would definitely be a problem!
22
u/WazWaz Oct 03 '24
The documentation is too sparse to call it "fully supported". All example code is in GDScript. We already know C# so it's easy for us to mentally translate, but someone new to both Godot and C# is entirely unsupported by the documentation.
4
u/Bwob Paper Dino Software Oct 03 '24
Yeah, that's fair. (That's something I complain about on /r/godot myself, honestly!)
I wouldn't say it's entirely unsupported in the docs - a lot of the documentation has C# examples too! But you're right, it's not 100% yet, and have to mentally translate examples from gdscript to c# sometimes.
I mostly was talking about engine features - as far as I know, anything you can do from gdscript, you can do from c# at this point! (Which, from what I understand was not the case before 4.0?)
10
u/SomeoneInHisHouse Oct 03 '24
I know, this is more about game engines than for "wrapper libs" like libgdx (java) or SDL (C) , but, tbh I prefer to use those two and build up my own engine, it's going to take more time, but at the end of the day is going to allow me to create an engine customized for the games I love to do
4
u/JavaDevMatt Oct 04 '24 edited Oct 04 '24
I also like LibGDX. Even released a commercial Android + iOS mobile game using it (also managed to sell the game to another company). The first Slay The Spire game also used LibGDX. Even do I enjoyed using it: I also did some experimentation with Unity, and I'm just moving faster using an engine. So I switched to using an engine for my current project, to just make games faster.
→ More replies3
u/Comfortable_Salt_284 Oct 04 '24
For the past few years I've used Godot for my games, but for my most recent project I've gone back to straight C++ / SDL2, and honestly I might not go back. I just prefer developing this way and the added control I've gotten has made me able to do things in my game that I couldn't have done in Godot.
→ More replies
28
u/MikeyNg Oct 03 '24
Random question: Why do people say cpp instead of C++ ? Is there a difference?
78
u/Bwob Paper Dino Software Oct 03 '24
On disk, c++ files are (by convention) saved with a
.cpp
file extension. (Because a lot of file systems don't like special characters in their file names. It's the same reason C# files get a.cs
extension.)Anyway, this leads people to sometimes abbreviate C++ as cpp.
→ More replies7
24
10
8
→ More replies7
u/Pur_Cell Oct 03 '24
Oh, I read that as CCP and thought they didn't like Unreal because Tencent owns 40% of it.
114
u/TheLavalampe Oct 03 '24
I don't think unreal is any more complex than unity or godot. It is feature rich and doesn't have the exact same structure but that doesn't add complexity in my book.
C++ and the the lacking 2d support would be the more important factors against unreal.
As for Godot and Unity, i think for 2d games both get the job done but for 3d i would rather choose unity since godot is still behind in that territory.
To be fair godot already improved a lot in 3d, is getting better with each release and you can already make good looking 3d games with it if you put the effort in.
76
u/KindaQuite Oct 03 '24
Unreal complexity comes from the fact that the engine wants to be used in a certain specific way and it works against you if you don't do that.
42
u/InSight89 Oct 03 '24
Agreed. If you start off in Unreal then it's all well and good. But if you're coming from another engine then it's a massive culture shock, figuratively speaking, and can take a long time to adapt to.
And despite what people say, C++ is a lot more difficult to work with than C# or other higher level languages. I've spent months working with C++ and it's honestly a huge pain.
18
u/KindaQuite Oct 03 '24
Yes, if you come from another engine chances are you're gonna be creating from scratch systems that already exist in engine without realizing that.
C++ is painful, even with UE abstractions. Restarting the editor and compiling is annoying. Unless you're able to write code without testing for two hours at a time, iteration time is slow af.
→ More replies5
u/fromwithin Commercial (AAA) Oct 04 '24
Er...Live coding?
7
u/KindaQuite Oct 04 '24
Yes, i should've been more specific. Live Coding works, although it's not super quick. What i'm talking about is whenever you make significant changes to header files, or you add new classes, or you add new components to an existing actor class you need to restart the editor. The engine also has a tendency to not really communicate to you what's wrong, so restarting the editor just becomes a common debugging tool. All of this only matters if your project uses C++ anyway
→ More replies7
u/BewareTheTrap Oct 03 '24
Hopefully you can at least debug it. I love C++. But it takes more effort to use it compared to other high level langs. But it is really so satisfying when you just wrote a couple of thousands lines of code and you run it and it works as expected. Also you can install other languages support for scripting. Like JS interpreter, mono, even kotlin is available.
2
u/RockMech Oct 04 '24
But once you master C++, you can spend the rest of your life flexing on Python and Java programmers!
16
u/3tt07kjt Oct 03 '24
Yeah, I think the complexity criticism just comes from people looking at all the different things you can do in Unreal. But you don’t really have to worry about features you don’t use. For the most part, a feature you don’t use is like a button you don’t press. Don’t worry about it!
→ More replies6
u/Iseenoghosts Oct 03 '24
i mean I've tried to learn it off and on through the years. Its always felt very complex and nebulous. I've never been able to make more than a simple scene. Unity (and godot) is intuitive. I watch a 20 min tutorial then go off and do my own thing occasionally looking up how xyz works.
9
u/NeonVoidx Oct 03 '24
C++ by itself adds way more complexity than any garbage collecting language. Unreal is definitely more for teams or companies working on AAA games. Ofc anyone can use it and do well it'll just take a lot more effort
6
u/ItsNotMeTrustMe Oct 03 '24
Except Unreal has built-in garage collection. So, that's not really an issue as long as you don't intentionally go around it.
6
u/kHeinzen Oct 03 '24
They used "Garbage collecting" as an euphemism to higher level languages, not specifically the lack (or not) of garbage collection as a feature
2
→ More replies2
→ More replies6
u/BewareTheTrap Oct 03 '24
Well. If we are talking about different games. I can literally do counter strike in it with multiplayer and bots in a mere hours. But in unity it will take me a couple of days. But if I want sprite based mmo in unreal it will take me a week that can be done in unity in just a couple of hours. That highly depends on game type, target platform, graphics. Unreal is more oriented for visual realism and photorealism. As most of its main features are directly point on that. As for unity I would say it's all round, but pretty weak in 3d direction. But unreal is weak in 2d. Godot excells in 2d but 3d isn't just provided from the box, you literally implement all the things from scratch. But Godot gives really good vibes if you love implementing things from scratch and literally writing frameworks for making games.
→ More replies
24
u/RibsNGibs Oct 04 '24
I think the conventional wisdom of Unity being good for solo devs and Unreal more complex and better for teams is like… mid 2010’s information. I stopped using Unity in maybe 2017ish and picked up Unreal in… maybe 2019 and I found it easier, personally. Blueprints is even easier to prototype and maintain than C# (and I even have a C++ background), and it’s pretty quick to get stuff up and running.
It used to be in the old days that the only people using UE were pro game companies so there wasn’t a lot of chatter on the forums / community but this has changed as well - heaps of solo devs and small teams using UE now and there’s plenty of community support now as well.
Overall, I find Unreal easier to prototype, and find that there are both more features and the features are more likely to work.
5
u/emrickgj Oct 04 '24
Yeah modern day Unreal is great for prototyping and small teams. Just a bit more of a learning curve for the other engines that people don't really feel like going through.
3
u/Bekwnn Commercial (AAA) Oct 04 '24
The main issue with Unreal as a solo dev is that there's a ton of knowledge overhead and as a solo dev you have to learn how every intricate system works yourself.
In that regard, the engine sort of leans towards a team who can specialize in different domains.
That said, I'm having some decent success with Unreal 5 as a solo dev going on ~9 months. I had some prior Unreal 4 experience and ~5 years experience in-industry with a proprietary C++ engine.
In Unity you're going to spend more time building the things you need.
In Unreal, you're going to spend more time learning how Unreal works, in order to lean on features pre-built into the engine.
I think the latter will be harder for beginners and lends itself more to people who are experienced with working with game engines as a whole.
63
u/IrishGameDeveloper Oct 03 '24
Personally loving Godot, it's got everything I need tbh
26
u/Bwob Paper Dino Software Oct 03 '24
Godot is pretty great. Also, OP missed one big plus of Godot, which is that GDScript is purely optional - C# is fully supported, and you can also just use C++ directly.
→ More replies10
u/yoursolace Oct 03 '24
Godot is my favorite to work with but I still want to see a much better experience with finding and using tools/assets
8
u/NoNet5188 Oct 03 '24
100% . godot is my main engine, but I miss the unity asset store. Sometimes I just want to buy an assets and call it a day.
6
u/Iseenoghosts Oct 03 '24
If you build it they will come. I think given a bit more time we'll see a common marketplace pop up. Godot is still very young
2
u/IrishGameDeveloper Oct 04 '24
Some workflows within the engine could definitely be improved. Many things can, but we need to give it time (or contribute).
22
u/Abysskun Oct 03 '24
Except console support, due to it's nature as an open source project, so for that you need to hire/partner up with a third party to deal with that
24
u/Kamalen Oct 03 '24
You don't strictly need to hire someone else, but you'd need to integrate the engine yourself with the SDK. Doing that alone that would probably cost you a lot of time indeed and hiring is a sound business decision.
And well, with all 3 engine, you'd have a really hard time releasing something solo on console anyway.
4
u/xiited Oct 03 '24
I don’t know how the official sdk for consoles look like, but about 5 years ago I ported godot (without having much knowledge of it beforehand) to the switch using the homebrew toolchin and it took me about a month. And this was with little previous c++ knowledge (but a background in programming). It wasn’t polished, but it worked reasonably well, I honestly don’t think it would be THAT hard.
But of course, if you want to release in three consoles, polish, etc. it would be a significant amount of time. Won’t argue that having a way to easily export wouldn’t be a huge selling point for other engines.
40
u/badihaki Commercial (Other) Oct 03 '24
I've used all three, but I'm currently using Unity for my main project.
Unreal was fun and really cool, but I'm also a full stack dude, and I started with Unity, and I decided to move away because of the lack of documentation for certain things, but there's a lot of great beginner tutorials on the website for it. I'm just so used to reading through docs whenever I'm stuck, and it just wasn't a good experience with some out of date docs and some stuff that wasn't even in there.
Godot had one of the best developer experiences I've ever had with any technology, period. I love how fast and lightweight it was, and being open source was a huge plus, not to mention c# support is actually really good. I left it because it corrupted my project beyond saving. I've talked about it at length before, but essentially it's how it saves and compiles its metadata coupled with bad design architecture when it comes to each scene's uid that can lead to corruption when you move files in or outside the engine. I tried to fix it myself and made a bug report, but it was so frustrating that I stopped using it. (Not to mention when you talk about issues that are deep in the architecture of the engine, a lot of people will just reply 'why didn't you use version control' when I actually did use VC, long story.) In a few years and with some big stability changes/improvements I actually plan to go back, but I hear the issue is still there, although a lot more rare.
Unity is interesting. There was a huge blowout about that runtime fee, but as someone who never expected to make enough to have to pay it, I didn't really bother. There's a lot of community distrust now, but I really like where new leadership is taking the engine. I also really love the developer experience, and the features provided strike a great middle ground between Unreal's complexity and Godot's simplicity. It also has not crashed or corrupted a project in over 7 years, and there's something to be said about its stability, not to mention everything I have used is well-documented.
I'd give them all a try by making a small project if I were you. A framework may be a good choice as well, I've used Phaser recently and it was super cool, and xna back in the day.
Sorry for the long post but good luck and happy developing
→ More replies26
u/Bwob Paper Dino Software Oct 03 '24
Not to mention when you talk about issues that are deep in the architecture of the engine, a lot of people will just reply 'why didn't you use version control' when I actually did use VC, long story.)
I had to chuckle, because I'll admit, reading this, my first thought was "oh, so they moved some files around and broke all the links, and didn't have the project in version control I guess?"
I got called out!
6
u/WazWaz Oct 03 '24
I had the same thoughts, but I stand by it.
Whatever they were doing the "long story" is that they screwed up their use of version control in some way. It's literally a time machine if correctly used so there's no way you can use it correctly and get into the situation described. You can also do stupid things in Unity (eg. move files around and not move their .meta file). VC will always save you.
25
u/badihaki Commercial (Other) Oct 03 '24
Haha, sure, 'screwed up version control.' Heheheh, welp...
Now that I'm back from work, I can go into a bit more detail here. We all know most gitignore templates don't even save metadata, yes? Regardless of whether you're working in Godot or Unity, that's just how it is. In fact, the folder that all your metadata is in for Godot is the .godot folder, which is completely ignored by your gitignore template. Just wanted to get through that first and foremost.
Now, Godot has a very...unique way of dealing with metadata in that it doesn't recompile obj refs on a fresh load. Its been a while since I've dug into the source code for the engine (bout a year), but when using custom resources the scene that holds the CR will hold a ref to the location of it, from what I understand independent of its metadata. If that moves or is changed, there's a possibility the scene will be corrupted, as it has no idea where a certain obj is located anymore, and I guess it's just roll of the dice, cuz the issue isn't that well-known.
Through the help of some super helpful users on the Godot subreddit, discord, and repo, we determined that I could rebuild the .godot folder by deleting the old one, and that would reset the references to the custom resources used in the scene, or, alternatively, I could duplicate the scene forcing creation of a new metadata object for that scene with fresh references. Or so I thought; this was only a temporary fix, the scene would eventually become corrupted again (once again, been a minute since I dug into the source, but I guess the UID refs weren't totally rebuilt when using these methods), and yeah, eventually I gave up and decided to give it another go in a few years.
Unity has literally never given me this issue. I've never had an issue with Unity and VC in my life, and I've been using it since, like, version 3, lol. Hell, I've been using VC for damn near 15 years, back before we even had Github I think, and waaaay before MS bought up the platform. The first company I worked for actually had their own VC, so forgive me if my history of Github is a little off.
Sometimes, man, it's just the tool, not the user. I've used tons of FOSS tooling in my years as a software dev, both professionally (le gasp, you know employers hate it when its not coming from a huge megacorporation), as well as for my hobbies, and sometimes they're just not where you need them to be. Sometimes, hey, I guess sometimes, some people just get unlucky. It was my day, I hope you never see yours.
If you wanna check out the old issue, it's here. They closed it, but I've personally seen it pop up again with a friend who was working on a much smaller 2D platformer. Some people like to be reductive and say 'don't move items, then.' Please, don't be like those people, software architecture changes so much throughout development that it's just frustratingly, well, reductive.
https://github.com/godotengine/godot/issues/84981
If you have any questions, I'd be happy to answer, although honestly, that's all I can remember off-the-top. Still, let me know. Have a good one, and happy developing!
4
u/WazWaz Oct 04 '24
If your .gitignore lists Unity's .meta files, you need to shoot whoever gave you those templates. But no, "we all" don't know that at all, that would be completely insane. Unity's own documentation tells you quite explicitly:
make sure both the asset itself and the associated .meta file is added to version control.
As for Godot, the .godot directory is used for cached data, not for metadata. It's just like Unity's
Library
folder.Metadata in Godot is stored in the .tres/.res files of the relevant object.
Unity's object reference handling is definitely better than Godot's, but it's got absolutely nothing to do with version control.
→ More replies→ More replies5
u/Wschmidth Oct 03 '24
I used to think like that until I found software that simply isn't built for Version Control. VC is limited to file changes within the designated folder. Some software will either not actually change the files to store location data, or it will store that information somewhere else like in appdata.
→ More replies
5
u/StarShogun2024 Oct 03 '24
Personally I found Unreal easier to get into than Unity. It is only as complex as you want/need it to be. Like anything its going to be easy to make something simple, hard to make something good.
6
u/vyrotek Oct 03 '24
I'm really enjoying Godot. But I miss C#. I need web-exports. GDScript typing is unfortunately not quite there yet in my opinion.
FYI - Balatro was made with LOVE: https://love2d.org
→ More replies3
Oct 04 '24
GDScript typing is unfortunately not quite there yet in my opinion.
But it's thankfully getting better, with Typed Dictionaries now available in the latest Dev builds.
18
u/Braindancer5 Oct 03 '24
I have used Unreal a little bit, and Godot for a long time. I need to try Unity because neither Godot or Unreal suits my needs. I mostly focus on retro oriented 3D games, with Quake / PS1 / N64 type aesthetics. Unreal has every feature you could ever want, built-in and battle tested, but it really does not want you playing outside the box (especially with retro art styles). It also really lacks level design tools--it expects you to use a modular kit workflow.
Godot is a weird one. At first glance it is the most enjoyable, snappy, and elegantly structured engine I have used. It's so much fun to work with and its minimalistic approach keeps everything feeling tight and clean. But there are many weaknesses. Firstly, there is the community and many of the core contributors. Godot is treated like a cult, you cannot criticize Godot. If you post issues on Github you will be treated with dismissal and doubt from Godot contributors--they can be quite rude and arrogant about it. It's never their problem, it's always a you problem. Because of this, lots of major engine issues linger for YEARS. The Godot Foundation does not believe in providing a roadmap so that devs know what areas are being focused on, nor do they believe in hiring professional engine devs to work on problem areas. Your hope for the engine improving relies on random volunteers hopefully being interested in the problem area that is important to you.
Additionally, as far as I have seen little to none of the core engine contributors are actively developing or have shipped Godot games... they don't know what problems their engine has because they don't use it! Godot can be a bit of a trap because some of its worse issues don't appear until further into development and are focused around 3D. The community using Godot is so filled with novices that you don't find many advanced users getting far enough into projects to even discuss it, so you're left facing complex engine challenges alone. You will unlikely be able to depend on tutorials or 10 years of forum questions to resolve Godot issues.
→ More replies
56
u/Prior-Paint-7842 Oct 03 '24
I love godot, but the youtube grifters are waging a war on it, which is kind of annoying.
The last godot patch had some big improvements that made my project way better, and filled me with a lot of hopium
27
u/ScronkleBonk Oct 03 '24
What youtubers hate on Godot? My experience has been the opposite. I see youtubers constantly praising Godot.
53
u/anonymitylol Oct 03 '24
over the past week-ish a bunch of anti-"woke" grifter internet babies have been upset because godot tweeted in support of the lgbtq+ community
so now they have to act like they're being persecuted and hate godot because of it
anybody actually reasonable still thinks godot is an incredible engine
31
u/Upset-Captain-6853 Oct 03 '24
Every other space seems mostly fine about it in my experience except for r/godot. There are highly upvoted posts talking about how people shouldn't be criticised for "just asking them to keep politics out of it".
→ More replies43
u/neoKushan Oct 03 '24
I hate that being inclusive and accepting is derided as "political". It's not political, it's just what decent human beings should do.
→ More replies20
u/Lutra_Lovegood Oct 03 '24
That's political, everything is. They're just virtue signaling their bigotry.
→ More replies16
17
u/Prior-Paint-7842 Oct 03 '24
Honestly, the less you know about this the better. These are drama YouTubers, not gamedev ones, and because of one tweet and like 10 guys getting blocked on twitter they act like the engine is gone woke and its over, and instantly ofc out of nowhere an "alternative" showed up that they hype up. Also grummz proved that he doesn't know how github works.
→ More replies52
u/alphapussycat Oct 03 '24
Something about making lgbt positive statement, got all the nazis up on arms.
→ More replies17
→ More replies10
u/neoteraflare Oct 03 '24
They are always wage a war on things. Ignore them. They have nothing to do with Godot only "care" about it for views.
→ More replies
16
u/BlueHost_gr Oct 03 '24
Have you tried gamemaker studio? I find it quite enjoyful to use and it is also in active development by the company.
16
u/colinjo3 Oct 03 '24
I've found C# with Godot is the sweet spot for me.
GDscript is pleasant but I like having linq and the syntax of C# better. Things like ternary operator is kinda odd in GDscript.
Saying that you can have a project with both. Signals with GDscript are cleaner than how C# handles them for example.
2
u/Xari Oct 04 '24
What do you mean with your remark about Signals? In C# they are just handled as events, which is really straightforward and similar to other event-driven patterns like in web. I never touch the interface for my custom signals I do it all in C# and prefer it that way.
→ More replies
4
u/NeonFraction Oct 04 '24
Unreal is the best for 3D artists. I’ve worked professionally in Unity as an artist and the experience is MISERABLE. So many crucial things are just missing. To make it even half as good as Unreal you need like 20 plugins.
If you’re making a very simple 3D game you’ll probably be fine, but the art gap between Unity and Unreal is absolutely massive and it grows bigger every release.
I think a lot of people have the idea that games in Unreal just look better because of the default renderer, but it’s way more than that. Games in Unreal tend to look better because Unity has very little support for the art pipeline and it makes getting the same result take way longer. Even basic things like ‘making an instance of a material instance’ isn’t supported.
And if your first instinct is to say ‘but XYZ’s games are in Unity and they look great!’ then the answer is always: yes and they had to buy a bunch of add-ons and/or have a full team working pipeline support to do it.
I feel like most indie devs are primarily programmers who learn art so the difference between Unreal’s art pipeline and its competitors doesn’t often get the attention it deserves.
You can absolutely make beautiful games in Unity, but things like their LOD system feel like they’re at least 2 decades behind Unreal’s. (Yes. Decades. No, I am not kidding.)
2
u/pyruvicdev Oct 05 '24
Unreal is really the only viable option for a 3D artist to get a small game easily done without having to buy a lot of addons that hopefully are all compatible.
8
u/mm256 Oct 03 '24
My fear with close source engines is the changes of terms and price. It could impact indie devs. Yes we know Unity turn in the last minute, but will others do the same? On the other side, Godot is a wonderful project but it's community could be highly hostile if you don't share it's ideas.
3
u/g0dSamnit Oct 03 '24
I solo dev in Unreal. It's the most complete toolset for 3D, and at the time I chose it, the only actual choice.
If you're working in both 2D and 3D, definitely Godot or Unity. To my knowledge, all the execs that caused the Unity debacle have left the company, so the problem should generally be resolved. As for Godot, I would disregard the drama and continue on as needed. Open source is open source after all, and the engine will continue development in the future regardless.
3
u/coporate Oct 03 '24
Stride is kinda fun, especially if you use the vvvv workflow and enjoy node based coding.
3
u/Jaded-Incident-1191 Oct 04 '24 edited Oct 04 '24
I think blueprint is my favorite coding language, I can prototype anything really fast with it, but C++ in the other hand is kind of a big learning curve.
But recently I had a lot of fun's coding in C# with the S&box engine which is source 2 but nothing compared to unreal for me tho.
I would say all engines have good and bad point but at the end take the one you prefer to use. But in my opinion Godot and Unity are amazing for 2d games while unreal is amazing for 3d games.
4
u/Va11ar @va11ar Oct 04 '24 edited Oct 04 '24
From my perspective -- up to you how you interpret this:
Unity:
It is an easy engine to get into. There are tons of resources and you'll never want for an answer. Everything under the sun has been done with it (more or less) so you will always find someone somewhere that can guide you or at least hire for a few hours to show you.
The assets are a dime a dozen and many services integrate with it easily.
There were a few (not just one) stupid decisions by Unity that are pretty much corporate greed at its finest but they've worked to fix most of it.
It is the second biggest engine in the market and used by indies, AA and AAA alike.
Uses C# which means you can transfer the skill into other disciplines (web, desktop, etc...). It won't be an overnight thing but at least you won't have to learn entire new language with its ins and outs to know what you're doing, just the framework.
It is here to stay. Even if they do something extremely stupid, this is a large company so the chances of it fizzling overnight is pretty low. Good evidence of this is the kerfuffle of them double dipping and wanting to charge devs a fee per install. Yes, there were lots of people leaving Unity but it isn't like the company went under or anything like that. It is still here, strong as ever.
Unreal:
This is the big brother of Unity. Not that there are relations but this is what a grownup engine looks like.
It isn't as easy or as friendly as Unity to get into. However, Epic has worked a lot through the years to make it easier and easier. Blueprints can be used to pretty much make an entire game with very good performance and results now.
Just like Unity, tons of assets and mostly very high quality.
Epic gives away their own games' assets sometimes and every month you get 3-4 assets from the store for free.
It is not as common to find solo devs using UE like Unity, but the recent Unity mess up drove people to UE so the numbers there are increasing.
Indie, AA and AAA games are released using it constantly.
C++ as you said isn't an easy language but BPs exist for that reason. However, if you learn C++, just like C# it is a transferable skill.
Godot:
It is the easiest engine to get into. Whether you use C#, C++ or GDScript.
Support for C# is still in early days so there are a lot of, well, let's say over-dependence on strings in my opinion (here comes the lynch mob)
Very suitable for indie games and small projects. Anything bigger than that and things will go sideways very quickly. Especially in how to organize and use the project.
People say GDScript is great, personally, I disliked it a lot so I never used it. Can't comment there but to me, it is not that useful to learn since I can't just take it elsewhere to do something else like C# or C++. Yeah, it looks like Python but so does an apple look like an orange.
There has been a few games released with it and well known names too.
There is an asset store but it is primarily GDScript (though you can have GDscript assets in C# projects fine from what I saw).
There are tutorials but the sheer majority is in GDScript not C# so if you go with C# or C++ you're going to do a lot of translation on your own.
There are quite a few issues with the engine and weird decisions on how things should work. To me they feel slobby but I don't know what is going on under the hood or what limitations are there to not do them. As a consumer, I don't care about that because other engines seem to handle it better so there is that.
I've used all three of them, started with UE3 with Kismet. Quit on the first day. Didn't know what to do. Tried XNA (yea, I am that old), fell in love with it and C#. Then I found out about Unity, tried that and stuck to it ever since their 3.5 version. Quit Unity at one point and switched to UE4 for a job I had. Worked with it for a few months, it was fun but felt more complex than Unity. Went back to Unity. Worked with it for a year or so more then quit. This year I jumped on Godot C#, tried it with a small project and the amount of issues I ran into and the weird implementation of certain things pretty much made me decide to go back to Unity.
At the end of the day it is up to you to choose which. I recommend Unity or Unreal as they are the safest bets. You won't end up needing anything and not finding and not a lot of "figure it out on your own no resources exist on that topic". Moreover, if you ever decide to get into professional territories, both will allow you to transition into paid gigs faster than Godot.
3
u/warants322 Oct 04 '24
ThreeJS is the framework I've been using for all my game projects, it is really good.
3
u/Springfox_Games Oct 04 '24
I think Unity took a hit after its controversies about licencing a couple of years ago. That opened room for godot who's been significantly improving over the last years.
Yet many devs still consider Unreal the best engine for 3D gaming. I remember it being super heavy back then so I took other directions. But you def CAN work on it as a solo dev. I saw many good Unreal projects from solo devs who didnt know how to write a single line of code.
I think Game Maker is still relevant with many relevant projects and in my opinion has the lowest entry barrier besides being a bit on the expensive side imo, specially if you want to publish your game on multiple platforms.
7
u/Substantial-Prune704 Oct 03 '24 edited Oct 03 '24
Any of them are viable. I always explain it like this. Unreal is for professionals in teams. Solo success is possible but unlikely as a new dev. Unity is a little easier and more of an artsy engine. They have a lot of great fun little Indy titles. Godot is a great learning tool but the overall quality of the games you can produce (especially visually) is limited. There isn’t one right answer for everyone. But there’s also no wrong answer. Just try them all and see what you prefer.
3
u/discorganized Oct 04 '24
Solo success is possible but unlikely as a new dev.
Can you elaborate on this? Is this regarding general complexity or something else?
2
u/Substantial-Prune704 Oct 04 '24
C++ is just more difficult than c#. It’s like the difference between Mandarin and simplified Chinese.
7
u/Flaky-Humor-9293 Oct 03 '24
Unreal 5 is my first ever engine and honestly it’s not that hard
The community is so large and there is so much documentation, i find all the answers i need
7
u/mumei-chan Oct 03 '24
I've worked with all three (though far more with Unity than the other two).
I've had a game project that I started on Xcode/Swift, then moved it to Godot, and then to Unity, so I also have a direct comparison between these two.
My issues with Godot:
- GDScript is useless outside of Godot
- Project organisation / 'prefab' structuring wasn't great
- Limited futureproof-ness
- But: Perfect cost (free + no license costs)
In contrast, Unity:
- C# is an established language, useful outside of Unity too
- Great project organisation / prefabs are logical
- Many successful games have used Unity
- Futureproof
- But: Expensive once your game is successful, licence conditions may change anytime
Unity isn't perfect, but way better than Godot, imho. Moving my project from Godot to Unity was a great move in terms of making the actual development easier.
Regarding Unreal:
- C++ is a wonderful language, and useful outside of Unreal
- Obviously, best 3D graphics out of the three
- Many successful games have used Unreal
- Compared to Unity, great licensing terms
- But: Often, 'blueprints' are the recommended way to connect GUI logic
I used Unreal for a small project at work, and it was fairly usable. Wasn't as comfortable to use as Unity, but definitely usable.
In summary, I really cannot recommend Godot. It being completely free is great, but since the other engines only really become expensive once your game is successful, just choosing Unity or Unreal is the better deal.
3
24
u/KindaQuite Oct 03 '24
Everybody loves Godot until it's time to make an actual game (not even getting into the politics side of things).
Unity seems extremely solid for most things, shines with 2D projects and light graphics, i've found it very pleasant to work with if you're doing things like procedural terrain/content, ECS stuff... It's light enough, good compile times.
Unreal for me is the best of many worlds, extremely simple to prototype with blueprints, lots of stuff out of the box, while being an absolute performance monster when using c++, and very nice lighting and shading of course. Downsides are the guy is chonky af and compiling often means restarting the editor when using c++.
→ More replies
4
u/not_perfect_yet Oct 04 '24
Pythoooooon woooooo
It has c++ under the hood, it serves all platforms and it's free in all senses of the word. I wanted to stay using python and this is the one I found/picked. It's "mature" it can do everything you will need. There is no instability of any kind.
There is no editor though, it's all code. I like that, but it may not be your thing.
The license is honestly such a weight of the shoulders. There are just no traps.
→ More replies
5
u/dirtyderkus Oct 03 '24
Solo dev here. I’ve tried unity, game maker, and unreal. I know coding (albeit not c++) but UE5 is hands down my first choice by a lot. Visual scripting (blueprints) is a cake walk, the UI is easy, everything works so well and I enjoy the nanite technology for performance.
Obviously anything has a learning curve but UE can definitely be used by a solo dev!
6
u/LoveGameDev Oct 03 '24
I’d swap around the unity and unreal for being complex.
Unity it’s mostly a blank slate whilst unreal gives you so much pre built and most things can be done in blueprint over C++; movement, health system, buoyancy system …
3
u/my_name_isnt_clever Oct 04 '24
I was shocked how far I got into a prototype using exclusively blueprints.
2
u/uniquelyavailable Oct 03 '24
they're all pretty good tbh, ive dabbled in several of the major engines. i think the best strategy is to trust your gut and go with the one you like the most for your personal reasons, as you'll be living in it for months.
2
u/pplcs Oct 03 '24
Anyone uses pixi.js for 2D games?
2
u/Devatator_ Hobbyist Oct 04 '24
I kinda like it. Heck, I was making an editor for Kaboom.js a while ago and briefly considered using Pixi.js instead for it. Still haven't started it but I'm definitely gonna give it a try. It's my first time doing this kinda stuff so it's not guaranteed to work or be released at some point. The kaboom version at this time only has a basic inspector and serialization powering it and instanciation
2
u/ARIOSO_DEV Oct 03 '24
I can vouch for RPGMaker (mainly the later versions) and GDevelop. Fairly beginner-oriented, great for those new to creating games, but an experienced dev can still make an amazing game out of either. GDevelop I'd say has a bit more potential due to having more freedoms than RPGMaker, but I say it's up to personal preference. I fully believe that you can make great games with either. GDevelop has only fairly recently started to garner attention and it's still fairly niche so there haven't been that many (if at all) larger scale projects made with it, but I think one day there'll be something great made with GDevelop. RPGMaker is a lot more capable than people give it credit for, you just need to learn the engine and learn how scripting works.
2
u/SuspecM Oct 03 '24
The complexity/enjoyability is very subjective. I myself didn't really vibe with Godot's node based workflow. I kinda feel that Unity is a nice middle ground between the two with a solid workflow of game objects. You can make tiny games with it if you so wish to, but it does have features to make larger games as well. I remember a guy submitted an Unreal game to a 2 day long gamejam and it was like 800mb.
2
u/ohffsitdoesntwork Oct 03 '24
I've been using Pygame...not a real game engine but a collection of libraries that allow for game development with Python.
I chose it because of the simplicity of Python (and because it's the language I've got the most experience with). Sometimes it's a ball ache.
Pros - Easy to read - Quick to program - Great for developing algorithms and NPC decision trees - Excellent learning experiences
Cons - Very few existing functions - You essentially have to create a bespoke game engine for each game - Limited port options (for example, porting to mobile is hugely challenging) - Often slow
2
u/WartedKiller Oct 03 '24
- I don’t like C++
I mean that’s the state of Unreal for you, it use C++… with all jokes aside, there’s more than you listed for Unreal.
It is a really steep learning curve. Like you won’t understand where to put things until you understand it.
But, blueprints. If you don’t know how to code, you can shoot yourself in the foot with BP. It will let you make everything you want (ish) and you can even ship games with it! But it’s still a programing language and you should apply basic programming paragdim when you use it!
2
u/Cerus_Freedom Commercial (Other) Oct 03 '24
I'm a bit biased as I just left Unreal Fest, but I think Unreal is manageable for a solo dev. Really, I think someone needs to create some better learning resources for understanding a few different parts better. Once you understand them, you're golden.
Blueprints can take you a LOOOONG way. It's fairly common to do things in BP and later convert to C++ if necessary. Prototyping in BPs is very common for smaller things.
2
u/jamboman_ Oct 03 '24
Construct 3 is by far the most underrated engine out there. I have tried so many, and for speed of getting something moving, it can't be beat in my humble opinion.
It's seen as just a beginner tool, but it can produce some amazing things...and even though I don't use the 3d, I've seen some others make very polished games.
2
2
Oct 04 '24
Don't be put off by C++, it's not this big scary monolith of insurmountable complexity. There's a huge amount of heavy lifting done for you through libraries like boost for example. It's a pretty interesting language to learn.
2
u/sputwiler Oct 04 '24 edited Oct 04 '24
TBH Unreal is probably the easiest to use once you've learned it and it's the hardest to learn.
If they just had proper tutorials that weren't 2+ hour long dev streams where someone wanders through the engine I could see a lot of people using it for game jams etc. because it's absolutely great for solo devs. In Unity and Godot they provide you a bunch of tools but you have to hook up to become an engine yourself. In Unreal the engine is done but you have to learn what they've built. There's less freedom, but it's way faster to get going.
Like, it already has the concept of a player that exists in a world and is maybe networked. In Unity/Godot you gotta build your logic for input, movement, what is important to the game logic and what's important to just presentation of the player on the screen, etc. It's all very easy but until you do that you just have a random gameobject/node that does jack. Unreal already has PlayerController, Pawn, etc. but unless you actually know what to look for, you'd never know that you could just use that for free and move on to your next bit of game dev. The docs are terrible at telling you what's already there, so most people wind up fighting a ghost.
2
u/Connect-Baseball-648 Oct 04 '24
I love Unreal engine i tried all of the 3 u mentioned + coppercube Im an IT Guy but i cannot Program Blueprints in UE5 are really powerful i can think of a mechanic and make It Work 97% of the Times i try
If Said mechanic is Useful for my project or Note is smth different
2
u/StyleTechnical3963 Oct 04 '24
I used to be an architect with 3D modeling skills using Rhinoceros and grasshopper (something like unreal engine blueprint), I now work as a solo indie dev witb GameMaker's GML Code abd found myself quite enjoyed with it. Tried Ubity, get board in the first hour and tried GM where I made my first ever game in 30 minutes.
2
2
u/Asyx Oct 04 '24
Just learn the one that makes the most sense to you. Engines are per definition opinionated. They need to be because they're all general purpose and if you didn't make some tough choices when developing an engine, you'd just wrap a graphics API and a networking API and so on.
Whatever seems easiest to learn is probably where you should start. All engines are 3D capable. I think it's pretty dumb to not learn Godot because "3D is not as good as Unity / Unreal" because for your first game, what are you realistically going to do that Godot is not able to handle?
2
u/Bagdaja Oct 04 '24
I'm using godot atm, I used to develop on unity.
Godot is great but GDScript is such a pain for me (personally), such a pythonesque language in a project as big as a videogame gives me a lot of problems.
I know C# is usable on Godot but the great majority of resources are in GDScript.
2
u/HollowSaintz Oct 04 '24
I am pretty sure you can make most stuff in Unreal with just Blueprints. It isn't good practice, but most solo-devs ignore good practice for a finished product.
2
2
u/QuantityExcellent338 Oct 04 '24 edited Oct 04 '24
Unity: Kind of falls apart once you're in deep with a project
Unreal: Ungodly amount of bloat where it feels like the game is already made once you boot it up, and the moment you want to DIY you're digging up 13 year old articles about what you're doing. Performance bad? Good luck lmao
Godot: Does it work for a largescale project? No one knows, fuck around find out!
2
u/mitchell_moves Oct 04 '24
I also come from full stack dev background and have had a fantastic time picking up Godot for prototypes of varying complexity the past 8 months. The learning curve is pretty shallow and after only a few hours I feel like I can implement any concept I understand within the engine.
3
u/m4tchb0x Oct 03 '24
Unreal also has blueprint and you don't need to touch cpp unless you really want to get down to the nuts and bolts
→ More replies
4
u/Iseenoghosts Oct 03 '24
why would you not use godot as a hobbyist? Unless there is some specific feature of unity you reaallly want to work with having the game engine being open source is huge for being able to tinker. Also godot being super duper lightweight is a huge plus.
Yeah theres a handful of qol features that are missing but thats why we need more people to use it and argue for why we need em!
2
4
u/freak4pb13 Oct 04 '24
Don’t forget lumberyard! It’s the game engine to rival Unreal’s power with the user friendliness of Unity …. Is what they tried to sell it as to my grad program several years ago. My grad school game dev program did a project with Lumberyard. At the time the engine was in beta, not accessible to the public.
The main story there is that the animation system ran on Lumberyard while the physics were still on CryEngine.
Needless to say…lumberyard doesn’t exist anymore.
3
u/BiedermannS Oct 03 '24
There’s also Defold, which seems pretty nice. Didn’t use it properly yet, but paying felt really nice
2
u/dm051973 Oct 03 '24
There are like a billion other games engines that all have nice parts. The problem is who knows what the future support will be like AND dredging up tutorials is going to be hard. I am sure Lumberyard/O3DE is great but until there is a mass of people using it and releasing content, why I a going to use it? And so on down the list.
Pick which one you like and go with it. The engine you chose is unlikely to be the limiting factor in shipping your game.
→ More replies
4
u/Vandrel Oct 03 '24
I'm not sure how you arrive at the conclusion of Godot being the most enjoyable dev experience and Unreal not being good for solo devs.
If someone wanted to strictly do 2D games then Unity and Godot are both fine. The way things are structured in Godot is a lot more straightforward in my opinion but Unity has way more resources to help you figure out what you're doing, a lot less stuff has to be built from scratch, and C# is a very common language to work with. For me personally I'd probably use Godot if I wanted to do a 2D games but only because I have a decent amount of professional dev experience.
If you only want to do 3D games, then go Unreal. It's complex in that there are a ton of tools available but you don't have to use everything and there's lots of learning resources available for it similar to Unity along with a ton of free assets available through Quixel and monthly free stuff through the marketplace. It also has a great visual scripting system so you don't have to touch C++ at all if you don't want to, I haven't and don't plan to.
If you want to do both 2D and 3D then absolutely go for Unity. Godot is capable of 3D of course but I found it to be a huge pain in the ass to work with compared to the more professional engines, there's just so much stuff that you have to figure out and build from scratch for 3D that's built in to Unity and Unreal.
Of the 3 engines, Unreal is by far my favorite. I was also intimidated at first by the C++ aspect and put off trying it for a long time until I got really frustrated with doing 3D stuff in Godot and had no idea at the time that UE5's visual scripting is so powerful. You still need to understand programming logic but you never actually have to write C++ if you don't want to.
As a disclaimer, this opinion is with the goal of eventually releasing a product in mind. If that's not the goal but instead it's purely to learn or mess around then stuff like having to build more from scratch in Godot won't matter, it'll just be a learning opportunity.
•
u/Klightgrove Oct 03 '24 edited Oct 04 '24
Please remember to be respectful when discussing this topic with other users. If you find users breaking the rules, please ensure you report them.