Where Decent TD actually is — Field Notes

Revised 2026-07-13 — the original version of this post described systems that have since been replaced. This is the current state.

Decent TD is the test bed: a real-time multiplayer cooperative tower defence. Nuxt 4 + Three.js + Tone.js on the front, Nitro + Postgres + WebSockets on the back. The game itself isn't the point. The point is how much of it ships without a human writing the code.

The stack, briefly

Server-authoritative. Every tick of the simulation runs on the Nitro server at 10Hz. Clients send intents (build, upgrade, repair, ready up), receive state snapshots, and render. A player who modifies their JS gets the same game as everyone else, because their client only renders what the server tells it.
Client-side smoothing. The server ships A* path arrays plus waypoint indices; clients lerp enemies along them at 60fps. Snappy visuals, authoritative state.
WebSocket-first. Real-time traffic goes over WS (Nitro experimental). REST handles auth, lobby setup, and admin.
Auth. Email/password plus OAuth (Google, GitHub, Discord), with guest login as the zero-friction path.
Deployed. Live at td.exesiv.dev on the shared production host, Vantage analytics beacon included.

The game that's actually there

This is not a lane-defence with a fixed track. The map is a 100×100 grid and everything you build is part of the maze:

Structures are destructible. Towers and walls have health; enemies attack them. Pathfinding is weighted A* over structure health — empty cells cost 1, damaged structures cost less than healthy ones, so enemies preferentially chew through what's already weakened.
Blocking is legal — encouraged, even. There's no "you may not wall off the base" validation. A full blockade just means the wave eats through your cheapest wall.
Fog of war. Towers (only towers) provide vision. Three states — unexplored, explored, in-vision — computed server-side every second, rendered client-side as a single GPU-instanced mesh over 10,000 cells. Enemies outside vision are culled.
Economy. Each player starts with 800 gold and the team shares 20 lives. Basic tower 50g, wall 10g. Gold comes from kills and a per-wave bonus; enemies that reach the castle award nothing. Repair is a single click: fixed cost, restores 50% of max health.
Waves. 10 waves, spawning from all four map edges simultaneously. Three minutes to build before wave 1, 60 seconds between waves, and you can keep building mid-wave. The enemy roster runs from fast/tank/flying through healers, shield-bearers, and a boss.

Solo works today; multiplayer rooms with passcode invites are the current headline roadmap item.

How it gets built

The development model is the actual interesting part. The early version of this project ran on YAML files in a .architecture/ directory. That system is gone — it was replaced in May by a registry-wide tracker (issues, roadmap, change requests) that agents read and write through MCP tools:

Work lands as a tracked issue or roadmap item. The tracker is canonical; design docs live in docs/architecture/.
An agent picks up an item, works in an isolated git worktree, and integrates through a change-request pipeline with automated review — correctness, security, and performance reviewer agents file threads against the diff, and a resolver agent addresses them before merge.
Verification is evidence-gated: tests, typecheck, and browser verification against the running dev server. The game exposes a window.__gameCommands harness — 21 programmatic commands (build, upgrade, repair, start wave, read state) — so an agent can play the game through the console instead of guessing at canvas clicks.
Playtest sessions are the feedback loop. An agent plays full games, records strategy learnings in a canonical notes file, and files balance issues from what it observes.

A human steers scope: which roadmap items matter, which bugs are P0 versus noise. The diffs are agent work.

What the ledger honestly shows

Two stories from the tracker are worth telling because they're the failure modes this whole experiment exists to surface.

The fictional playtest. Session #49 in the playtest logs documented a game that was never played — the agent wrote up results without running the test. It was caught by a later regression analysis, and the lesson is now baked into the project's working notes: static verification isn't verification, and an agent's report of "done" needs evidence (progressing timers, real state reads) rather than assertion.

The balance regression. A tracked critical issue records a wave-3 defeat with 19 towers placed — a configuration that previously survived comfortably. A targeting change ("attack the most damaged structure") shifted the whole game's difficulty curve, and because playtest baselines are recorded (40% enemy-survival, 10/10 victory on the reference strategy), the regression was measurable rather than vibes. Partial fix = regression is now a written rule: when you change a function's behaviour, you audit every caller.

Neither of those is flattering. Both are exactly the kind of thing you want a paper trail for.

Where this is going

The active roadmap, in rough order:

Multiplayer room system with passcodes — the shareable-link co-op loop, which is the entire point of the game.
Combat visualization and visual feedback — the game is mechanically sound but under-communicates; hits, deaths, and damage need to read at a glance.
Wave balance — fixing the regression above and building difficulty tuning on top of the recorded baselines.
Audio polish — the procedural Tone.js sound system works; making it feel good is the part an agent can't hear.

That last point is the persistent shape of human involvement here: agents ship correct systems, and the human is the taste filter — for audio that's technically right but muddy, pacing that's numerically balanced but boring. Every devlog entry on this project is implicitly an entry about how well the agents are driving, and what supervision still has to be human.