Why Some Studios Are Moving to Godot in 2026

PGP Studio Team · May 20, 2026 · 7 min read

A third of new indie games on Steam now run on Godot. Here's what's actually driving the migration, and when it's not the right move.

Trust, Not Just Technology, Is Driving the Migration

The most important thing to understand about this migration is that it is not primarily a story about Godot suddenly becoming technically superior to Unity across the board. It is at least as much a story about trust, and specifically about the lingering damage from Unity's 2023 Runtime Fee announcement, which a full reversal did not fully erase from studios' collective memory. Unity's decision this year to put the High Definition Render Pipeline into maintenance mode reinforced exactly the same underlying worry that drove the original Runtime Fee backlash: that the platform underneath an already-shipping game can shift in ways a studio did not choose and cannot fully control, with real consequences for teams that have already committed years of production time to that platform.

Godot's structural answer to that worry is not a promise or a policy statement, it is a fact about the engine's governance: it is free, open source, and MIT licensed, with no company able to unilaterally change its pricing or licensing terms because there is no pricing or licensing to change in the first place. For a studio that lived through the Runtime Fee period and is choosing an engine for a project that might still be in active development five years from now, that structural guarantee carries real weight independent of any specific technical feature comparison, and it is the piece of this story that generic performance benchmarks miss entirely.

The Performance Numbers Actually Back Up the Switch

Setting the trust argument aside, Godot's reported performance benchmarks genuinely support choosing it on technical merits alone for a meaningful category of projects, not just as a trust-motivated fallback. Reported benchmarks show Godot loading projects over 5 times faster than Unity, exporting finished builds around 20 times faster, and compiling scripts roughly 31 times faster, all backed by a genuinely tiny 120MB editor install with zero licensing risk attached to any of it. For a small team iterating quickly, especially one running frequent internal test builds throughout a day, those export and compile time differences are not a marginal convenience; they compound into meaningfully more iteration cycles per working day across the life of a project.

High-profile validation matters too, and it is worth naming specifically rather than treating Godot's growth as purely a grassroots indie phenomenon. Slay the Spire 2 switching its production engine to Godot is a genuinely significant signal, because it demonstrates the engine can carry a real, commercially successful, already-established franchise through a full production cycle, not just support game jam projects and small experimental titles where a technical limitation would be less consequential if it surfaced late in development.

Where Unity Still Clearly Wins

None of this makes Godot a universal replacement for Unity, and treating it as one would be exactly the kind of overcorrection that leads a studio into a genuinely worse decision than the one it started with. For console releases specifically, Unity's mature, well-documented console certification and porting pipeline remains a meaningfully lower-friction path than Godot's comparatively newer and less battle-tested console workflow. For projects that need Unity's top-tier 3D rendering capability, the kind of visual fidelity Unity's HDRP was built to deliver before being placed into maintenance mode, Unity (or, for the very highest end of visual ambition, Unreal) remains the more capable technical choice today.

The category where this decision genuinely gets close, and where we would tell a client to seriously weigh both options rather than defaulting to Unity out of habit, covers 2D titles, roguelikes, and visual novels specifically. These are exactly the genres where Godot's node-based architecture and scene system are a particularly natural fit, where console certification is less frequently the primary release target, and where the iteration-speed advantages from faster compiling and exporting compound most visibly across a typical production timeline.

Our Own Position, Given Our Genre

We are, on paper, close to the exact profile of studio that this migration conversation is aimed at: small team, 2D and lightweight 3D puzzle and arcade genre, no current console release plans. That said, we have not migrated our own production pipeline, and the reason is not a rejection of Godot's case so much as a recognition that a mid-lifecycle engine switch carries real, concrete migration costs (retraining, rebuilding tooling, re-validating a shipping pipeline) that need to be weighed against a genuinely new project's clean-slate decision, where none of those sunk costs exist yet.

For any brand new project we scope going forward, particularly a 2D-focused one with no console ambitions in its initial roadmap, Godot now belongs in the same evaluation conversation as Unity from day one, not as an afterthought considered only if Unity presents a specific problem. That is a genuinely different starting point than we would have had two years ago, and it reflects how much the calculus has shifted, not a verdict that Unity has become the wrong choice broadly.

What We Tell Clients Asking This Exact Question

