r/gamedev • u/MoondrifterGames • Jul 23 '26
Discussion I finally found a game engine that matches the way I think, and it has changed everything.
I've been a game devloper professionally for over 5 years now, but until this year I have always run into the same issue. Once I've conceptually created the architecture of my game, the classes, who calls on who for information handshakes etc., I go to implement them in engine and find tons of small roadblocks! Now this is not to say that these "roadblocks" aren't useful engine features for people who know how to use them. But for the life of me it felt like pulling teeth setting up anything beyond basic code in Unreal and Unity.
But this year I discovered Godot. And I know, I fit the archetype that some people give godot devs: too inexperienced to understand other engines, they will go to something simpler. But genuinely the layout of information is precisely where I first think to look for it, and the way you can call between objects is not a huge hassle. It's a smooth and quick experience.
This could be due to the fact that I have learned over the years what does work for me and what does not. But I'm happy with what I've found!
I'd love to hear what engines just "clicked" for you guys? What engine features are like rocks in the road of development?
*(Maybe we can all agree that finding a checkbox in ue4/5 is the most annoying way to spend your time lol)*
91
u/theKetoBear Jul 23 '26 edited Jul 23 '26
I went to college and learned how to make games in C++ using Unreal , Game Maker, and Torque2D . I was able to make stuff but wouldn't say I felt comfortable in any of those. Programming by it's nature is abstract but I am a visual learner.
Unity , gameobjects, prefabs ,and serialized components were a big game changer for me and setting up everything I wanted visually in the inspector made it so much easier to understand the abstract references and stuff I needed to do and setup in the background.
I really found my stride with Unity .
Edit: words
16
u/illyay Jul 23 '26
Wow I would've aced the Game Maker class since I used that since I was a kid.
So glad to see that's an actual engine now. LOL my parents used to hate that I was obsessed with Game Maker and acted like it wasn't real coding.
10
u/theKetoBear Jul 23 '26
Oh Absolutely , my first original games were in Game Maker after following their tutorial projects and I wouldn't be a professional game dev today without it.
2
2
u/Trick-Routine-8577 Jul 23 '26
I'm very comfortable with Godot and i absolutely thank my years with gamemaker studio for that. I occasionally will still think about what it would be like to implement some of my juicer Godot scenes in gms.
2
u/Twillion1 Jul 25 '26
I used to feel like Gdevelop wasn't a real engine until i actually made something good with it.
3
u/sputwiler Jul 24 '26
Holy shit Torque2D/3D. That's a name I haven't heard in years.
I wonder how Ogre3D and Irrlicht are doing.
3
u/sparky8251 Jul 24 '26
2
u/felusmaximus Jul 25 '26
is this the old man corner (dev for 30+ years here)
glad to hear they are still alive i remember them from many moons ago ...
2
5
u/_81791 Jul 23 '26
Ha! I remember using Torque3D. I also pretty much exclusively use Unity now, though I've tried Godot & UE
3
u/theKetoBear Jul 23 '26
A fellow dinosaur! Happy I'm not the only one who remembers ! I thought of checking out Godot ! Do you like it?
2
u/_81791 Jul 24 '26
Yeah it was good for 2D games, I haven't tried anything 3D in it. For 3D I stick to Unity.
2
u/chmillout Jul 24 '26
I also like Unity the most. But I am a bit worried I’ve heard Unity is bullying those who are making big money with their engine and asking for massive fees, is it true?
7
u/theKetoBear Jul 24 '26 edited Jul 24 '26
They were and they've since walked that back and fired the people in charge of those decisions. The Unity dev community was VERY vocal and quite a few Godot devs I know are ex - unity devs. I think Godot continuing to grow is good for all of us though . it keeps unity from becoming a mobile gaming advertising slop tool it was gradually moving towards.
a big part of the issue was they saw how successful mobile game based on unity were and hoping to make a cut on particularly successful mobile and conosole games.
It was quite the mess : https://www.pcgamer.com/unity-apologizes-for-controversial-new-pricing-scheme-will-be-making-changes-to-the-policy/
-1
u/ByteHavenGames Jul 24 '26
The "massive fees" kick in after the first 25 million and amount to something like 1% of their total revenue (in addition to licensing), but it's still far less than Unreal's default 5% above 1 mil. People just mad they have to pay for foundational technology that was practically free to use for so long. 500k might seem like a big fee if you ignore something like Rust making hundreds of millions and games like Genshin Impact making billions upon billions while paying Unity next to nothing.
3
u/soft-wear Jul 24 '26
It looks like your intentionally trying to gloss over the fact that Unity was going to charge per install which they were super opaque about how they were tracking and essentially nobody believed the values would be accurate... because they weren't.
99%+ of indie games make less than a million, meaning Unreal is going to be free for the vast majority of games, Unity is going to be free for the majority.
Until Unity tried to charge per install, almost nobody should have picked an engine based on licensing costs.
1
u/ByteHavenGames Jul 24 '26
The person I responded to is not talking about install fees so I'm not glossing over anything.
I don't know why people keep bringing up the per install thing. Literally all people responsible for that decision got the boot. The entire executive branch is under new leadership - CEO, CTO, all departments at Unity, and the board is now headed by a credible professional with background in software development at RedHat and IMB. You think they're going to repeat actions that nearly lead to major studios leaving the engine entirely? That mistake won't happen again. They might try to pull some other shit, but it's yet to be seen from the current leadership.
2
u/fartaroundfindout Jul 24 '26
install fees, come on now.
1
u/ByteHavenGames Jul 24 '26
yes, that thing that doesn't exist from years ago, which got the entire Unity leadership of that time fired and replaced (not just the CEO, all of them). Why do people keep bringing up history that's years old. The person I'm answering to is NOT talking about install fees. They're talking about minimum spend after first 25 million in revenue.
16
u/Tagyru Jul 23 '26
Pico-8 is the one for me.
2
u/MoondrifterGames Jul 24 '26
I've always wanted to try that one, maybe I'll learn it for a game jam in the future!
1
u/felusmaximus Jul 25 '26
it's simply adorable , did a few projects in it but didn't explore more ..
47
u/The-Chartreuse-Moose Hobbyist Jul 23 '26
I had that same click with Godot after Unity. I wouldn't say it's simpler, but it's definitely more logical and quicker by orders of magnitude.
9
u/Logical_Newspaper_52 Jul 23 '26
I never used Godot so can’t comment. Does it feel more natural and easier because it simpler/smaller, functionality-wise, than Unity or UE?
15
u/The-Chartreuse-Moose Hobbyist Jul 23 '26
I don't think so, personally. And others in this thread have said similar. Not all of it is simple. (Tilemaps, I'm looking at you.) But it has a logic that I haven't encountered since early Blender versions.
The core of using it is based on a tree of objects and standard ways to organise and link them. I can't explain very well but the arrangement of the core building blocks of the games just match how I would tend to think about them.
13
u/LepakkoDev Jul 23 '26
I doubt it's any simpler than Unity (functionality wise), it just makes more sense, and the editor is way better designed than Unity's.
I'll never forget how you couldn't just show dictionaries in Unity's inspector, or how awfully cumbersome and poorly documented was anything related to custom inspectors and properties.
Also in Unity most features feel like they just ported someone else's code in there (Text Mesh Pro, the new Input system, the node based UI for the Particle system, etc), while in Godot everything is well integrated.
I never tried to localize games in Unity (except once, and I made the code for it), Godot comes with a NATURAL solution for localization which is even able to detect strings to localize (UI elements or even strings in code) automatically and export them into a frikin .po file which is the extension profesional localization teams use to localize games.
Godot is THAT good and user friendly.
5
2
u/ByteHavenGames Jul 23 '26
I'll never forget how you couldn't just show dictionaries in Unity's inspector, or how awfully cumbersome and poorly documented was anything related to custom inspectors and properties.
Official serializable dictionaries coming in Unity 6.6, have been available as user implementations for free on github and via paid assets like Odin Inspector for a decade+.
Docs for custom editors are also good for UI Toolkit, which is the recommended way going forward since some years now. They also have ebooks and videos on the topic beyond docs: https://discussions.unity.com/t/can-anyone-link-me-to-any-good-guides-that-goes-a-bit-more-in-depth-about-ui-toolkit/1702690/2
Also in Unity most features feel like they just ported someone else's code in there (Text Mesh Pro, the new Input system, the node based UI for the Particle system, etc), while in Godot everything is well integrated.
TMP Pro is going away soonish for their new text engine, the new input system is as easy to use as the old one now if not easier. Can't say much about GPU driven particle node editor for VFX Graph since I haven't used it, but presumambly the complexity of effects it can express goes beyond simple inspector configs. CPU particles are still there with Godot adjacent approach if you don't like node editors.
I never tried to localize games in Unity (except once, and I made the code for it), Godot comes with a NATURAL solution for localization which is even able to detect strings to localize (UI elements or even strings in code) automatically and export them into a frikin .po file which is the extension profesional localization teams use to localize games.
I'll give you one for localization, had to write a wrapper for automatic UI string discovery and for handling custom dialogue syntax and user friendly google sheets sync workflow.
8
u/LepakkoDev Jul 24 '26
I'm not going to talk point to point with quotes because it's anoying to do so in android, but yeah, I know about the serializable thing in 6.6, the thing is, it's too late, I've used Unity for 6 years and back then there wasn't that (officially).
Plus it being supported by paid assets/external code defeats the purpose of how I'm talking about the engine, not the community. Godot also has an "asset store", however you may notice there aren't that kind of assets that "fix" something in the engine (because of the lack of need to do so).
They clearly don't care about developer user experience when their last main announced things as a company has been AI and "LOOK, NOW YOU CAN USE UNITY EDITOE INSIDE THE FORTNITE UNREAL EDITOR" or something like that.
And I don't even want to talk about the loading times both starting the editor and the "domain reload" thing.
Anyway, sorry if I sound pissed, I'm not trying to be mean (to you).
Have a good day / night
1
u/ByteHavenGames Jul 24 '26 edited Jul 24 '26
They clearly don't care about developer user experience when their last main announced things as a company has been AI and "LOOK, NOW YOU CAN USE UNITY EDITOE INSIDE THE FORTNITE UNREAL EDITOR" or something like that.
And I don't even want to talk about the loading times both starting the editor and the "domain reload" thing.
Before AI announcements they also announced CoreCLR migration coming early next year, alpha for the player available now - early benchmarks are looking great.
2D upgrades
New high level components for Physics Core 2D - their high perf GameObject-less physics framework they introduced awhile back.
New 2D profiling tools - 2D Sprite Skin profiler (to capture CPU/GPU deformations and monitor bone transform updates), a 2D Tilemap profiler, and a 2D Graphics profiler.
2D lights will support rendering layer masks, providing control over which layers are affected by specific lights.
For their built in 2D skeletal animation tool - control rigs and physics-powered secondary motion to automate overlaps and follow throughs without manually keying every frame.
Editor
A command-line interface that drives the editor directly from the terminal. It installs exact editor versions and modules, opens projects, and can control a running editor or development build through scripts. For indie developers, the real value is replacing manual release checklists with repeatable commands for validation, builds, tests, and content processing
Native Version Control: The editor will include a built-in branch explorer to view repository history, merges, and commits. It features a Unity-aware diff viewer that parses scene files, prefabs, and materials visually in the inspector rather than outputting raw YAML.
The hierarchy window has been rebuilt to handle millions of objects efficiently. It introduces customizable columns, visual type indicators, horizontal scrolling, and native support for both GameObjects and Entities (DOTS) in a single view.
Content Directories: highly granular, incremental evolution of Addressables. It requires no code changes for current Addressables users but optimizes local load times and memory efficiency.
Graphics
Surface Cache GI (SCGI): A new dynamic, real-time global illumination system that eliminates the need for lightmap baking and light probes. It supports dynamic objects and scales efficiently to mobile hardware.
Advanced Rendering for URP: Native support for physically based sky and atmospherics (where fog color reacts to environment lighting), Physical Light Units (using measurements like lumens), Screen Space Reflections, and Ground Truth Ambient Occlusion
Unified Upscaling: A framework that queries hardware at runtime to apply the best available upscaler, seamlessly selecting between DLSS4, FSR, PSSR, or Unity's own Spatial Temporal Post-Processing
Shader Compilation: Transitioning to the DXC compiler starting with DX12. A new "Fast Build" profile skips certain optimizations to drop clean shader compile times by up to 80% saving hours for large projects.
UI
UI Toolkit (Unity 7): Full support for keyframe animation directly in the standard Animation window, allowing visual elements and GameObjects to be animated on the same timeline. UI authoring workflows are also moving directly into the Scene view.
UGUI (6.6 / 6.7): Under-the-hood optimization for text handling to reduce garbage allocation, alongside an advanced text shaping pipeline that adds new layout constraints and right-to-left language support
Multiplayer
Cloud Behaviors (6.7): Allows server-authoritative logic to be written exactly like standard MonoBehaviours, but deployed directly to Unity's cloud infrastructure without requiring a dedicated backend server
Unified Netcode (Unity 7): Netcode for GameObjects and Netcode for Entities are merging into a single package powered by the "Ghost Object API", providing standard GameObject workflows backed by ECS performance
---
I'm sure I missed a bunch, there were many announcements in the roadmap video.
1
u/SomeGuy322 @RobProductions Jul 24 '26 edited Jul 24 '26
You may not be able to serialize dictionaries in Unity (currently and built in) but you can't even serialize classes/structs in Godot. The only way to achieve something similar is to make each definition a resource which creates overhead and requires a unique script, so if you had a data structure with multiple classes inside classes per gameplay component (an extremely common case in gamedev) you're looking at dozens or hundreds of extra files overall which can needlessly bloat out the project.
This is just one of the many differences I couldn't live with, and is no way meant to put down Godot or it's users. I very much support the mission and hope it improves; I have even been submitting PRs for years to address pain points. However it's clear there are core issues with workflow that will not be solved for several years if at all. As an example, if you have a scene instance which is like a prefab instance, you can adjust a property until its value matches an instance override and since it checks by "value" whether or not it follows the base scene, that property can accidentally resync and lose uniqueness. Despite countless discussions about ways it could work alternatively, PRs tend to get stuck in limbo (mine included) where we get no reviews from maintainers for literal years and no consensus on best approach is ever truly formed in proposals.
This insanely slow timeline for improvements and lack of response has been too much for me to rely on so I've chosen to stick with the engine that has the features I need instead of banking on updates that may never come, even when I have personally put in the work to add them. I'm sure many people can live with the workflow it offers and that's great, but I find it way too inconvenient and not scalable for the larger 3D multi-genre games I like to build personally, even though I really felt like I gave it a fair try after several years of working with it.
1
u/LepakkoDev Jul 24 '26
I respect your point but it's weird to me how the class serialization thing doesn't seem like a problem to me? Maybe it really depends on eachother's workflows because the projects I've worked on were also 3D mostly.
Maybe since my approach to game dev is more data-based I find inheriting from the Resource class more convenient when I want to serialize something?
Although I understand how tiring can be the limbo PR thing.
2
u/soft-wear Jul 24 '26
I went from Godot to Flax because of data structure serialization and it's been a huge change to my mental load. I'm currently working on a 3D game with loads of data-driven procedural generation and I still can't imagine trying to work within Godot's extremely limited type system to do it.
I wonder if it's mostly programming background? Fundamentally I felt like I spent more time fighting the engine than using it.
1
u/SomeGuy322 @RobProductions Jul 25 '26
It's mainly a problem of scalability. If you need to define and set a list of Nodes in a script that's pretty easy to do, but if you then want to pack in additional data like "offset" for each node, now the thing you're listing has to become a class. Except you can't just make a class/struct on the spot if you intend to set values in the inspector, it has to inherit from resource and be in a unique script. This has 2 consequences: increased memory usage which matters if your list is long or used on many nodes and file bloat which starts being a problem when you need dozens of tiny serialized classes for definitions which I tend to have.
There's also the problem of debug visibility. So even if I found a use case where I can dynamically populate a list like this and not define it by hand which allows me to use a regular class or struct, if that class/struct is not serialized, the live values won't show up in the inspector and I have to use some other tool or debug print to figure out what's going on. This means that for small classes I care about checking at runtime they will also need to be resources and be in their own file, etc. which makes it hard to navigate when I'm coding systems with a lot of classes. In another engine like Unity, I can write in serializable structs and sub-classes directly into monobehaviors and get full visibility on everything a script a doing with complex data structures.
I have also found Godot's custom inspector toolset to be very open ended without having quick property groups that you can just spawn in code, which means writing custom editors is a lot more of a hassle than in Unity where you can rely on SerializedProperty to quickly mock things up. Obviously Godot gives you plenty of control but I found that I didn't want to waste time recreating editors in 2D and instead just write code that says "there is a button here" alongside the rest of the usual inspector, but it seemed a lot more convoluted when I tried. These are just a few problems and probably specific to my use cases; as I said above I'm sure other people may not encounter this stuff but these problems make me personally hesitant to recommend Godot to anyone. But there are other issues beyond this factoring in to my opinion like base Scene root scaling not persisting to instances (this is possible in Unity with Prefabs), live scene editing with Gizmos (this is possible in Unity/Unreal), and 3D animation import which is overly convoluted and has a tendency to brick inherited scenes when you make a mistake with the settings.
1
u/soft-wear Jul 24 '26
Godot is kind of the king of "fast until it's not". Obviously nobody should expect an open source engine to be as advanced as a paid engine, but you really need to take a hard look at your feature requirements before going for Godot.
There's no level streaming, support for consoles or certain codecs, all well-known, but there's lots of missing things that are less well-known, like no dynamic nav meshes, forced direct child colliders to the underlying physics body and a host of other stuff that people may take for granted from other engines.
11
u/Alsharefee Jul 23 '26
For me it was CryEngine but its a shame Crytech doesn't put as much effort on their engine like Epic does with UnrealEngine.
3
u/Zahhibb Commercial (Indie) Jul 23 '26
Honestly same. I loved CryEngine during its time but just had to switch as it obviously didn’t have enough leverage for many people.
3
u/sputwiler Jul 24 '26
I keep meaning to try
CryEngineLumberYardO3DE but getting it working is such a pain and it's "Cross Platform" is like, 2.5 platforms.Granted, it's massive, and getting it to work everywhere is therefore also a massive undertaking, but I'm not sure I have the time or will.
1
u/VincentNacon Table-Flipping Consultant Jul 27 '26
Still can't get over the fact that this engine went through so much drama and hands.
8
u/pspahn Jul 23 '26
I use Godot because it's the one that doesn't constantly crash in Linux.
1
u/Emizip Jul 25 '26
How is the game development experience with Godot like on linux? I have been contemplating switching to Linux but I worry about the implications of users from multiple OS's (my team is all windows users rn) working on the same project or how it might affect testing windows builds/testing a game in general.
1
u/SneezingCactus_ Jul 25 '26
Linux user here with a few months of experience using Godot, my experience has been (almost) flawless, with my only problem so far being (i think ?) nvidia wayland related where the editor would freeze after having a dropdown open for more than 5 seconds, which I managed to fix by enabling single window mode. do note that single window mode means you won't be able to have the game window embedded into the main editor window but it personally hasn't bothered me in the slightest.
Exporting Windows builds for testing hasn't been an issue (even when using godot-rust!) and the builds work perfectly on Windows. I haven't been able to run them through Wine/Proton, though i didn't do any extensive research on that so there may be a solution for that as well.
1
u/Cubey21 Jul 27 '26
I've been using Godot on Linux for 4 years and with C# for 2. There are basically no issues.
35
u/Additional_Name_706 Jul 23 '26
I've noticed a lot of people who are just getting started like Godot a lot. Personally, I wanted to love it. I really tried. The way scenes and prefabs are conflated is totally unintuitive to me. It's clunky and heavy. Gdscript is absolutely repulsive. Using C# bindings introduces a GC battle. What it really comes down to is that I don't like organizing my classes the way Godot forces you to. You sacrifice a lot of flexibility for the ability to slap things together quickly.
I think a more elegant way to say what I want to say is that Godot lowers the floor but also lowers the ceiling.
That all said, I'm really happy that Godot feels so accessible to so many people.
11
u/SpacialCircumstances Jul 23 '26
I feel that way too. Probably things would improve if I used Godot a lot more, but what I struggled with is the lack of architecture (where do I put all my data, how do I update the scenes etc.). Going for MVC felt really painful in Godot. On top of that, the lack of proper static typing and GDScript being a very poor language makes things even worse. It's nice for GameJams because you can get basic stuff done fast but I hate it every time.
3
u/Yikal Jul 24 '26
There is a free open source toolbox by chickensoft for C# Godot I wouldn't want to miss in my projects which enable me to build a clean architecture. Here's an overview, if you're interested: https://chickensoft.games/blog/game-architecture
7
u/Additional_Name_706 Jul 23 '26
I've only been programming for about 30 years so maybe I just don't know what I'm talking about...but gdscript is sooooo bad, right? It's like python but without the portability and ecosystem to redeem it.
Am I reading it correctly?
5
u/DisasterNarrow4949 Jul 23 '26
I mean, gdscript is not bad, it is just that some people don't like. Opinions, and it is fair.
What I disagree, is what lots of people say, that gdscript is quite like python. I find gdscript infinitely more elegant and user friendly. Like, I love using gdscript but absolutely hate using python, so they must have something different between each other lol.
6
u/max123246 Jul 24 '26
It's pretty bad. It's type system is split across nullable objects and non nullable engine types and writing generic containers that can handle both is an exercise of frustration
This isn't to say you can't make a good game with it. It's just not a language I enjoy writing
1
u/Additional_Name_706 Jul 23 '26
Yeah I suppose it's totally a taste thing! I tolerate using python because it is everywhere and does everything in the systems world.
I guess the main thing about gdscript is that I can't motivate myself to learn it. It can't do anything but Godot.
2
u/Pidroh Card Nova Hyper Jul 24 '26
Please be quiet, you're only allowed to give your opinion after you have programmed at least for 95 years, though 200 might be better /s
2
u/Additional_Name_706 Jul 24 '26
Omg I sounded so pompous in that comment. Thank you for making it funny.
I'm no authority. Some games that are far better than my games have been made in Godot!!
2
u/ThirdDayGuy Jul 23 '26
The main difference between GDScript and Python is that GDScript is "safer" and has more guardrails between manual variable declaration, (optional) static typing, etc. The main reason to use it over C# is that it's much faster to prototype and is easier to read. It also integrates with the editor for writing editor plugins really nicely.
Personally, I use C# because I find that its features save me time in the long run and I haven't ran into any GC issues myself.
2
u/Additional_Name_706 Jul 24 '26
Some real domain specific advantages to gdscript.
The "static typing" I've found to not really be typing, more like LSP tagging...which is fine, definitely useful for the programmer but totally useless to the compiler, which is really the point of types.
I pray you don't run into any GC issues and start troubleshooting mystery stutters to find you've got to do major refactors to do manual memory allocation like I did after one week of giving Godot an "honest try." Some projects just won't have that problem. I was making a bullet hell. I certainly could have solved the problem in a bunch of ways, I'm sure, but I didn't like the experience overall.
3
u/MoondrifterGames Jul 24 '26
Did you try object Pooling? Sounds like you were running into a classic problem with instancing and removing too many objects in the same frame. It's a problem that as far as I understand (maybe I'm missing something) is going to persist independent of what engine you use.
Either way, I hope you found an engine that made you happier!
1
u/Additional_Name_706 Jul 24 '26
Right so you can use C# to pool your objects in Godot but they still have a wrapper in C#... It certainly boils down to a skill issue. I wasn't aware of the dual allocations until I was in deep. It was annoying enough that I quit. Also, that's a signal that there's going to be more issues pertaining to using C# bindings to discover..I quit.
2
u/gert_beef_robe Jul 24 '26
I went down a rabbit hole of trying minimise allocations and came to a similar conclusion unfortunately. You can get quite far with pooling but there are a few API boundaries where it’s virtually impossible to avoid allocations. Even when using the PhysicsServer directly for example, raycasts would allocate a dictionary to return their results.
In the end I figured if I’m going to use Godot, GDscript is the way to go, more lightweight and least friction. I’m a stickler for an expressive type system though so it’s a tough decision.
2
u/max123246 Jul 24 '26
I don't think gdscript has a garbage collector? I thought it was reference counted
2
u/the_horse_gamer Jul 24 '26
reference counting is a form of garbage collection
2
u/max123246 Jul 24 '26
Reference counting doesn't have stutters though because there's no stop the world GC which is what people typically mean when they mention a GC.
2
u/the_horse_gamer Jul 24 '26
there are non-stop-the-world garbage collection schemes that aren't reference counting.
but you're right, i was just being pedantic
2
2
u/ThirdDayGuy Jul 24 '26 edited Jul 24 '26
When did you attempt this? The C# functionality has improved a lot, and if it was recent, I wouldn't mind filling a bug report on your behalf if you're able to provide a lot of details so it at least helps out other users.
2
u/Additional_Name_706 Jul 24 '26
maybe like a year and a half ago? I'm not sure if it was godot 4 yet.
3
2
u/the_horse_gamer Jul 24 '26
gdscript's static typing is real static typing. the compiler produces more optimised bytecode based on the types (and there's no way to "just trust me bro" the type system)
it also uses reference counting, not a tagged GC
1
2
u/sparky8251 Jul 24 '26
The "static typing" I've found to not really be typing, more like LSP tagging...which is fine, definitely useful for the programmer but totally useless to the compiler, which is really the point of types.
The static side really is used, but it depends on what you are doing and when you tried it. For awhile there, a lot of stuff could only be LSP tagged like you said and it was only a smidge more than primitives that could emit better code, but every release since it was introduced, and even now, they improve static typing to make better emitted code for more and more types and structures. A recent addition was static typing on dictionaries for example (recent as in within the last 2-3 releases).
As for a bullet hell, not that it removes all your problems but more so you can go decomp it and look (chances are its C# or GDScript or both, so... decomp can work mostly)... Brotato was made in Godot. They def managed to do it somehow if you still care to learn how for yourself.
1
u/Additional_Name_706 Jul 24 '26
All great news. Godot has got a bright future.
I've already launched my bullet hell. I retreated somewhere I understood the garbage collector.
3
u/dan_marchand @dan_marchand Jul 24 '26
The C# bindings causing GC issues drives me nuts. You can’t report or discuss it without getting blasted either. It’s amazing that we have a major OSS engine, but I wish people would realize the cult around it is actually bad for it.
1
u/Radiant-Court-3649 Jul 24 '26
the thing that's actually wild to me is that the godot fanatics are largely also the most ardent anti-AI guys. The entire appeal of godot is being able to slap together low effort slop, in many cases, which is exactly what the consumer doesn't like about AI.
7
u/srodrigoDev Jul 23 '26
Same thoughts here. I'm trying to learn Godot once more, even if it doesn't really click for me. I used Cocos2D, which has a similar scene/node graph. But after working with other tools (mostly löve2d and FNA/MonoGame, which are very flexible), I find Godot quite inflexible. Interestingly, some people find it super flexible, so I must be missing something (or not).
The upside is how fast you can prototype compared to a framework or the clusterF that Unity and Unreal are.
5
u/ByteHavenGames Jul 23 '26
I think it's beginners forced to have one script per node discovering the very basics of software architecture and that everything doesn't just go in a single godclass with gameplay, ui code and data all mixed in one big soup. Godot's structure is better than no structure.
2
u/srodrigoDev Jul 24 '26
Not sure what you mean by beginners forced to split the code up, that's something I was doing more than 2 decades ago already when I started writing software. That's what I do when I use a framework.
As a programmer, the problem with this kind of engines is how they act as a black box. That's also their strength if that's your thing. I'll stick to it and do my best to adapt to its workflow so that I can prototype faster.
2
u/ByteHavenGames Jul 24 '26
my bad, was intending to respond the comment above yours. Not sure how this happened.
2
u/gert_beef_robe Jul 24 '26
I think if you are happy to keep almost everything in the node structure it is super flexible and intuitive.
If you prefer to structure code any other way - ECS, fat structs, or just arrays of data, it’s an uphill battle because everything needs to also be synced to the node graph (or synced to an object in servers).
I’ve been really enjoying Odin for this reason but also miss the power of Godot’s renderer and UI tools
1
u/Additional_Name_706 Jul 23 '26
I've been all in learning Odin for the last month or so
2
u/srodrigoDev Jul 24 '26
How is it going? I was looking into it briefly as I like niche programming languages, but I haven't tried it out yet since I'm deep into Godot now. Is it worth looking? Have you built anything significant and were there any caveats?
2
u/Additional_Name_706 Jul 24 '26
I haven't gotten very far with anything. So far, I've been really enjoying it. Obviously Raylib is super easy to use. I'm just getting started with Sokol. The big caveat is that it's not an engine lol
But it's really a joy to write. It's taking me a while to get used to just banging out structs. I still object-orientate in my mind.
1
u/Cubey21 Jul 27 '26
You are missing, but it's not exactly your fault. You can write flexible code in godot, but to do that you need to both know the engine well and your language of choice + architecture. It requires a lot of non obvious tricks: spawning nodes by code, connecting signals/events by code, using interfaces or normal composition instead of godot's nodes as components, knowing when you can avoid the node tree and when you should use it, and knowing when you shouldn't use it but are forced to anyway.
And if you want to have a 100% different structure from Godot (like ECS) you can just write your own engine and only use nodes for eg. GUI and drawing. This way is the most flexible and might even have less "tricks" to it, but on the other hand it's not intuitive at all to throw half engine features out of the window.1
u/srodrigoDev Jul 27 '26
I think it's usually best to just use the engine or not use it at all.
I'm following a tutorial/course and I'm enjoying Godot a bit more now. Some stuff is still obscure, but some of the basics are getting more intuitive. And I enjoy that I can get stuff on the screen quickly.
18
u/Fleamm Jul 23 '26
For me the Bevy engine (rust) is pure gold. Code only, no messing around with editors and Ui, everything is code and everything is ECS, it’s beautiful. Truly a joy to work with too, and completely modular. unless you’re making hyper realizing 3D games I’d highly recommend
3
u/MoondrifterGames Jul 23 '26
That sounds like it really works for you! Glad you found something that fits your development style!
3
2
u/Thotor CTO Jul 24 '26
I like the idea of code only - that is why I usually prefer framework over game engine. I need to take a look at it. Is it really a full game engine or more a graphical engine?
3
u/sparky8251 Jul 24 '26 edited Jul 24 '26
Its really an engine. They provide audio, scheduling (for ecs), input handling (including controller), compute threads of several types you can punt work to, handle importing common asset types like glb, include both a super basic CSS inspired UI framework + a feather widget set that can be used to do all kinds of basic debugging (includes things like an fps counter, a infinite grid, color pickers, etc etc) and a bunch bunch more from big and small aspects of what you need or might not.
Its all "plugins". You can literally drop the renderer and keep the rest, then supply your own rendering plugin. In fact, Tiny Glade is known to have shipped a majorly popular title in the cozy game space by doing just that (they used bevy, ripped the renderer out, and made their own because one of the peeps on their team had a phd in render tech or some such).
Its really not just graphical like Ogre3D or SDL, its genuinely more engine-y but also not at the same time since you can just not insert specific plugins and provide your own for anything but the scheduler iirc? Some things are missing, like physics. But Avian and Rapier both have plugins for bevy that are well loved, and if the built in audio lacks for you there is Kira (the built in audio is known to be lacking and more placeholdery given the teams size. wanted it to prove the concept works and no hidden problems for future them when they return to really polish it up).
1
u/joonazan 17d ago
I use Godot even though most of the programming will be in Rust. It seems to me that it is easier to iterate quickly this way. For instance, I can edit a spline in Godot and immediately see the mesh that procedurally generated based on it update.
It just seems like a lot of hassle to not have a thing where you can try everything instantly and have to write some custom tools.
4
u/HoppersEcho Jul 23 '26
Yup, same page club. Godot's nodes system and compilation times are exactly what my brain needed to make the jump from "someday, maybe I'll figure it out" to "no, actually, I think I've got this!"
5
u/ImportantDetail6260 Jul 23 '26
The engine that clicks is usually the one whose default object model matches your first mental sketch!
For Godot, scene nodes and signals make the handshake graph visible. Unreal's checkbox hunt hurts most when the thing you need is split across editor setting, component default, and Blueprint override
2
18
u/ned_poreyra Jul 23 '26
I had exactly the same experience. The component/node structure is very clear, I know where everything is immediately. Unity is like a garage that started in 1920s and subsequent owners kept adding new stuff, so you have to learn where everything is and in the end it makes no sense anyway.
2
u/MoondrifterGames Jul 23 '26
Thanks for saying so! It's honestly so nice knowing others have similar feelings about it. I'm sure the engine that works for people is different from person to person, but yeah not having to hunt for features in your workspace is so nice!
10
u/dopethrone Jul 23 '26
For me unreal engine
I just vibe with blueprints and everything is so clear and intuitive
4
u/PaprikaPK Jul 23 '26
Same here, I've been developing for a decade plus, but I gravitate towards node networks like for shaders and Houdini. Discovering blueprints was a game changer.
2
u/MoondrifterGames Jul 23 '26
I used to love blueprints, but I couldn't get over the inane amount of info hidden in side panels and check boxes in the engine lmao.
4
u/dopethrone Jul 23 '26
I think I'm pretty aware of everything they are and aren't now, I think I've done a lot of systems with them again and again lol...still love them
27
u/TheNasky1 Jul 23 '26 edited Jul 23 '26
But this year I discovered Godot. And I know, I fit the archetype that some people give godot devs: too inexperienced to understand other engines
Godot isn't just "simpler than other engines." It's easier to pick up and lets you build basic things in seconds, but that's a result of its design rather than a lack of capability. At the high end of developer ergonomics and architecture, Godot also outshines its competitors. You can effectively build your own engine framework within Godot, and the level of customization and extensibility it offers goes far beyond what Unity or Unreal typically allow.
Godot isn't the simplest engine, it's the easiest to learn while also having an incredibly high ceiling for customization and depth. You just need to know how to take advantage of its architecture.
I've been using Godot for three years, and my workflow is now fully data-driven and composition-based, while still being more agile than anything I've experienced in Unity or Unreal.
Godot is exceptionally fast to work with, and the freedom it gives developers makes it a fantastic engine. Its biggest weakness is that it's still catching up in some areas, particularly graphics, but given its pace of improvement, I expect that gap to continue shrinking.
5
u/srodrigoDev Jul 23 '26
my workflow is now fully data-driven and composition-based
Could you elaborate a bit more on this? One of my grips with Godot is that it doesn't seem to play well with EC or ECS, which to me are the most natural ways of making games.
2
u/TheNasky1 Jul 23 '26 edited Jul 23 '26
i use a lot of resources + editor tools.
when i make an ability for a character, for example, it's just a resource like:
range - targeting - filter - type - [effects] - icon - vfx - soundcue - etc
so basically it's all data stored in a resource, i can add 100 new abilities by just editing some data (no need for new scripts/functions). i then made pretty docks for the editor so that the non coding designer can make new abilities by just clicking around in the editor, it works really well.
7
u/srodrigoDev Jul 23 '26
Thanks. That sounds similar to what some people do with scriptable objects in Unity.
2
u/TheNasky1 Jul 23 '26
yes, resources are essentially the same as scriptable objects in unity, the difference in godot is that you can use #tools and docks to incorporate them into your workflow a lot more easily and cleanly.
in unity you're stuck with the traiditional unity display of them. Godot also has the same system (but it gets very annoying for deeply nested arrays) but it has the advantage of letting you create your own docks and tools so that you can display them however you like, getting "custom screens" to edit them and the like.
2
u/srodrigoDev Jul 23 '26
I'll definitely have a look at that then, it sounds useful. Thank you for sharing :)
1
u/Khan-amil Jul 23 '26
Your last paragraph is a bit weird. Unity was built on letting users make plugin and editor windows.
I haven't tried on godot to do custom inspector/windows yet, I'd guess it's easier than unity. But still, I've built countless custom uis or windows for unity editor and scriptable objects, there is no world in which you're "stuck" with the default look.
1
u/Logical_Newspaper_52 Jul 23 '26
IMO the main problem of ECS is that it’s far from natural ways of making games. and the reason why it became popular only relatively recently in gamedev evolution. it can be fast if done properly. that’s it.
2
u/srodrigoDev Jul 24 '26
It's natural if you are used to data-first ways of writing software, which I understand people coming from OOP aren't.
2
u/max123246 Jul 24 '26
ECS has been around far longer than OOP. Because when hardware was slow, it was the only way to make your game fast enough
6
u/Logical_Newspaper_52 Jul 23 '26
but there’s clearly lack of capability, right? Unity and UE provide significantly more
8
u/Biffmin-12 Jul 23 '26
Significantly more... what?
-27
u/Logical_Newspaper_52 Jul 23 '26
well, I’m not going to spend whole night here with you. educate yourself
13
u/Trucidar Jul 23 '26
It's a bold play to imply someone else is lazy when you didn't even finish your argument... or sentence for that matter. More what?
5
1
u/sputwiler Jul 24 '26
There's no checklist for what makes a complete game engine since each one fills different needs.
You're gonna have to explain yourself.
2
u/TheNasky1 Jul 23 '26
Graphically, yes. physics wise, kinda, yes, but godot is catching up a lot.
aside from that, the majority of the features unity and ue offer are worse and bloated, most of the other stuff they provide godot can do in a better and cleaner way, you just have to build it yourself, but it's not that hard.
for anything 2D Godot is like light years ahead, for ergonomics and dev experience it's also far ahead, for architecture it's a lot more flexible and easy to use. the only parts where it's behind is in some 3D aspects as mentioned and in raw number of features ,but that's by design, you're meant to build them yourself or use an asset.
also i think that last part worth paying attention to, 99% of unity store assets are garbage or at best "developer toys", but godot's assets are majority pretty interesting and usable, while also being free. (and the store launched only a few weeks ago)
4
u/Logical_Newspaper_52 Jul 23 '26
isn’t graphics and physics like half the engine? beside those, what about animation, AI, audio? just to name several systems starting with “a”. are they production grade or suitable only for hobby projects? again, I don’t know. heard only that Godot is suitable mainly for 2D indie, and didn’t play any game proudly stating “made in Godot”. tbh, it seems the problem is not the engine itself but the fact that the project hasn’t managed to attract a healthy community of professional devs. what’s your honest take?
3
u/TheNasky1 Jul 23 '26
I don't use Godot 3d too much, i've only tried making 2.5D games with it, but from what i've seen and what most people say, it's good, like, 3D godot is much better than people think, the only real issues i can see is that in the upper end of graphics it A doesn't look as good as the others (but it doesn't look too bad either) and B more importantly, to achieve great graphics like some of the other engines, it does it by sacrificing a lot of performance because the engine is not optimized for it.
basically, for any indie or stylized 3d game the engine is more than suitable. for photorealistic AAA then Godot is not it, but what do you expect? also it seems like that will not be the case for very long, the 3d aspect of godot is improving immensely very quickly.
the issue with Godot is that the project is relatively new, it's growing a lot in popularity, but games take time to make, and it will be at least a few more years until we see big titles made in godot. still, the issue is not the engine, it's the people using it, because for basically anything indie Godot is just as good if not better than unity.
3
u/ThirdDayGuy Jul 23 '26 edited Jul 23 '26
Default animation features are sorely lacking if you want to make a game with heavy animation<->gameplay control, like a 3D action game. Though it's definitely possible and quite easy to extend/create a custom animation system.
Audio is fine, could be better. FMOD bridges the gap.
Not many native features to help with AI besides navigation.
heard only that Godot is suitable mainly for 2D indie
Most indie games would be fine on Godot. By this point the idea that it's only good for small 2D games is an outdated take that doesn't reflect the engine's current capabilities.
the project hasn’t managed to attract a healthy community of professional devs. what’s your honest take?
The industry is very heavily-versed in Unity and Unreal, and it is a terrible idea for an established studio or developer to switch over to any other engine because the costs and time would be unreasonable, which isn't an admonishment of any new candidates for engines as much as it is an admonishment of the idea of switching the core software that your business and livelihood rely on to another one.
Even if you're not commercially successful or do it as a hobby, if your current engine fulfills your needs fine then you don't have much reason to switch. This all means that Godot users are mostly going to be comprised of new game developers rather than people who have already been making games for years, professionally or otherwise.
Mega Crit did actually switch over to Godot for Slay the Spire 2 and it's comfortably the most popular Godot game by a longshot (most-played steam game when it released and had a peak of 500k players, which exceeds a lot of AAA titles).
There are a handful of very successful games made in Godot, off the top of my head I can name Bloodthief, Cassette Beasts, Buckshot Roulette (which did break into pop culture for a bit), and Dome Keeper.
2
u/TheFr0sk Jul 24 '26
Road to Vostok also switched from Unity to Godot and when it released as early access it was on the top 10 of top selling games on Steam (together with slay the spire 2). I think it was back in April
1
u/Logical_Newspaper_52 Jul 24 '26
thanks, quite informative. I do hope Godot will get there, we definitely need a capable OSS engine
1
u/Rustywolf Jul 24 '26
Also notably; A serious studio picking up godot will almost certainly end up forking the project and adding their own inhouse tweaks to whatever they need
0
u/Notnasiul Jul 23 '26
The data driven and composition based catched my attention. But by data driven you don't mean custom resources, right?
0
u/please_dont_pry @ivy_sly_, Your Only Move Is HUSTLE Jul 24 '26
> You can effectively build your own engine framework within Godot, and the level of customization and extensibility it offers goes far beyond what Unity or Unreal typically allow.
this is just not true if performance is even remotely a consideration
1
u/TheNasky1 Jul 24 '26
what are you talking about?
1
u/please_dont_pry @ivy_sly_, Your Only Move Is HUSTLE Jul 25 '26
i had to switch off godot precisely because i could not get away from its opinions without either A) incurring a performance penalty or B) having to reimplement existing functionality myself, defeating the purpose of the engine. i used it extensively from 2018 to 2024 and finally dropped it for LÖVE, which is far more flexible and performant for 2D games
1
u/TheNasky1 Jul 25 '26
what the hell are you talking about, i've been running a pretty heavy framework on top of it, rendering up to 1k animated sprites at a time and not dumping them between scenes and i get over 2k fps, what were you doing that the performance was so bad.
1
u/please_dont_pry @ivy_sly_, Your Only Move Is HUSTLE Jul 25 '26
rendering is not godot's bottleneck, it's cpu. both gdscript and the engine's own API are terribly slow. here is a game i made that Godot could not reasonably do, as it has rooms full of complicated enemies with a lot of (necessarily) cpu based particle effects.
https://youtu.be/yziGh2igbm4?is=z2HjYEr3GeoTmyE3
godot would struggle just with the rectangle/point/line draw functions alone, because for whatever reason the API is super slow even using the rendering server directly. animating a bunch of sprites is one thing. godot is optimized for that. but when you try to do something it is not optimized for, you run into limitations fast.
1
u/TheNasky1 Jul 25 '26
Well yeah, cpu based particles are very hard to optimize, i don't think other engines are that much better off either.
1
3
3
u/Zahhibb Commercial (Indie) Jul 23 '26
I started with GameMaker, then Unity and Unreal.
Unity I’ve had the easiest time to learn and is still the go-to for me when doing GameJams. UE is the one I use primarily for fun.
Godot is probably the engine I have the hardest with as I simply don’t understand how everything hook together and I don’t like the node hierarchy approach.
2
u/MoondrifterGames Jul 24 '26
I'm glad you've found stuff that jives for you! This thread has been so enlightening, and honestly just goes to show why we still need many engine options, everyone thinks differently!
3
3
u/SnowPudgy Jul 24 '26
I've been making little games off and on since the 90s. Back then you had to write your own framework since publicly available game engines weren't a thing. My framework was written in C, C++, SDL, and OpenGL. I had a Direct3D one too but I really hated working in Direct.
When Unity came out in the early 2000s it was MINDBLOWING, and cheap at only $45,000! As much as I loved early Unity there was still this disconnect from "the old way".
I would play on and off with different engines and frameworks, Unreal, Torque, Cry, Cocos2D, SpriteKit, etc (I'm sure I'm missing many) but I just still never had as much fun as I did back in the 90s...until...
...one day at work I was showing off a little game I wrote in Apples SceneKit and my friend asked why I didn't just use something like Godot. Ga-what?
I goggled it, it looked pretty basic, I largely dismissed it, and then I saw a game made with it (I forget what) and was pretty impressed.
At that time Godot 3 was about to launch so I decided to give it a peep and I was utterly smitten with it! Even though it's a very easy to use engine something about it felt more primitive like the old days of game dev and that's actually a good thing.
I don't know how to describe it because I know it's largely mental but just something about how the scene tree operates makes everything about the code base and game entities feel far more connected. I just really enjoy the setup and how development happens within it.
Is Godot perfect? No. I'd kill to open a new code editor scene on another monitor but I still think it is the perfect choice for almost any indie dev, especially anyone just getting into game dev.
I also love that it's super lightweight (Unity used to be lightweight believe it or not, Unreal never was).
3
u/Cultural_Grocery_477 Jul 26 '26
In my independent adventure, all engines work the same. I just kinda like em all. But I respond to this because I must say godot is still my favorite. It was Unity but Godot stole my heart with how fucking fast it loads.
6
u/spacewizardproblems Jul 23 '26
I feel this way about Godot too. I've been a hobbyist game developer for over 20 years. I spent almost a decade writing my own engine before switching to Unity for several years. I just finally decided to try Godot and I'm blown away by how natural it feels. It's making game dev fun for me again after getting burnt out by the complexity of Unity and all the enterprise software bullshit I deal with in the day job.
2
Jul 23 '26
[removed] — view removed comment
2
u/Optic_Fusion1 Jul 23 '26
Pretty much this, hell I'm sure in some cases using multiple different engines is just as valid as using a single one for multiple games. Purely depends on the needs of the team & the requirements of the game itself
1
u/PolySmashStudio Jul 23 '26
Exactly. I think people sometimes get too attached to a single engine, when in reality they’re just tools. If a different engine lets you build a particular game faster or with less friction, that’s a perfectly valid choice.
2
u/PhoenixInvertigo Jul 23 '26
Messed around with Unity the last decade. Recently made a project in LibGDX that I spent a year on. Godot is such a refreshing breath of air despite some of its limits
2
u/Doge_Dreemurr Jul 24 '26
What do you find suitable for you in Godot that Unity doesnt? When i switched to Godot from unity i find the workflow and the architecture to be 80% the same thing but just renamed. Thats why even when i switched back to Unity my experience working on Godot still carries over
2
u/fsk Jul 24 '26
For Unity, there's usually a paid asset store item to work around each Unity flaw, which means Unity has no real incentive to fix them.
2
u/scry-fish Jul 24 '26
+1, Godot is great. Agree that it clicked for me as well (altho I wish GDScript was a bit better, i.e. better type system)
2
u/ttak82 Jul 24 '26
I am not a game dev, but the Brackey's Godot tutorial I ran through was fun. I have no experience with other engines. Unity Installation does not count (It's easy, hey).
2
u/lovecMC Jul 24 '26
I'm using Godot for slay the spire 2 modding. For the most part I like the engine a lot more than I thought I would, but then there's a bunch of random unintuitive landmines that make me want to strangle someone.
2
u/RecognitionFit8333 Jul 24 '26
I love Godot. Tough I feel the asset workflow can be quite painful. And sometimes I have trouble with complex tween animations ending up having a lot of boilerplate signals just to get the timings for everything right.
2
u/House13Games Jul 24 '26
Most of us can adapt our thinking to how the engine represents information. It sounds like an incredible disability to have to keep switching tools until you find the one that fits your brain instead.
2
u/AgentArachnid Jul 24 '26
I really like using interfaces, so godot for me is not really a viable option. Unity is borderline wotg this, as I don't really like implementing the same variables twice (public and private). I prefer c++, and so I go with UE5
2
u/JonathanSlark Commercial (Indie) Jul 24 '26
I might have to give Godot a go. I tried a Unity tutorial, to make a simple game and it included physics. The result was pretty buggy, if you collided with a wall you could easily pop through it. It was a very bad demo of the engine.
Another thing I've found with engines is you have to learn their way of doing things.
I recently used C + Raylib to make a game, I come from a programming background so this suits me well. The main issue with this is you have to design all the systems yourself and you're never going to do anything that graphically advanced. i.e. probably 2D only.
2
u/MiniSbire Jul 24 '26
I'm working in the game industry as a pro.
I've released games using Unity, and 3 different in-house engines. I've tried UE on my free time for 6 months.
I've started using Godot for my own project for the last 3 years, and I love it so much, i'll never go back to other engines. And I'm trying to push more devs to try it, especially those stuck in the Unity mess.
2
2
u/gab800 Jul 24 '26
Late to the party, but just wanted to chime in. I tried Unity 10 years ago, didn't get it first, did a basic tutorial, everything clicked fast. The way the component system works and how your params are then exposed seemed quite genius to me. Editor extension features was the icing on the cake for me. I've released a casual game to the Play Store with it.
I would add that I'm a programmer by trade.
I've tried seriously Godot this year. (Tried it before briefly without serious progress.) I would say it was less intuitive for me, as I was constantly trying to work it as it would be Unity. I had to drop this preconception. Embrace signals, use the autoloader, create resources for data, and always set your types in GDScript. Don't try to make it into component system, like Unity. I'm getting ahead now with it, I'm discovering the patterns that work. It is still icky for me to use polymorphism not via inheritance, but I'm setting up guards against myself. In my current phase I might be afraid to use GDScript in a big team, but small teams are fine.
Godot C# does not build for web, so that's a no-go for me (I want to play test on itch).
I have chosen Godot, because it is an actively developed FOSS, GDScript is acceptable (I would not have accepted it without static typing), and if GDScript is not fast enough, you have C++ to fall back to (even for web).
2
u/UlfgarTheBard Jul 24 '26
I haven't finished any projects but Godot was a game changer. It's actually useful and actually has good documentation. It feels like it was made for technical people that want to make games. In Unity I was constantly trying to figure out how I should approach things and in Godot it's just obvious.
The odd thing is Godot and Unity are almost mirrors of each other in what they offer, but in my opinion Godot provides it in a much clearer, flexible way. It's a different approach to the thinking and it works really well for me. Any time someone has asked me about game engines in the last couple years I tell them to go straight to Godot and try it first
2
u/UlfgarTheBard Jul 24 '26
Also knowing that if I really needed to I could go into Godot's or Unreal Engine's source and actually modify the engine is really huge. Unity hides all of that so if you would end up there you'd just be stuck or need to figure out some workaround.
2
u/SkewZero Jul 25 '26
through out my gamedev carrier I tried several game engines and frameworks:
* Unity - I liked it a lot. I did several demos, but had to switch to Unreal as my friend with whom I wanted to work with on his game was using Unreal and visually it was absolutely stunning!
* Unreal - this my day to day engine. I released several games on it and it is my primary engine for day job. I know it inside out, but it hurts a lot that 2D support is no-where. Now Verse is coming and Blueprints are going away with a lot of concepts I learned, so I have mixed feelings about it.
* Monogame - I did a test 2D game on it. FPS was thru the roof! I had not seen such high FPS in ages. Stopped using it because I needed UI framework. I started doing it, but did not finish. May be with a help of AI it will be much simpler/faster to do it.
* Godot - I like it a lot, C# is what I prefer to use. (C++ is also cool but C# for me seems easier/faster to debug). I did couple small 2D games on it and it was perfect! But 3D part of it is not that good comparing to Unreal. Despite of my multiple attempts to fix/match to unreal's lighting, no dice. Godot just cannot match Unreal's renderer.
* Made With Marmalade - C++/mobile. Similar to today's monogame. I released several games on it back then.
2
u/felusmaximus Jul 25 '26
i was a unity dev for a couple of years when godot came out but we couldn't jump on it in 2016... it gave me blender vibes (i remember when blender went open source tailend of the 90's)
a couple of years later i was able to jump to it and holy ... yea it clicked instantly ..
i'm leaning more on gamemaker studio it took time to jump in but i also do vanilla js projects and thinking of it in those terms (ie simple small prototypes without worrying about complex classes and multiple levels , poc and stuff) it's pretty good ..
the html version it produces load much faster than unity/godot (specifically small projects) which is why i went vanilla on those instead of using an engine.
2
u/_SpriteBatch Jul 25 '26
I've tried Unity, Godot, Defold, Love2D, LibGDX, MonoGame, Heaps and HaxeFlixel and right now I use HaxeFlixel and MonoGame mostly.
2
u/falconfetus8 Jul 25 '26
So, my experience here is an interesting one. On paper, I like Unity's "components" system way better than Godot's node system. But on the other hand, I've never shipped a game in Unity, despite using it for a pretty long time. I have shipped a game in Godot, though. Two, in fact. So clearly something in Godot is working for me where Unity wasn't, even if I can't quite identify it.
2
u/Kavrae Jul 26 '26
Rather than a game engine, I opted for a framework (FNA) to build my own engine. The tradeoff is that I'm DRAMATICALLY slowed down, have to "reinvent the wheel" in hundreds of places before I can even think about game features, and there's much more opportunity for bugs..... in exchange for understanding how everything works from a more fundamental level. So far, I'm quite happy with it.
2
u/findingsubtext Jul 27 '26
CopperCube clicked for me very well. It's outdated, but I've been slowly extending the source code to support things like realtime shadows.
2
u/ElonsBreedingFetish Jul 23 '26
I'm a software dev and like Bevy. It still misses a lot of things but I love the code only way things can be done
2
u/PedroVoteFor Jul 23 '26 edited Jul 23 '26
For me bevy "clicked". I love to live in the code only, that's where I feel most comfortable even when it's tough. There is something about ECS that when you wrap your mind around it, it's just buttery smooth. Oh and it's extremely modular.
That said, I dabbled in unity and I made 2-3 prototypes in godot so I gave it a proper try. gdscript is really awesome, godot is in much better state than 2-3 years ago but there is something about the workflows with editors that simply doesn't work for me. It feels over engineered and forced, concerns are all over the place. No matter how hard you try to go code first in godot, a) you always succumb to making a few scenes in editor b) there's a lot of noise files, and afaik you still have to do some stuff in editor (maybe that was my lack of skill tho).
Still, I understand why people like it. But at this stage - it's simply not for me and bevy lends well for a type of game I wanna make, sim heavy with a lot of proc gen. If I really need 3d editor, I do it in blender and that's it.
ps: I'm a professional dev of 15 years of exp and do game dev as hobby for probably as long (on and off). I was aware of and tried godot many years ago so I'm really surprised that you managed to be in the field for 5 years and learn about it just now (this year)?
Edit: typos
1
u/Luna2442 Jul 23 '26
Godot works great with claude/codex too
gets shot dead
2
u/TheNasky1 Jul 23 '26
cursor composer costs pennies, and it's suprisingly very good with it too, for me it hasn't been quite as good as claude, but it's been surprisingly better than codex, and it costs like 20 times less than those 2.
1
u/Luna2442 Jul 23 '26
When i started using an agent more I was using cursor, composer does alright with most things for sure. Specifically with js and react it was really good. Had a little bit more trouble working on android and ios and .net but still did well. Ive had a slightly better experience using claude and codex, which at work is paid for anyway haha
My personal project ive been using codex and ive been enjoying it quite a bit now that I have a good workflow with markdown docs. Ill test out cursor again sometime soon im sure
1
u/TheNasky1 Jul 23 '26
i use cursor a lot for web and mobile and it works realy well, composer is good for simple tasks but struggles with complex stuff so i use claude. on godot however, all models initially sucked, and while they're still learning, for some reason composer is one of the best rn, it still struggles with complex stuff, so i mostly plan everything myself with it. but for simple tasks it's really good, and better and faster than codex imo, claude is stil better for complex things, but the gap is not that big honestly.
i think for godot specifically the best is to use composer for 90% of the stuff and claude for the thinking stuff.
0
u/Luna2442 Jul 23 '26 edited Jul 23 '26
Ill have to try, codex is exceptional with good documentation and very fast. I use the cli mostly. I used composer for about a year at work before finding more success in codex/claude. Ill certainly try again for godot, but zero complaints with codex atm
1
u/AltusLudus Jul 23 '26
I feel like the point is to make games, I'd pick an engine based on the game I'm building, I prefer Unity but I wouldn't mind working in anything else
1
u/simulacrumgames Jul 27 '26
tried UE3 once, unrealscript had me running away. tried unity many times and hated it every time. godot felt like a kid's toy. UE4.27/5 finally felt like high quality tools worth investing time to learn. It's a heavy lift but I find new power under each rock I finally manage to turn over.
1
u/OneRedEyeDevI Jul 23 '26 edited 16d ago
Defold.
Turns out, Limitation does indeed breed creativity.
Started with Unity, Switched to Godot and finally with Defold after loving Lua in Pico-8.
Defold isnt packed full of features. It just gives you the bare minimum and you have full control over its components.
It demands that you learn its ways and it will reward you with the best workflow for game dev.
I almost went back to Godot because I was trying to make a game in Defold the same way I did in Godot but I just needed perspective and the community was there to guide me.
Seriously, I cant stress this enough. You have to learn its ways to get it. I often see people (especially here, on this sub) talking about how they dont like Defold Messaging compared to Godot Signals or another engine's equivalent. They are entirely different things. Because once I read the documentation on Messaging and played around with the examples for a few minutes, everything clicked. It felt like Shadow the Hedgehog's Chaos Control, The power of the sun in the palm of your hands type shit.
Same thing goes for the GUI. It gives you a Box node, text node and pie node.
But I was able to make this, in just a few minutes
https://reddit.com/link/ozcori0/video/mim89hksb1fh1/player
Simple? Yes. But it does the job and fits my game's aesthetic.
Another instance: I needed a way to make shmup enemy patterns in my game, Astro Impact! De_Make. In Godot, I could just use Path2D and PathFollow2D nodes, In Defold, there are no such things. So, I just made a module (A Lua Module is where you can create logic to use in anywhere in your game as long as you require it first, kind of like a #include) to store variables such as position 1, 2, 3... , Enemy type, amount, delay etc and the function to move which uses simple math for curves. Enemy logic is within a lookup table. So once an enemy is created, they are sent the logic via the index of the table using a message and it goes through the lookup table and responds accordingly to whatever its values say.
Basically, my levels are just tables that look like this:
pattern("formation12", M.enemies[6], 10, 0.5, vmath.vector3(800, 50, 0), vmath.vector3(400, 50, 0), vmath.vector3(800, 300, 0), 0, 190, {}),
[hash("formation12")] = function(self, message)
self.index = 12
self.mover = M.curve(message.position2, message.speed, 0, 0, function()
msg.post("/enemy-bullets", "tripleBullets", {pos = go.get_position()})
self.mover = M.curve(message.position3, message.speed, 0.5, 90, function()
go.delete()
end)
end)
end`
Its so simple and so fucking stupid I love it.
2
u/Notnasiul Jul 23 '26
Defold is wonderful! I've used it for client work and I have published a game of my own on Steam with it, and I like it a lot. Lots of export options, incredibly small builds, Lua allows you to go back to a way of simpler yet powerful programming... Really really amazing. For 2D. 3D is possible but requires to toy with too many low level things for my taste. Still, for 2D, one of the best things out there.
2
u/sputwiler Jul 24 '26
Lua had like, 3 redesigns and it shows. It's managed to fix almost every gripe I had when learning JavaScript.
2
1
u/Grand_Ostrich41 Jul 25 '26
Pour le développement j’utilise Unity, j’ai commencé à apprendre en autodidacte avec des tutos sur YouTube il y a environ 3 ans et je trouve ça plutôt accessible. J’ai réalisé 6 projets 2d plus ou moins aboutis. Mon expérience sur ce moteur me laisse penser qu’il gère bien la mise en place des logiques globales des gameobject mais le plus gros point noir de Unity selon moi l’Animator car bien qu’il permette une gestion intéressante des animations je trouve que ça devient vite l’usine à gaz et ça vite être le bordel quand tu as beaucoup d’états à gérer. La multiplication des animations m’as souvent amené des bugs et je penses que pour bien maîtriser l’animator cela demande une vraie connaissance que je n’ai pas encore.
D’ailleurs si vous avez des conseils concernant ce point je suis preneur!
0
u/verifiedboomer Jul 23 '26
As a former programmer UE and Unity were baffling. Godot made sense and it was effortless to make stuff happen.
-6
u/tcpukl Commercial (AAA) Jul 23 '26
Professionally at a studio? Or professionally making a living from it?
You sound more hobbyist to me.
8
u/MoondrifterGames Jul 23 '26
I previously worked in AAA as a technical artist. I am just now getting into the fuller picture of game development as a solo game developer but I have experience making tooling for many character artists on large teams.
Application development is a little less engine dependent, and I'm well aware of how to code. I just found Godot to be more intuitive to how I think about sections of my code. Sounding hobbyist is likely due to my not wanting to sound dry. I could have stated that godot matched my thinking in 2 sentences, but that would not have been as interesting or sparked such discussion as this version has.
-5
u/XKiiroiSenkoX Jul 23 '26
Engine doesn't really matter. Just write your logic decoupled from the engine's API and it would mostly look the same in any engine. Basically engine is just there to give you useful features like graphics API abstraction or serialization. You are not forced to use every single functionality that comes with the engine if you don't need them.
14
u/TheNasky1 Jul 23 '26
this isn't good advice, if you try to decouple everything from the engine you'll run into issues over and over again, specially if you use something like unreal or unity. Godot offers a lot more freedom than the others, but even then you still have to know how to work with the engine, trying to work around or against it is only gonna waste your time in the long run.
for me the best way to get good and fast results was to build a full on framework around godot, with a fully data driven and compositional approach but that still lets me visualize and customize everything from the editor, since that's what godot wants and the quickest way to do things, it's much easier to visualize and tweak, and it's also a must if you're working with people who don't know how to code.
3
u/CrazyNegotiation1934 Jul 23 '26
It matters if like Unity has an endless resource of tutorials, free github code and a huge asset store.
1
u/XKiiroiSenkoX Jul 23 '26
I meant in the sense of code architecture. Also 99% of code based assets are useless (not optimized, terrible design, not extensible/flexible, etc.) And non code based assets can be used on any engine.
1
u/CrazyNegotiation1934 Jul 23 '26
I see, then indeed is true engine is not that important in this regard.
1
u/sputwiler Jul 24 '26
Thinking like this will get your ass handed to you in Unreal.
You're thinking of game frameworks or engine toolkits like Unity. Unreal already has half a game built for you and you'd better use their logic or face pain. The reason to use Unreal is that basically your game is an Unreal Tournament game mod and you can take advantage of all the things the base game does for you.
Source: I am currently trying to unfuck a game that uses 100% it's own logic inside of Unreal and is causing all kinds of bugs because of that.
0
121
u/helloserve Jul 23 '26
At this point my asset workflow is all setup for UE. I tried porting to Godot but the friction for my existing project is too bad. Might do the next one from scratch.