KAIJU CITY: BUILD & DEFEND

The start screen.
Early gameplay.
The roguelike map.
The store for persistent upgrades.
Late gameplay.

Inspiration

I love the mazing side of tower defense, the moment in Bloons or Isle of Arrows where you realize the map is yours to shape, and I love the one-more-run pull of roguelikes like Vampire Survivors, where a random pick between rounds makes every run its own. I wanted a tower defense where the maze is not a feature of the map but the whole game: you build the enemy's path yourself, block by block, and every block is also somewhere to put a tower. Giant kaiju stomping through a city gave me the perfect enemy for that, because a monster that can smash your walls makes the maze feel fragile and worth defending.

What it does

Kaiju City: Build & Defend is a portrait, single-session tower defense played as one 30-minute roguelike run. Giant kaiju march on the Empire State Building. You raise buildings to wall them into a maze of your own design, top those buildings with towers, and gamble on every wave.

Before each wave, red threat lines show exactly where the kaiju will walk, and every block you place bends those lines in front of you, so you sculpt the enemy's route past your towers and see it working before a monster appears. Small kaiju wind through the maze; big ones cannot fit and smash straight through, so you re-route under pressure. Every Start Wave is a bet: Standard pays a steady reward, Double or Nothing pays double gems only if nothing touches the skyscraper. Gems are spent in a Store between levels on random upgrades that last the whole run, so each run grows into its own build. The skyscraper's HP lasts the whole run and never heals; hit zero and the run ends, no retry.

The build contains a guided tutorial, four hand-built maps, 19 waves, three towers, small and big kaiju, the wave bet, and 22 Store upgrades including street traffic that slows kaiju and two god powers.

How I built it

The whole game was built with Claude Code across about sixty sessions, with me as the designer and Claude as the engineer. I wrote the game design document first, then had Claude turn it into engineering contracts: an architecture spec, a data schema, a UI spec, and later a run spec for the roguelike layer. From there we built in small verifiable passes, core loop first, then progression, then feedback and polish, with a build log entry at the end of every session.

The rule from day one was that everything tunable lives in JSON, not code: tower stats, kaiju stats, wave lists, the economy, the upgrade catalog, the tutorial steps, even the particle effects. Levels are hand-painted PNGs where one pixel is one cell. That meant I could reshape the game between sessions without touching a line of code, and it made the big pivots cheap.

Claude also built the tooling around the game: a build script that packages the single-file offline build, a headless screenshot tool that smoke-tests scenarios, a balance bot that plays whole runs under named strategies and reports where each run dies, and a phone-playtest QR script. Every push deploys to GitHub Pages so playtesters could open it on their phones within minutes. The engine is Three.js in a single unminified index.html.

Challenges I ran into and accomplishments I'm proud of

What I'm most proud of is how hard I was willing to pivot core elements after each playtest, rather than defending the design I had.

The first external playtest was humbling: nobody built mazes. Tanks stopped kaiju dead, so they were the only slow worth buying, Artillery only ever hit tank-pinned targets, and blocks were just decoration. The fix was to pull Tanks out of the starting roster entirely, make the walls themselves slow kaiju, and later introduce street traffic as a Store upgrade so that the slow comes from the city you are building, not from a unit that replaces the maze. After that change, players started mazing, and the game finally became the game I had pitched.

What I learned

Playtest early and believe what you see, not what you intended. A mechanic that is strictly best will erase every mechanic around it, and the only way to find that out is to watch a stranger play.

Building with an AI engineer changed how I designed. Because changes were cheap, I stopped protecting ideas and started testing them. Keeping every number in data files meant a playtest finding on Sunday could be a tuned build on Monday. And the discipline of specs, small passes, and a build log turned out to matter more than any single prompt: the AI was only as good as the contract it was building against.

What's next for KAIJU CITY: BUILD & DEFEND

There is already enough gameplay for a 30-minute run, which is the run length I want. The next step is making each run more its own: a pool of levels the run draws from, unlockable starting towers, more kaiju types, and a much deeper upgrade catalog, so no two runs build the same maze or the same arsenal.