One Prompt, Three Engines: the Same Android Game in Bevy, Unity, and Unreal

June 18, 2026 · ~1,050 words · What an AI coding agent does with three game engines, and why the editor is the whole story

I gave Claude Code the same brief in three game engines and kept the results. The brief was deliberately hostile to the usual game-dev workflow: build an Android game with no art and no audio assets, everything generated in code. I ran it twice per engine - a 2D HORSE poker game and a 3D USPSA practical-shooting stage - across Bevy 0.18 (Rust), Unity 6 (C#), and Unreal Engine 5.7 (C++). Six repositories, all built on macOS with Claude Code on Opus 4.8.

I was not trying to ship games. The question was narrower: how much does the engine choice change how well an AI coding agent does? The engines differ in language and build system, but the difference that mattered was how much of the work lives in a visual editor you click through - the one place an agent cannot follow.

The constraint that decides everything: no editor

An AI agent works in text. It writes files and runs commands. It does not drag a mesh into a scene, wire a node graph, or nudge a transform in an inspector. So "can Claude Code build in Unreal" really means "how much of Unreal can you drive without ever opening the editor." Every result below follows from that one fact.

The no-assets rule is the same idea from the other direction. Binary art and audio are the one thing an agent cannot author as text, so I banned them. Cards are drawn from primitives, stages from primitive meshes, every sound synthesized by a small Python script committed next to the game. That sounds like a handicap, but it is what makes the exercise tractable: remove the one thing the agent can't produce, and let it generate everything else as text it can read back, test, and fix.

Bevy (Rust): nothing to click

Bevy was the natural fit because there is no editor to begin with. A Bevy game is a Rust program - the entire thing is source, so nothing is out of the agent's reach. It reached a working build in the fewest commits (4 to 5) on the lightest toolchain of the three: the aarch64-linux-android Rust target plus cargo-apk, driven by a committed build_apk.sh. Each game is about 64 KB of Rust, and the APKs are small because a Rust binary is small.

The cost is that Bevy hands you the least for free: no scene editor, no asset pipeline, no physics you didn't write. For an agent that is closer to a feature than a bug - less engine to misuse - but the game is exactly as capable as the code, and no more. The Bevy poker skips side pots; it is the bare engine plus what was written on top.

Unity (C#): headless, and the most complete

Unity has a heavy editor, and the surprise was how much of it Claude Code routed around. It built the entire scene from C# (SceneBuilder.cs), ran the game logic headlessly in Unity's batchmode before any UI existed, and packaged the APK with -executeMethod ... BuildAndroid, never opening the editor window. It wrote the most code of the three (73 to 91 KB of C#) and took the most iterations (9 to 10 commits), and produced the most complete game logic: the Unity poker is the only one with side pots and three opponents.

The price is a real Unity install (6000.0.77f1) and IL2CPP in the loop, and the most rounds to get there. But "drive Unity entirely from C# and the command line" turned out to be a workflow an agent handles well, and the headless tests let it know it was right before anything rendered.

Unreal (C++): possible, at a price

Unreal worked, in pure C++ with a Slate UI and no Blueprint - the only way to keep the whole game as text in Source/ instead of in binary editor assets the agent can't touch. The hand evaluator is dependency-free C++ you can compile and test with clang++ outside the engine.

The price is the toolchain, and it is steep: UE 5.7 with the Android platform, NDK r27, JDK 17, an ASTC cook through RunUAT BuildCookRun, and bPackageDataInsideApk so a sideloaded build runs without an OBB file. The resulting APK is about 130 MB, against a few megabytes for Bevy. Unreal also produced the simplest game of the three - heads-up poker only - for the most ceremony.

Side by side

The pattern is consistent: Bevy reached a working build with the least code and the lightest toolchain; Unity took the most code and iteration but produced the most complete logic; Unreal carried the heaviest build for the simplest game. None of the three needed its visual editor, because the agent was told to keep everything in code - and that, not the language, is what made each one possible.

Then I built it for Windows

The six builds above all target Android from a Mac. To close the loop I rebuilt the USPSA shooter twice more - native to Windows, built on Windows, once in Unity 6 and once in Unreal Engine 5 - and switching the target inverted the difficulty curve. Android-from-macOS was easy to start and fiddly to finish; Windows-on-Windows was the reverse: tougher to get going, smoother once it ran.

The bootstrap was the whole tax. The machine had Visual Studio 2022 and .NET but no UnrealEditor.exe, so step one was a multi-gigabyte engine install through the Epic Games Launcher before a single line could compile. Once the toolchain was in place, the native target was the nicer place to work and to play: a desktop build is a folder you double-click, and a first-person shooter wants a mouse and a real screen, not thumbs on glass.

It is also where the idea fully landed. Freed from a phone, both Windows builds run a two-stage course of fire where Stage 2 adds an armed "ranchero" who shoots back from cover - a navmesh-free enemy AI that aims, strafes, holds its range, and fires on line of sight. That is more game than the single-stage Android versions had room for.

What I'd tell someone pointing an agent at a game engine

Choose the engine with the least editor and the most truth-in-source.

• Bevy is the cleanest fit: all code, one build script, and the agent can reach every part of it. You give up everything an engine would otherwise hand you.
• Unity is more capable and still very workable headlessly, if you accept that the agent writes its own scene-builder and leans on batchmode. It rewarded that with the most complete game.
• Unreal is genuinely possible in pure C++/Slate, but you pay in toolchain weight and a 130 MB APK, and should expect the most setup for the least game.

The deeper lesson is the no-assets constraint, not the engine ranking. All six exist because I removed the one thing an agent cannot produce - binary assets - and let it generate the rest as text it could read, test, and repair. The engine choice only decides how much ceremony stands between the code and a running build - and, as the Windows rebuilds showed, the target platform decides where that ceremony lands: a light start and fiddly finish targeting Android from a Mac, a heavy bootstrap and smoother finish targeting Windows on Windows.

Get the code, grab the builds

The six Android repositories are public, and each ships a release with a sideloadable APK (debug-signed, arm64-v8a - turn on "install unknown apps" for your browser, download, and tap it). The two native Windows rebuilds are public too, each with a zipped desktop build in its release.

• Bevy (Rust): BevyHorsePoker (code · APK) · BevyUSPSAMatch (code · APK)
• Unity (C#): UnityHorsePoker (code · APK) · UnityUSPSAMatchAndroid (code · APK)
• Unreal Engine (C++): UnrealHorsePoker (code · APK) · UnrealUSPSAMatch (code · APK)
• Windows builds (desktop): USPSA-Shooter-Unity-Windows (code · Windows build) · USPSA-Match-Unreal-Windows (code · Windows build)