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 (5)
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."
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.
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.)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.