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 where that framing really starts to break down.
In 2025, over 1,200 games made with Godot shipped on Steam. Not prototypes. Not experiments. Finished games released on one of the more unforgiving platforms out there.
At the same time, itch.io sees roughly 500 new Godot games every week. Game jam entries, student projects, odd experiments, early demos - the kind of work that shows what developers actually reach for when they want to build something now. Godot showing up that often isn't an accident.
Taken together, the picture is fairly clear: Godot isn't just something people try. It's something they actually finish games with.
What Actually Changed with Godot 4
Godot 4 didn't suddenly make Godot "serious." What it did was remove a lot of friction.
- Rendering that finally feels modern and scales properly
- GDScript that’s faster and easier to live with as projects grow
- Tooling that holds up once your project stops being "small"
- More realistic workflows for C#, C++, and native extensions
At some point, the engine stops being the thing you're constantly working around and just becomes… the engine. For a lot of people, Godot 4 is that point.
Open Source, Without the Headaches
One thing that's easy to miss is how Godot is growing.
There's no pricing drama. No surprise licensing changes. No awkward fine print you only notice once you're committed. People are adopting Godot because they trust it - and because they can ship without worrying that the rules will change halfway through.
That kind of stability doesn't get talked about much, but it matters more than people like to admit.
Godot 4.6: Quietly Making Things Better
The Godot 4.6 update doesn't try to grab headlines, and that feels intentional. It’s focused on performance, editor polish, and continued work on 3D stability and usability.
It feels less like a "big new direction" and more like the engine settling into itself - getting faster, smoother, and more predictable with each release.
And that's usually the point where an engine stops being "the alternative" and starts being the obvious choice.
Godot Engine 4 isn't really trying to convince anyone anymore. The people shipping games with it already did that.
Top comments (15)
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.