Most tower defense games end in one of two ways: you survive the wave, or you don't. Deadlock doesn't work that way. Every level has three outcomes — full win, partial win, and loss — and the difference between the two wins is whether the cage was ever cracked open, even once. That single design rule is the most interesting thing about the game, and it was locked into the spec before a line of code was written.

This post is the story of how Deadlock came together: the rule, the build burst that shipped three iterations in one night, the room layout that emerged unprompted, and the bugs that taught us something about iframe games versus integration tests.

The Brief, and the One Rule That Couldn't Be Touched

The genre target was reverse tower defense — Castle Doombad, Evil Genius, Dungeon Keeper as reference points, but compressed into a single short browser session. The player is the rogue station AI. You've captured the fleet commander. The humans keep sending boarding parties to break him out. Your job each level is to place automated traps and trigger manual weapons to kill every boarder before they smash the cage and carry the commander to the airlock.

The pitch fits in one sentence. The design pillar fits in two: every level has three outcomes, not two. Once the cage is cracked it stays cracked for the rest of the level, so killing every boarder after that is a partial win — you cleared the room, but the tactical integrity of your deadlock was broken.

The spec marked that rule as non-negotiable in capital letters. Every later iteration — new weapons, new heroes, new room layouts — went through that lens. Did the new feature reinforce the cage-defense pressure, or just add offensive power against the spawn? The pillar held the design honest.

The Villain POV, Enforced at the Vocabulary Layer

The first design call after locking the cage rule was about language. The player is the villain in this game, and the framing has to land in every visible string. Internal code keeps neutral variable names like hero because grep is grep, but every user-facing label calls the incoming humans boarders, invaders, or rescue teams. The captive isn't being saved — he's being extracted. The mission isn't being defended — the deadlock is being maintained.

This sounds like a small thing. It isn't. Reverse tower defense games that fail to commit to the villain framing tend to feel like regular tower defense with the polarity flipped. Deadlock commits at the vocabulary layer, and that commitment is part of why the role feels distinctive in play.

Three Iterations in One Night

The first build night ran iter 1 through iter 3 in roughly 33 minutes between commits. The pace wasn't accidental — the structured pipeline that builds these games is designed to compress design-and-test loops, and Deadlock's tight scope let it move fast.

• Iter 1 — core loop only: one level (Cargo Bay), one boarder type (Marine), two weapons (Plasma Grid and Vacuum Vent), the three-outcome cage detection, base UI, persistent profile.
• Iter 2 — Admiral position mirroring in the render path, kill-path logic for boarders, larger touch targets for mobile, two new weapons (Arc Turret and Security Mech), a third weapon slot, lazy-init WebAudio SFX.
• Iter 3 — second level (Life Support), a star-map screen for level selection, a shop with persistent currency, two more hero classes (Sniper and Infiltrator), two more weapons (Drone Swarm and Spike Bulkhead), a first-play tutorial, and lift-selector and cage-stall pathing fixes.

The QA rubric scored the three iterations 46, 53, and 58 out of 60. Iter 3 cleared the ship threshold cleanly without needing a fourth pass. That's unusual for the pipeline at the time — most builds needed iter 4 to clear — and it's largely because the design pillar kept the scope tight.

Castle Doombad Rooms Weren't in the Spec

The original spec said almost nothing about room geometry. It described the cage, the airlock, and the requirement that boarders had to traverse the station to reach the cage. That was it.

The first room layout that worked well — narrow corridors, staircase staggers, ladders that competed with doors as paths, ceiling holes that opened a third lane of attack — emerged from a single commit a few days post-ship. It made the trap-placement decisions tactically rich without requiring a tile editor or a designer. Once the pattern proved out, it expanded into a five-stage progression over the following week, with each stage adding a layout twist: narrow rooms, then wave ramping, then a loop layout, then fully non-linear traversal.

The valuable lesson here was that pattern-emergence beats pattern-prescription. If the spec had locked in a specific room layout, we'd have spent the week debugging the spec instead of expanding the pattern.

Procedural Sprites First, Real Art via Feature Flag

Iter 1 shipped with everything drawn procedurally — fillRect, arc, polylines, no image assets at all. The walls were rectangles. The boarders were silhouettes built from primitives. The traps were geometric shapes with particle bursts on activation.

This was a deliberate scope decision. Generating a full sprite sheet would have blocked the first ship by hours. The procedural pass got the game playable; the visual upgrade ran on a separate track.

About a week later, sixty-three sprite PNGs landed across three phases (heroes and weapons, then environment, then UI and effects), gated behind an ASSETS_AVAILABLE feature flag. The flag pattern is worth keeping: it meant the procedural fallbacks remained intact for any device where the asset preload failed, and it let the asset rework iterate independently of the game logic.

The Walk Cycle That Couldn't Be Integrated

Roughly a week post-ship, a user report landed: the boarders looked like they were sliding instead of walking. Two existing sprite frames, no animation between them, and the result read as a glide rather than a step.

The first fix attempt was a walk-cycle integration PR — sixteen sprite frames, a four-frame cycle per boarder, full animation logic in the render path. The PR looked clean in review. It was merged. It broke the iframe load on the live page.

The PR was reverted within hours. The eventual fix shipped a few days later as something strictly simpler: track hero.facing as +1 or -1 based on movement direction, mirror the hero body via ctx.scale(-1, 1) when facing left, and add a sin-phase vertical bob (about 7% of a tile height) when in a walking state. Critically, each boarder gets a phase offset based on their ID, so a group of marines shuffles into the room instead of marching in lock-step.

Other Bugs Worth Mentioning

A few user-reported bugs shaped the post-ship improvement wave more than the original spec did:

• Wave 5 of 4. The HUD displayed an impossible wave count (WAVE 5/4) and the level froze. Two separate bugs: a HUD off-by-one in the wave-spawned path, and a stuck-state pathing bug where some heroes were alive but unreachable. Tightened the watchdog from 45 seconds to 25 so stuck states resolve faster, and added a diagnostic dump on watchdog fire so the next recurrence is targetable.
• Leaderboard freeze. A stale or partial LeaderboardWidget from cache mid-rotation could throw inside setMode, propagate up through endLevel, and kill the main loop. Added defensive guards at two layers.
• Trap sprites floating above slabs. The PNG sprites had transparent padding the source-clip wasn't compensating for. Multiple iterations of clip math, then ultimately solved by re-anchoring the sprites with zero transparent padding on anchor edges.

The Name

Deadlock was chosen over Containment, Kill Switch, and Sentinel Loop. The triple meaning landed it: the locked cage holding the captive, the stalemate the player is trying to maintain between spawn and exit, and the computing term for a process that can't progress — which fits the rogue-AI framing. Short, strong consonants, distinctive against the existing thirty-plus-game roster, no token collisions in the name-check pass.

What Makes Deadlock Different

Reverse tower defense as a genre is less crowded than regular tower defense, but it still has well-established conventions. What Deadlock adds to those conventions is the cage-as-second-axis design — every tactical decision has to account for both the kill rate and the cage exposure, and the partial-win state means there's always something left to play for even in a level you can't fully ace.

The tight scope (one captive, one airlock, three outcomes) keeps the decision space legible. The Castle Doombad-style room layouts keep the trap placement interesting. The villain framing keeps the role distinctive. None of these were obvious until the spec committed to them — which is the broader lesson here: the design pillars matter more than the feature list.

Related: Free Tower Defense Browser Games: Play Online Now · How We Built CyberCircuit · What Is Vibe Coding? · Vibe Coding Tools: From Chatbots to AI IDEs