When a client asks us directly whether they should build their next project on Godot or Unity, our answer is deliberately not a single universal recommendation, because the honest answer genuinely depends on the specific project's target platforms, genre, and expected production lifetime. We walk through the same framework laid out here explicitly: console plans push toward Unity, top-tier 3D fidelity needs push toward Unity or Unreal, and a 2D-first project with no console ambitions and a founder who values engine-level licensing certainty over a slightly more mature console pipeline is a genuinely strong candidate for Godot today in a way that would not have been true even eighteen months ago.

The broader lesson we take from this whole shift, independent of which specific engine wins any individual project's evaluation, is that engine choice has become a live, actively-revisited decision again rather than a settled default most studios stopped thinking about years ago. That is a healthier state for the industry overall, even for the studios that end up staying with Unity after doing the comparison, because a default that survives active scrutiny is a stronger foundation than a default nobody ever bothered to question.

The Learning Curve Question We Get Asked Most Often

The most common practical question we get from a Unity-experienced developer considering Godot is how steep the learning curve actually is, and the honest answer is that it depends heavily on which part of Unity's workflow a developer is most attached to. Godot's node-based scene composition model is conceptually different enough from Unity's GameObject-and-component model that the first week or two involves genuinely relearning how a scene is structured, not just learning new menu locations for familiar concepts. Developers coming from a background heavy in Unity's prefab and component system report the steepest initial adjustment, while developers who think in terms of scene composition and hierarchy first tend to find Godot's model intuitive quickly, sometimes faster than they expect.

Our own internal experiment, having two developers spend a focused week building a small prototype in Godot with no prior Godot experience, matched that pattern: the adjustment period was real but short, on the order of days rather than weeks, and both developers reported that GDScript's similarity to Python made the scripting side of the transition considerably easier than the scene architecture side. That is consistent with what we hear from other studios making the same evaluation, and it is worth setting realistic expectations around before committing a team to a switch: budget for a short, real adjustment period, not zero friction and not a multi-month retraining cycle either.

Asset Store and Ecosystem Maturity: The Honest Gap

One area where Unity retains a clear and currently unclosed advantage is third-party asset and plugin ecosystem maturity. The Unity Asset Store's depth, built over more than a decade, is not something Godot's comparatively younger and still-growing asset ecosystem has matched yet, and for a studio that leans heavily on purchased or free community assets and plugins rather than building most tooling in-house, that gap is a real practical consideration, not a minor inconvenience.

For genres and project types where a studio expects to lean heavily on third-party assets and plugins to move fast, that ecosystem gap is worth weighing seriously against Godot's other advantages before committing. For a studio more inclined to build its own tooling in-house regardless of engine, which describes our own approach on most of our tooling needs, the ecosystem gap matters considerably less, since we were not planning to depend heavily on either engine's asset marketplace either way.

The Decision We Would Make Starting Fresh Today

If we were founding a brand new studio today with no existing Unity codebase, no existing team expertise, and no console plans on the immediate roadmap, we would seriously prototype in both engines before committing, rather than defaulting to whichever one we happened to have used most recently. That is a genuinely different starting posture than we would have recommended even two years ago, when Unity was still the uncontested default for almost any new 2D or mobile project regardless of its specific requirements. The fact that this is now a real, close evaluation rather than a foregone conclusion is itself the most important takeaway from everything covered here.

We will revisit this comparison again as Godot's console pipeline and asset ecosystem continue maturing, since both are the two remaining gaps that, if closed, would remove nearly every technical reason left to default to Unity for a new 2D project. Neither gap looks likely to close overnight, but the trend line on both has moved faster over the past two years than most of the industry expected, and that pace itself is worth watching closely.

The console and ecosystem gaps aside, one more practical factor worth naming is hiring. Unity's much larger existing talent pool makes it meaningfully easier to hire an experienced developer who can be productive on day one, while a Godot-specific hire is still a rarer, harder search in most markets as of 2026. For a studio planning to grow its team significantly, that hiring pool difference is worth weighing alongside the more commonly cited technical factors.

The trust dynamics driving this specific migration trace directly back to the pricing history in our Unity Pricing, Two Years Later piece, worth reading alongside this one. Engine choice is usually among the first questions we walk through with a client scoping a new Unity or XR project.