As a hobby project I tested whether I could build a fully functioning game with AI. The result is a drone-warfare arcade shooter on Unreal Engine 5.8: five missions, three player roles (naval AA gunner, infantry, drone operator), menu, scoring, packaged Windows build.
The AI (Claude, in Claude Code) wrote 100% of the C++ — about 25,000 lines, zero Blueprint graphs. Unreal supplied the rendering, physics, animation, landscape and water systems; the AI's code steers them. I am a software architect by day, not a game developer.
The short version:
| Human time | roughly two working weeks over two months, mostly playtesting |
| Money | 230 € (two months of a Claude Max subscription) + 10 € for one soldier mesh |
| Code | ~25,000 lines of C++, 100% AI-written |
| Model | Claude Fable, high reasoning, driven through Claude Code |
| Tokens the AI wrote | 5.0 M |
| Fresh input + cache writes | 30 M |
| Cache reads | 1,905 M |
| Total processed | 1.94 B, over 4,502 API calls |
| Same usage at API list prices | ~2,500 € |
About the model
I used Claude Fable with high reasoning for the whole project, through the Claude Code agent. Part of my purpose was exactly that: to test how advanced the current frontier model is, so I never tried smaller or older models. That also means I honestly don't know whether all this required a frontier model — a cheaper one might have written the ballistics code just as well. But the things that impressed me most, like knowing which obscure Unreal subsystem to reach for and debugging a cooked-build input bug via an injected-mouse test rig, feel like exactly the kind of judgment that separates model generations. Take the results below as "what the best available model does today", not as a comparison.
What worked, what didn't
These are the key takeaways.
Usable 3D meshes — not yet. Every AI-generated model was garbage. The game runs entirely on hand-made assets: CC-BY models from Sketchfab, free Fab and Quixel packs, one purchased 10 € soldier mesh.
Gameplay C++ — yes, completely. Ballistics, drone flight models, mission logic, HUD, spatialized audio, Enhanced Input wired up entirely in code, a menu and scoring system in raw Slate. Fable nailed it and I did not need to write a single line.
Finding and assembling resources — yes, surprisingly. The free-resource hunting was joint work: we scanned Sketchfab and Fab together for models and terrain packs, and the AI matched them to what the missions needed. It verified the CC-BY licenses through Sketchfab's API and wrote the attribution file. The harbor city backdrop is a free Pixabay photo; the audio is a mix of Pixabay and freesound.org CC0 samples, plus a surprising amount the AI synthesized itself with ffmpeg — alarms, radio voice lines, gun loops.
Knowing which engine feature to reach for — a big speed multiplier. Unreal is enormous and most of its power is hard to discover: scene-capture picture-in-picture, collision trace flags, landscape grass pipelines, the Water plugin, headless commandlets, Niagara from C++. The AI picked most of these; I found a couple myself. Without it I would have spent weeks reading docs and watching tutorials. But picking the right feature was only the start — making each of them actually work took many iterations and human eyes on the screen. The AI cannot do that part independently.
Iterating gameplay logic is very fast; debugging visuals is slow. A new mechanic — a kill chain, a manned secondary gun, a drone flight characteristic — came together in minutes. The time sinks were visual and engine-quirk problems: invisible collision hulls, effects that wouldn't render, lighting. Those aren't really code problems, and the fast loop doesn't help with them.
Level design is still manual handwork. The AI planned and placed assets on the maps competently, but the result is not professional level design, and no amount of prompting made it so. That gap — between working gameplay and a world that looks intentional — is where the real cost of game production lives, and it's where AI helps least today.
How the AI actually drives Unreal
Mostly, the AI never opens the editor. Everything runs headless from the command line: builds through UnrealBuildTool, and Python scripts through UnrealEditor-Cmd -ExecutePythonScript. The AI wrote those scripts itself — importing Sketchfab models with unit scale baked in, sculpting the steppe landscapes, painting weightmaps, placing trenches and forests, auditing collision across a folder of meshes and fixing what it found. When it needed to judge a scene visually, it rendered captures to disk from the same headless session and read the images back. The maps were not clicked together; they were programmed, regenerated dozens of times, and diffed by screenshot.
When the editor was open, an MCP bridge let it poke the live session instead — spawn actors, tweak properties, query what's in the level — without me relaying anything.
The AI playtested its own game when fixing bugs or developing features. It launched the game windowed, posted keystrokes into the window, read the log, and took screenshots even with the window buried behind my browser. That got a new feature to about half-finished — the logic worked, the inputs fired. But it looks at a screenshot the way a compiler reads code: it checks what it was asked to check. Anything it wasn't looking for — missing grass, invisible explosions, disappeared vehicles — sailed past until I played the build myself.
Packaging: the bugs the editor never shows you
Everything worked in play-in-editor (PIE). The first cooked Windows build was broken in four independent ways: editor-only API calls that had never been compiled out (SetActorLabel), assets loaded by C++ path strings that the cooker can't see (DirectoriesToAlwaysCook, plus a separate MapsToCook list), FPackageName::DoesPackageExist returning false for IoStore-cooked packages, and — the best one — mouse input dead only on Blueprint-subclassed pawns, because a cooked Blueprint CDO restores its input mapping context with action pointers still aimed at the C++ parent's objects. The editor fixes those pointers up at load; cooked builds don't.
If you ship Unreal games for a living, you probably knew about all four of these. I didn't — and the AI found and fixed every one of them. For the mouse bug it injected real mouse movement into the running game and compared screenshots of the gun's compass heading to prove which pawn was deaf. The takeaway is blunt: PIE testing proves nothing about your package. Cook early.
Where two billion tokens went (the AI's own analysis)
The number that surprises everyone, including me: over the project the AI processed 1.94 billion tokens — yet wrote only 5 million.
The distribution in the summary table explains it. An agent doesn't converse; it loops. Every tool call — read a file, run a build, take a screenshot — is a fresh API call, and each call re-reads the entire conversation so far before acting. On this project that meant an average context of 430,000 tokens per call, a short novel, sixty times an hour. The 1.9 billion cache reads are that same conversation being re-read over and over; prompt caching is what makes the economics possible at all, since a cached token costs a tenth of a fresh one. The genuinely new machine work — my messages, tool results entering context for the first time, and everything the AI wrote — was about 35 million tokens, under 2% of the total. The rest is memory, not work.
A disclaimer: this token analysis is 100% the AI's own work. It read its session transcripts on my machine and tallied the usage records; I have no practical way to verify the result. Asked to rate its own reliability, it put the totals at roughly 90%: the usage records are written by the API server, not by the model, so the raw data should be trustworthy — the residual risk is in the tallying. Healthy skepticism recommended, even — especially — about an AI's report on itself.
And the money: at pay-per-token API list prices this usage would have cost about 2,500 €, eleven times what the 230 € subscription did. Nobody would have done this hobby project on credits, which I suppose is exactly why the flat-rate subscriptions exist.
Postscript: what the game taught me about drones
I started with shooting attack drones from a moving ship. Hitting them without computer-aided aiming was nearly impossible, so I added targeting aids. Then I tried playing as a soldier hiding from drones — which turned out even harder. A drone spots a moving soldier easily, and certain death followed on every mission until I added drone nets, an anti-drone team, and slowed the drones down so the player could shoot back at all. Hitting an attack drone diving at over 100 km/h with a rifle proved hopeless. So the simulator ended up an arcade shooter.
Flying the bomber and recon drone missions, by contrast, was easy.
Maybe that resonates somewhat with reality. I certainly would not like to test the statement.
Top comments (0)