I just finished making a Candy Crush clone in Godot and I’m completely burnt out and stressed.
Every time I look at the Godot Editor, I feel like my body is pulling me away from it. It’s like I’m traumatized by the Godot’s brainrot and foot-guns. The reason why I wanted to learn Godot is because of their skeletal animation system. It’s what I need for my dream wrestling game. So learning Godot is an appropriate decision.
But I spent more time fighting the engine’s quirks than actually making the game.
So, I’m looking at Defold again because I’m now finally earning money and can now buy Spine (yay!).
I tried Defold and made a simple game, and it actually lets you just write code without getting in your way.
So, here’s my post-mortem rant on why I’m abandoning Godot for good based on my time I spent (ACTUALLY MAKING GAMES not just simple systems) there.
- First off, the engine-specific brain rot is real. In Godot, you have to memorize these strict, dogmatic mantras; “Children shouldn’t talk to parents! Parents should listen to signals! Children shouldn’t ask for data! Parents should provide data to children!” and if you deviate from this even a little bit, your project turns into a massive spaghetti monster and you have no idea why things are breaking.
- To scene or not to scene. To node or not to node. To script or not to script. To class or not to class. To resource or not to resource. It’s insane how many ways a thing could be done. It’s an headache to do simple things after reading the documentation explaining concepts you have to keep in mind because of how the engine is designed. There’ll be a point where you just want to create an entity such as an enemy, but you have to think about many things such as scene structure, communication model (who’s the root node that will allow its communication with other nodes?), and data resource (where it should get its data and its model).
- They keep talking about flexibility when the nature of the design they chose (scene/node architecture) is tightly-coupled by default. Nodes are organized hierarchically, so a child node depends closely on its parents.
- Hot-code reload. They say it does work, but it doesn’t. So they gave you @tooltool annotation so your script will execute inside the editor. Great, you can now preview your game inside the editor. The problem is that you basically have to make your game twice; once for your player, and once for your workflow.
- The Editor Workflow: What I love about traditional programming is that everything happening in my program exists within a single window: the code editor. In Godot, that’s just not the case. There are multiple “sources of truth” for why your code might not be working. You can easily spend an hour debugging logic, only to find out the value was overridden in the Editor Inspector (often via the @export annotation). Alternatively, the issue might be that a Node is using a shared Resource; when you modify one Node, it accidentally alters every other Node sharing that same Resource. While it’s fair that the engine is designed this way, the real problem is that these relationships aren’t displayed transparently. You have to make Resources unique (“Make Local”) one by one via the editor, which becomes a nightmare when dealing with dozens of UI nodes. Worse yet, because of dogmatic design mantras regarding how nodes should communicate, you often have to dig deep through the scene hierarchy just to figure out what is happening.
- Another major hurdle is the way the engine initializes scripts and the scene tree. I cannot count how many times I have tried to access a node, only to find out it isn’t “ready” yet. In Godot, initialization notifications (_ready()) propagate from the bottom up, but nodes enter the scene tree (_enter_tree()) from the top down. That is simply too much of a mental model to force onto a beginner game developer who just wants to sit down and make a game.
- Scene Dependencies and Debugging Friction: Fixing scene dependency errors is incredibly tedious because you constantly have to navigate back and forth between the script editor and the 2D workspace. It doesn’t help that for certain errors, Godot points to the engine’s internal C++ source code instead of highlighting the exact location where the error occurred in your script.
- Lack of Editor Quality-of-Life Features: I find myself criticizing the editor frequently because it lacks basic usability features. For example, if you want to round the corners of a button, you are forced to manually adjust the radius value for every single corner one by one.
- Rendering and Scaling Bugs: The rendering system frequently introduces visual artifacts. When animating the scale of a node, the edges shake and jitter as they move. It seems like the engine fails to handle pixel snapping and synchronization correctly when factoring in parent-child scaling and complex anchor layouts. Rendering simply keeps breaking. I have already filed three bug reports for rendering issues, but the community insists those aren’t an issue, despite the fact that these issues never occurs in engines like Defold or other framework libraries.
- To top it all off, I absolutely hate GDScript. I don’t know exactly what it is about whitespace-dependent languages, but writing it feels completely unnatural, clunky, and deeply unsatisfying.
I want to love Godot, I really do, and whenever I see updates about it, I get excited. But it’s just not for me and that’s okay. So, I’m choosing Defold. Why? Here’s the list, I may get some wrong because I haven’t made any serious game from it, but I’m liking the experience so far!
- Composition over inheritance.
- Code-driven. Godot have an infamous quirk of being able to make games inside its own animation player.
- Export size.
- Lua.
- Message communication.
- Engine stability & community (it’s really unfair to compare Godot to Defold, but the forum here is way more friendly and the Defold team are actually answering questions)
I’ll keep adding more things here now that I’m abandoning Godot and changing to Defold. Maybe a Godot user will see this and give Defold a try.
