In early 2026 Unity put its High Definition Render Pipeline into maintenance mode, which landed on top of the trust still leaking from the 2023 runtime fee, and the internet filled up with migration guides. I am going the other way, so let me be precise about what that is worth before you read any further.
What I actually did, and what I do not remember
I used Godot seriously. I made a 3D game in it that friends played and told me was a good direction, which is the only external verdict that project ever got. I did not ship anything commercially in it. Then I went back to Unity and stayed there.
I do not remember exactly which version I was on. That matters, because Godot has shipped real improvements to at least one of the things I hit, and an article that presents a two-year-old recollection as today's news deserves the comment section it gets. So the structure here is: what I felt, then what is actually documented now, then whether the feeling survives contact with the second part.
The feeling: “this engine keeps me at basics”
The sentence I would have given you then was that Godot limited me to basic projects. It did not arrive on any particular day. It accumulated, and the two conditions I remember clearly are that it came after a long time and as the number of files grew.
Hold on to those two conditions, because they turn out to be the whole explanation, and they are not a statement about the engine's ceiling at all.
Friction one: two people, one project
This was the worst of the three and the one I understood least at the time. Working on a single project with a friend was heavy in a way I could not name, so I filed it under “we are disorganised”. We were not, or at least not only.
Godot scenes are text, which is usually sold as the version-control advantage over Unity, and in principle it is. The problem is one level down. The identifiers inside those files have not been generated deterministically across machines. Two people adding a resource to the same scene can both receive a generated id, on the same line, and git has no way to reconcile that beyond handing you a conflict.
Then the second half of the trap closes. The usual guidance for a conflicted scene file is
not to fix it in a text editor — because editing a .tscn by hand is
a common way to produce a scene that no longer loads. The recommended route is to open the
project and reintegrate the change through the editor. Which is to say: a text format whose
text you are advised not to edit.
The evidence that this was not just us
Dedicated third-party merge drivers exist for exactly this — tools that parse scene files the way the engine does and merge nodes and resources by identity rather than by line number, reassigning ids themselves. Nobody writes a git merge driver for a problem that does not happen.
The practical advice circulating in the community is also telling: agree who is working on which scene, and split scenes into smaller ones so that two people collide less. That is a coordination workaround, and coordination is the thing a two-person hobby project has least of.
And here is the part that makes this fair. Godot addressed it. In January 2025, with
4.4, the engine added dedicated .uid files, and the team wrote about the
reasoning publicly — including that a single central id database was rejected
specifically because it “would be subject to frequent merge conflicts in version
control systems”. They were designing against this problem on purpose.
It is better, not gone. The same change introduces a new way to lose: if the
.uid files are not committed, references break when somebody clones the
project. So if you are picking an engine for a team today, this is the single area I
would test for an afternoon before committing, rather than trusting either my experience or
a changelog.
Friction two: the asset gap is an order of magnitude
My memory of this was blunt: compared to Unity, assets did not exist. That is unfair as phrasing and roughly right as scale.
| Commonly reported size | |
|---|---|
| Unity Asset Store | around 70,000–80,000 items |
| Godot Asset Library | around 3,000 items |
Call it twenty to twenty-five times, depending on who is counting and what they count as an asset. Godot's ecosystem has also roughly doubled since version 4, so the direction is right even though the distance is large.
The qualifier matters more than the ratio, though, and most comparisons skip it: a large share of what a solo developer actually needs is engine-neutral. Models, textures, audio and fonts from itch.io or OpenGameArt import into either engine and do not care which you chose. The gap is not really about art.
Where the gap actually hurts
Engine-specific tooling. Editor extensions, inspector helpers, save systems, dialogue frameworks, state machine editors, build pipeline utilities — the category where you either buy an hour or spend a weekend. That is where twenty-five times is felt.
Which also tells you who is least affected: if you were going to write your own systems regardless, the ratio costs you very little. If you planned to assemble, it costs a lot.
Friction three: where the 3D gap actually sits
I remember 3D being a fight. What I could not have told you is which 3D, and that distinction is the one worth taking away.
Godot 4 renders modern 3D properly. Physically based materials, global illumination, volumetric fog — stylised and mid-scope 3D is covered convincingly, and anyone telling you Godot cannot do 3D is working from Godot 3 memories.
What published comparisons consistently describe as maturing is a specific list, and every item on it is about scale rather than capability:
- Level of detail and occlusion culling — the things that stop a scene from costing what it looks like.
- Large-world streaming and large-world coordinates.
- High-end terrain tooling and real-time global illumination at the top end.
- Heavy light counts, where comparisons generally put Unity ahead once a scene casts many shadows.
Notice what that list is not. It is not “Godot cannot render”. It is a list of things that do not matter at all until a project gets big, and then matter enormously. A small scene does not need occlusion culling. A test level does not need streaming.
So my conclusion was wrong, and the shape of the error is useful
Put the three together against the two conditions I remembered: it came after a long time, and as the files multiplied.
| Friction | When it is invisible | When it bites |
|---|---|---|
| Scene merge conflicts | One person, few scenes | Two people, shared scenes, many files |
| Asset ecosystem | Writing your own systems early | When you start wanting to buy time |
| 3D at scale | Small scenes, test levels | More lights, bigger world, streaming |
All three are invisible at the start and all three arrive with growth. Which means that what I experienced was not a ceiling on what the engine could do. It was three independent costs that each scale with project size, arriving together — and from the inside, three things getting harder at once is indistinguishable from a wall.
So the honest correction to my own sentence: Godot did not keep me at basics. I reached the size at which its weak spots compound, while I was also a two-person team with no process, on the 3D side, which is the exact intersection of all three. A solo developer making a 2D game would have met none of it.
Why I am bothering to correct myself in public
Because “the engine limits you” is unfalsifiable and spreads easily, and I would have repeated it for years if nobody made me check. The three checkable statements are far more useful to somebody choosing today than my conclusion ever was, and they point at different decisions.
How I would actually choose now
Not by reading comparisons, including this one. By answering three questions about your project, because each maps onto one friction above:
- Will more than one person edit the same scenes? If yes, spend one afternoon testing the merge story before you commit a year. Have two machines add a node to the same scene, conflict it on purpose, and resolve it. Whatever you learn beats my recollection and a changelog.
- Does the 3D get heavy? Many shadow-casting lights, a large world, streaming. If yes, this is where the gap widens. If your 3D is stylised and roomy rather than vast, it is not a factor.
- Will you buy or build? If your plan involves assembling from existing systems, an order of magnitude in catalogue size is a schedule difference, not a preference.
If all three answers are small, Godot is an excellent choice and the things people praise about it are true: no licensing anxiety, a tiny download, text scenes that belong in git, a language you can learn in days. None of my frictions touch a solo 2D project, which is most first projects.
I went back to Unity for reasons that are specific to what I build now: a simulation with twenty-odd dense data screens, 1,624 automated tests, and a tooling ecosystem I lean on hard. That is an argument about my project, not about the engines, and I would rather give you the questions than my answer.
Questions people ask about this
Why do some developers go back to Unity after trying Godot?
In my case three frictions, none of them about the language or the editor: collaborating with a second person on shared scenes, an asset ecosystem roughly an order of magnitude smaller, and a 3D gap that is invisible early and grows with scene complexity. Godot has improved the first of these since, so check the current state rather than treating any recollection, including this one, as news.
Is Godot bad for teams?
Not bad, but historically awkward in one specific way that hits small teams hardest.
Scene and resource identifiers were not generated deterministically across machines, so
two people touching the same scene could conflict on the same line, in a format you are
advised not to hand-edit because doing so commonly breaks the scene. Godot 4.4 added
dedicated .uid files in January 2025 and the team wrote about the
version-control reasoning directly. Third-party merge drivers exist for this, which is
itself evidence that the problem was real.
How big is the Godot asset library compared to Unity's?
Roughly an order of magnitude: commonly reported figures put the Godot Asset Library around three thousand entries against seventy thousand or more for Unity, so twenty to twenty-five times depending on counting. The honest qualifier is that much of what a solo developer needs is engine-neutral — models, textures, audio and fonts from itch.io or OpenGameArt import into either. The gap bites on engine-specific tooling and editor extensions, where you either buy an hour or spend a weekend.
Does Godot limit you to small or basic projects?
No, and this is the claim I most want to correct, including in myself, because I believed it. Godot 4 handles stylised and mid-scope 3D convincingly. What lags are things that only matter at scale — level of detail, occlusion culling, large-world streaming, heavy shadow-casting light counts. Because that gap is invisible early and arrives with growth, it feels from the inside exactly like a ceiling on ambition when it is a ceiling on scale in one area.
Should I choose Godot or Unity in 2026?
Answer three questions about your project instead of reading comparisons. Will more than one person edit the same scenes? Does your 3D scene get heavy — many lights, a large world, streaming? Will you buy systems or build them? If all three answers are small, Godot is an excellent choice and its licensing and size advantages are real. The frictions in this article do not touch a solo 2D project.
Does Unity putting HDRP into maintenance mode change this?
It changes the calculation for the high end, not for most of the people reading engine comparisons. If your plan depended specifically on HDRP, that is a genuine reason to re-evaluate and the migration guides filling the internet are aimed at you. If you are a solo developer or a small team building something stylised, it has very little to do with which engine suits your project, and it is worth noticing how much of the current content assumes otherwise.