For a long time, Godot was described as promising. Fun to use, easy to recommend - usually followed by a quiet "…for small projects."
Godot 4 is w...
For further actions, you may consider blocking this person and/or reporting abuse
Godot is a great engine, but the biggest problem is that I can't fully utilize AI to create games. Godot imposes severe limitations with its specific language and scene syntax, making the use of AI like copilot practically impossible. Therefore, I find it easier to make games in a "pure" language - no visual editors, no new interfaces, just pure code. I used to think it was crazy that people created program interfaces with code instead of specialized programs, but over time I realized that typing a few keyboard keys is more convenient than poking around in an interface. I think it would be cool if Godot offered the ability to create scenes with code (while it allows this with
add_child, it still falls short of maximum control, limiting it to messy resources, scene inheritance, etc.)Some might see this as a feature rather than a bug. But what is it that stops you from using an AI? You can use external editors and IDEs with LLMs running.
There are many reasons for this. I described them in my article a few days ago, attempting to do this with copilot. However, the problem isn't so much with Godot itself, but with copilot, who doesn't know it well. While it can certainly help you refactor your script and fix bugs, it certainly won't make the game for you. Perhaps using C# would have been better.
There are already tools for creating slop games from start to finish - if you're going down that route, why look at the code at all? Wouldn't it be easier just to use a tool where you give it a prompt for a game?
A single prompt simply isn't enough. You can't just say, "Make me Silksong 2, GTA 6, Half-Life 3, or any other large-scale project." Writing a prompt can take days, which will slow down development rather than speed it up. As for specialized tools, there's a good saying: "The more specialized the tool, the more limitations it has." If I understand correctly, using game engines that are used to create free games will have more limitations than a pure programming language. Godot has already implemented a lot, but its nature still doesn't allow you to push its limits, except by modifying its core, the code of which would take months to read. So, if you know a programming language but don't know game engines, it's better to stick with pure code. You'll already know the architecture and be able to expand it more easily if you run into difficulties, especially since everyone has the option of using AI, which is well-versed in this area. If you know a game engine, then make a game on it, but this does not guarantee full assistance from the AI.
That’s a reasonable take, and it mostly comes down to how you like to work.
Godot is very scene and data driven, so if you’re used to defining everything directly in code, it can feel a bit boxed in. You can build things programmatically, but the engine is clearly designed around a hybrid model rather than full code-first control.
For some people that’s a good tradeoff because it speeds up iteration and keeps things visible. For others it just doesn’t click. Godot’s making a deliberate choice there, not really trying to be a pure code framework.
Thanks for sharing your thoughts - it’s a solid perspective on the tradeoffs of different workflows.
A few things here resonate strongly, especially the shift from “interesting engine” to “engine people actually finish games with.” That distinction matters more than feature checklists.
What Godot 4 really fixed, in my experience, wasn’t capability but friction density. In Godot 3.x, you could build almost anything—but you were constantly negotiating with the engine once scope increased. Rendering limitations, editor slowdowns, GDScript scaling issues, and awkward extension paths all added up. Godot 4 didn’t reinvent the engine; it removed enough sharp edges that medium-sized projects stop feeling like a fight.
The shipping numbers you mention are important because they reflect developer confidence, not hype. People don’t ship on Steam—or repeatedly show up in jams—unless the tooling survives real-world pressure. That’s a stronger signal than marketing claims.
The open-source angle is also understated but critical. Post-Unity, a lot of teams are optimizing not just for performance or visuals, but for risk. Godot’s governance model removes an entire class of existential questions from production planning, which is hard to quantify but easy to feel once you’ve been burned elsewhere.
Godot 4.6 continuing with incremental polish instead of flashy pivots is, frankly, a good sign. Engines usually become “default choices” not when they add revolutionary features, but when they become predictable, boring, and dependable.
At this point, Godot doesn’t need to argue that it’s viable. The shipped games already made that case.
Indeed, Dominik, your comments reinforce the post really rather well.
The uptake with regard to Godot Engine has been steady and constant - due in no small part to meaningful updates and a superb license I'm sure.
Totally agree. Godot’s growth feels very organic — consistent improvements and a permissive license go a long way. It’s refreshing to see steady progress without hype-driven decisions.
This really matches what I’m seeing too. Godot 4 feels less like “the indie alternative” now and more like a tool people actually finish games with.
The lack of licensing drama is a big deal — it removes a whole layer of mental overhead. When the engine stops fighting you (or worrying you), you can just focus on building.
Curious to see how many teams quietly pick Godot next without making a big announcement.
Absolutely - it feels like a real shift in mindset. In the past, many teams had to navigate licensing changes, legal uncertainties, or unexpected engine policy shifts, which added mental overhead beyond actual development. Godot 4 flips that script: you just open the engine, start building, and don’t have to worry about hidden "gotchas."
I have used Godot before when creating games, and I really enjoyed it! It is nice to see people start to use Godot to ship games on Steam and itch.io.
Although it is good that it is open source and is continually growing, I currently do not see it used as a mainstream like Unity and Unreal Engine for example. I think it would come to a time where it would eventually reach there like Blender for example.
Overall, great post!
Thank you, Francis. I really do appreciate the reply!
For myself - as a Pythonista - the fact that GDScript "apes" the syntax really appeals, especially as I'm only just taking tentative steps into game dev.