Four 3D Games in 3.82MB: Inside Claude's One-Shot Build Pipeline
A single AI session can now produce a complete, playable vertical slice with zero external assets, collapsing the cost of validating a game idea and shifting value from executing builds to deciding what is worth building. Frontend engineers who only know how to call Three.js APIs become replaceable; those who can judge quality and budget will price higher.
A single Claude session produced four complete browser games — an FPS, a CrossFire-inspired map, a kart racer, and a pelican cycling game — totaling 3.82MB. Each is a single HTML file with no external images, models, audio, or backend; all assets are generated procedurally. The engineering relies on Three.js primitives, Canvas-drawn textures, WebAudio-synthesized sounds, and esbuild bundling that inlines everything into one file.
The article breaks down how one-sentence prompts translate into technical constraints: research before building, state machines for drift mechanics, two-bone IK for pedal animation, Gerstner waves for the ocean, and Verlet cloth for a scarf. It also covers the pitfalls: a 320-second soak test to catch memory leaks, a Bloom NaN bug that black-screened after release, and a 12-item review list from a sub-agent.
The 'one-shot' label means one session, not one attempt; the model iterates on its own research, tests, and fixes within that session.
Procedural assets — Canvas textures, WebAudio synthesis, geometric modeling — are the key to small size; compression alone couldn't achieve it.
The pelican game, with no IP to imitate, is the most telling: every choice is novel, and that's where the model's limits show.
The demo layer of game development is collapsing; a concept can now be validated with a link rather than a pitch deck and a funded prototype.
For frontend engineers, knowing which effects are worth building and where to spend the performance budget matters more than Three.js API fluency.