I Claude Coded a multiplayer Three.js tank game with 100+ procedural vehicles. Here's my workflow

I built a multiplayer browser tank game in Three.js! As a kid, I played a ton of World of Tanks Blitz and fell in love with the aesthetic, gameplay, and the idea of driving around vehicles with crazy physics and mechanics like missiles, spotting, armor deflection, ammo types, and so on.

Claude of Tanks has 100+ playable vehicles across 16 unique maps, ranging from standard tanks with cannons to AFVs with autocannons and guidable missiles to autoloaders that can deal massive damage in a single clip. Tanks feature highly detailed armor zones, internal modules, crew positions, and hitboxes. You can view each of them in a special gallery: https://cot.kevinliu.studio/gallery?id=amx56&layer=modules

CoT supports physics-driven destruction with detached turrets flying through the air and actual suspension. It also supports multiplayer! You can hop in private rooms or LAN lobbies.

As the name would suggest, I used Claude Code throughout a long-running multi-agent development pipeline, alongside Codex. I directed the architecture, decided what each vehicle and system should do, reviewed the rendered results, and made the final calls.

The repository contains an AGENTS.md file and smaller subsystem instruction files covering simulation, vehicles, networking, UI, audio, effects, and world generation. These record the rules that agents need across sessions. Units are meters, seconds, and radians, and changes enforce a fixed 60 Hz. Authoritative logic must be deterministic. Vehicle changes have specific geometry, armor, module, and release gates that evaluate models visually and geometrically.

For vehicle development, I split the fleet into bounded families. One agent would own a specific vehicle profile or family file, implement the geometry, run the relevant checks, and generate screenshots. A separate critic reviewed the rendered tank for proportions, clipping, missing surfaces, running gear, and recognizable details. The orchestrator reran the checks and committed only the verified files.

A trailer was also produced through the game’s own Scene Studio and capture tools. I used agents to stage battles, build camera paths, record the browser runtime at 60 fps, inspect specific frames, and iterate on awkward cuts or poorly framed tanks.

I find that Claude is best steered with persistent instructions. Important decisions need to live in the repository because I often spawned fresh agents which needed to resume work without reconstructing weeks of chat history.*

For visual quality, the only thing that worked was a proper render loop with visual comparison; tests don't really work for this.** The cycle I fell into was change, render, inspect, measure, and rerun the gates. Text-only reviews missed warped proportions and camera problems that would just plainly be obvious in one screenshot.

*Parallel agents need strict ownership. Separate files and isolated Git worktrees prevented concurrent sessions from overwriting each other or generating assets from a dirty tree.

**Tests still changed how I use agents. Claude Code became much more reliable once every system had concrete invariants and executable failure conditions. But visual quality is another beast.