The Best Game Engine for AI Is the One It Can Read
The engine AI can read as text and run on its own is the one it actually masters
I've written a few games in TypeScript. They run, you can throw a link at a friend, they click and play. But every time I got halfway, I hit the same feeling — no matter how much I piled on, this thing was never going to grow into a "real" game.
So when I decided to build one for real, I started digging: if AI writes most of the code, which engine is the right one?
The intuitive answer is clean. Whoever has the most material, whoever gets discussed the most, is the one AI handles best. By that logic you pick Unity, or you just stay on the web.
After a full lap of research, I found that intuition is wrong.
The web-game ceiling is half real, half illusion
First, was my own gut right?
Half right. The web ceiling is real, but it's actually two completely different ceilings that I'd mashed into one.
The first is performance and graphics. JavaScript is single-threaded, garbage collection stutters, the 3D tooling is immature — all true, and open worlds and photoreal 3D are basically off the table.
But that ceiling is being pushed up. In September 2025 WebGPU landed in every major browser, including Safari on iOS, with large matrix math running several times faster than the old WebGL. Three.js weekly downloads doubled in a year to 5.4 million. The line that used to be a hard wall is moving up — even Unreal 5's Lyra demo now runs in a browser.
The second ceiling is distribution and perception. That one is mostly a relic. Want Steam? Wrap it in Electron — in October 2025 a three-person team shipped a Phaser idle game (Desktop Heroes) to Steam exactly that way. Want the mobile app stores? Wrap it in Capacitor. The "browser games don't count" stigma stopped being true a while ago.
What matters more: the web is exactly where AI moves fastest.
Phaser is the only game framework that flatly states on its own GitHub page that "every major frontier LLM was trained on Phaser," and the repo ships agent skills built for Claude Code and Cursor. One developer used Claude plus Cursor to build a tower defense game (Tower of Time) in 25 to 30 hours — about fifteen thousand lines, 95% written by AI — and it pulled four stars at a game jam.
So my "ceiling too low" feeling was misplaced. What's low is the graphics ceiling and the distribution friction, not how much AI can build for me. Those are two different things, and they need to be counted separately.
The engine with the most training data isn't the one AI uses best
This is the most counter-intuitive thing I found.
"Whoever has the most material, AI handles best" sounds obvious. Two examples blow a hole in it.
One is Bevy, a game engine written in Rust. There's no shortage of Rust in training data, but Bevy ships a breaking API change roughly every three months. That warning is printed right in its own quick-start docs. The result is that AI is forever using the old syntax — correct grammar, just won't compile. A developer behind a game called Architect of Ruin spent six weeks migrating the whole thing from Bevy/Rust to Unity/C#, precisely because AI's guidance for C# was "highly relevant" and its Bevy advice was perpetually a step behind.
The other example runs the opposite way. Pico-8, an extremely constrained fantasy console: 128×128 pixels, 16 colors, an 8,192-token code limit. By the "more material" logic, something this niche should be a disaster for AI. Instead, someone used Claude Code to write a bug-free Lua game in a single session, without touching a line of Lua themselves. The reason was exactly that the API is small enough to have no ambiguity — AI could see all of it at once.
Put those two side by side and the real variable surfaces. It isn't the total volume of training data. It's freshness and stability — and more than that, whether AI can fit the entire project inside its field of view.
So the right way to ask the question isn't "which engine has the most material." It's this: which engine lets AI read the whole thing as text, run it, see the result, and then fix itself in a loop.
Unreal has the highest ceiling and is the worst fit for AI
If what you want is the graphics themselves, Unreal has no rival. Nanite, Lumen, and MetaHuman stack up to film-grade realism. This year's breakout, Clair Obscur: Expedition 33, is the case study of a small team hitting AAA visuals on Unreal 5.
But switch to "let AI write it" and Unreal is the most painful of the three, painful in three places.
First, Blueprints are binary. Unreal's visual scripting is stored as .uasset files — a binary node graph that AI simply can't read or write. One developer put it plainly: I opened Claude Code to have it look at my blueprints, and it couldn't see them. A 2025 paper studying Blueprints had to write its own parser to chew through more than 330,000 .uasset files. The current workaround is a plugin that translates Blueprints into C++ first so AI can read them — which is an admission that AI can't touch them directly.
Second, Unreal C++ isn't ordinary C++. A pile of reflection macros like UCLASS and UPROPERTY, plus the notoriously hard GAS ability system, mean AI hallucinates even when the syntax is right. NVIDIA wrote a whole blog this year on how to keep AI from going wrong inside large Unreal C++ codebases, framing it as an open, unsolved problem. When a company that size treats it as a research topic, that tells you off-the-shelf tools aren't enough here.
Third, compiles are slow enough to break the loop. Going from Unreal 4 to Unreal 5, one developer's cold compile time went from a bit over twenty minutes to fifty or seventy. AI's whole advantage is fast trial and error. Wait an hour per compile and that loop is dead.
The subtler tell: Unreal 5.7's built-in AI assistant (shipped November 2025) is deliberately sandboxed — it can't read your project files, can't run any editor operation, and amounts to a chatbot bolted onto the docs. And Verse, the new language that would be friendlier to AI, only works inside Fortnite's creation tools today; you can't use it for a real game.
The conclusion is clear. Unreal fits projects where the graphics are the product, and you accept that AI here is a C++ sidekick — it can't touch Blueprints, and it can't compose your levels. For someone who wants AI to carry the load, it's the worst of the three.
Unity has the strongest code and a workflow that fights AI daily
Unity holds the biggest card: training data.
C# is mainstream — over a million questions on Stack Overflow alone — on top of twenty-plus years of docs, tutorials, and Asset Store discussion. For writing game logic, AI really is steadiest on Unity. One developer logged that AI-generated Unity editor scripts ran on the first try close to 80% of the time; someone had it stand up a localization system in eight minutes that would normally take two or three days.
But strong code doesn't mean a smooth game. Unity's workflow fights AI at every turn.
Its scenes and prefabs are stored as GUID-laden YAML — technically text, but AI can't actually read it. The same simple scene that takes sixty-odd lines of dense ID references in Unity takes ten lines in Godot. And plenty of the work happens inside the editor — dragging, wiring, tweaking the Inspector — which text-only AI just can't do. Add that C# has four or five ways to do the same thing in Unity (UnityEvent, C# events, ScriptableObject, message buses) and AI still has to guess which one your project uses.
The most telling thing is the workaround the community settled on: don't have AI write the scene file directly, have it write an editor script that builds the scene. Back to pure code, with a "controlling the editor" skin on top. Unity's official AI (MCP included) only reached beta in the second half of 2025, and the community still says it's worse than a 10,000-star open-source one.
Money is a factor too. After the runtime-fee saga (announced September 2023, cancelled September 2024), Unity Pro actually climbed to over two thousand dollars per seat per year, and the trust never fully recovered. Godot is free forever.
Godot wins on something humble: the whole thing is plain text
Run that variable — can AI fit the whole project in its field of view, run it, and watch itself fix it — down the list, and Godot is almost built for this question.
Its scene files (.tscn) and resource files (.tres) are plain text. AI reads them directly, diffs them directly, edits them directly, with no conversion step in between. Unity can't do half of that; Unreal can't do it at all.
It's MIT open source, so the engine itself (well over a hundred thousand stars) is in the training data — AI doesn't just know the API, it can read the internals. GDScript reads like Python, so the barrier is low; you can also use C# and pull in that huge body of training data that's independent of Godot.
And here's the killer: the loop. Since 4.0, Godot natively supports --headless, so AI can run the game itself, read the errors, and fix them. Pair it with a test framework like GUT and the whole write-run-check cycle needs no human in it. Across 2025 and 2026 Godot's MCP tooling exploded — the main godot-mcp server has nearly four thousand stars, GoPeak ships ninety-plus tools (breakpoint debugging and screenshots included), and other servers let AI launch the game itself, simulate clicks, take a screenshot to look, and move on. That's the most complete "AI self-check" loop of any engine.
It's light, too. The Godot editor is about 50MB. Unity is 2GB. Unreal starts at 50GB. For an AI pipeline that pulls the engine up over and over in CI, that's the difference between seconds and minutes.
The commercial-ceiling doubt is starting to close as well. Slay the Spire 2 migrated from Unity to Godot after the runtime-fee saga and went into early access in March 2026, with concurrent players reportedly peaking around 570,000. Godot's share of GMTK game jam entries went from 19% in 2024 to 40% in 2025, and Godot games on Steam grew from 618 to nearly three thousand in two years. The old "Godot can't carry a commercial title" worry is being filled in, one number at a time.
Of course, there are costs.
Godot isn't free of traps. GDScript genuinely has less training data than C#, and Godot 4.0's March 2023 API overhaul meant that for a long stretch, models with an earlier cutoff would confidently emit deprecated Godot 3 syntax. The problem is real but narrowing — developers who've used it say that with a post-Opus-4.5 model and a well-written project context file, it rarely trips up anymore.
There's a more important expectation to manage: counting on AI to build a game from zero, by mouth alone, with no engine knowledge, mostly fails. One developer spent twenty or thirty attempts just to get drag-and-drop working in Godot before bailing; several "vibe coding gone wrong" write-ups stall on foundations like the state machine. This year's GDC survey says it bluntly — 81% use AI for research and brainstorming, 47% for code assistance, and only 5% dare to put AI into player-facing features. AI is a multiplier. What it multiplies is someone who can already build the scaffolding, not a path that grows a project from nothing for you.
So how I'd choose
After that lap of research, my choice actually got simpler.
For a prototype, a game jam, or anything where the whole point is sharing a link — stay on the web with Phaser and TypeScript. The ceiling is lower than I thought, and WebGPU is still pushing it up; if you really need a desktop build, wrap it in Electron. This is where AI moves fastest, because in a browser you change something and see the result instantly. Shortest loop there is.
For a proper game you want to ship on Steam, with AI carrying the load — Godot. What it offers is "web-game speed with a native ceiling," and the reason it can is exactly that it preserves the property that made the web AI-friendly: everything is text AI can see and run. Pair it with an MCP server so the agent closes its own loop; if you want to squeeze in even more training data, use C#, at the cost of giving up web export.
Only when the graphics are the product — photoreal AAA — is Unreal worth it, and then be clear-eyed: AI is your C++ sidekick, not the lead.
I've written before about trying to make three games without writing code, and about why Claude Code won. Take the long way around and the conclusion is the same one: how much AI can build for you depends on how much you let it see.
On the surface the engine question asks "which one is AI best at." Underneath, it's asking which engine is willing to let AI see what it's doing. Godot flattens the project into a page you can read. Unreal locks it in a black box. The gap between them isn't about how smart the model is. It's about whether you give it eyes.