**The project:** [nodecontrol.gg](https://nodecontrol.gg) : a competitive multiplayer territory-control .io game set inside a neural network. Free, browser, no install. Built for Vibe Jam 2026.

**The build:** 30 days, solo + Claude. Now live in production: 4-region anycast, mobile support, telemetry, in-game help, FTUE.

# Stack

* **Client:** Three.js (WebGL), vanilla JS, single HTML entry, all visuals procedural (zero external assets: no models, no textures, no sprite sheets).
* **Server:** Node.js + `ws` (WebSocket), authoritative game state, 60Hz tick.
* **Audio:** All sound effects are procedurally synthesized via the Web Audio API, down to the boost burnout sweep and the elimination crunches. The BGM itself is external `.ogg` tracks streamed through `HTMLAudioElement`.
* **Deploy:** Cloudflare Pages (client, free unlimited bandwidth) + Fly.io 4-region anycast (game server, \~$8/mo).
* **AI:** Claude throughout. Roughly 1% Sonnet, 80% Opus 4.6, and 19% Opus 4.7. All of it working from plan-first docs that I'd written by hand before starting any implementation.

# Process

1. Before any code, I wrote a PRD and a DESIGN doc by hand to capture the gameplay, network protocol, and visual language. These docs were then "locked". Heavy emphasis on the quotations. Many of the decisions in those docs actually shifted as the build surfaced assumptions I'd gotten wrong, and recognizing *when* to deviate was where my expertise mattered most. If the AI adhered too strictly to the original docs, we'd have continued down paths that no longer made sense. If it ignored them entirely, we'd have re-visited every decision every session. The right balance lived in the middle, and keeping it there required active human judgment.
2. I broke the build into 14 numbered phases (rendering → movement → basic gameplay  → multiplayer → bots → UI → mobile → audio → polish →  FTUE →  deploy → analytics → final polish  → submission).
3. Each phase was a structured implementation pass. The AI did most of the typing; I reviewed every diff and ran, judged, and did minor polish adjustments on each phase despite having dedicated polish phases. 
4. Persistent memory files kept the AI oriented across sessions: rules learned, project state, and references to where things lived in the code.

# What AI did well

* Boilerplate-heavy Three.js work (instanced geometry, shader uniforms, scene setup).
* Translating game logic between client prediction and server-authoritative state.
* Audio synthesis from natural-language descriptions.
* Implementing the FTUE / hint system from a key-list spec.
* Settings UI, telemetry pipeline, region picker, mobile touch controls.

# What needed me

* **Feel.** The AI is happy to implement RTT measurement and lag compensation, but only a human can sit down with the deployed game, notice that the boost feels worse on production than on localhost, and get an actual headache after 30 minutes. That subjective evaluation is irreducibly human.
* **Catching production bugs.** I shipped to production with a bandwidth leak that made every idle client fire 12 HTTPS region probes every 5 seconds for their entire session, roughly 4.4 GB per month per idle client. I spotted it post-deploy by reading the network panel out of curiosity, and the AI hadn't flagged it in any of the code reviews leading up to that deploy. You must be aware of what the AI is doing or it will cost you. Literally.
* **General debugging.** The AI is excellent at implementing well-defined changes, but it can lock onto a wrong conjecture about the cause of a bug and keep digging deeper into it rather than questioning the premise. Several times in this build, the AI was confidently chasing the wrong cause, and the only way out of the loop was for me to step back and redirect: "you're assuming X, but we haven't actually verified X. Let's check that first." Without that human override, those sessions would have continued indefinitely.
* **Stopping scope creep.** The AI is always willing to add more features and abstractions, and the discipline of saying "we don't need that yet" has to come from me.

# Three war stories

**Netcode iteration.** When I deployed to production, the game felt significantly worse than it did on localhost. Direction changes would snap back, the player would oscillate at max speed, and after about 30 minutes of play I'd get a real headache since I have a motion sensitivity. Fixing it took multiple iterations: bumping the server tick rate from 40Hz to 60Hz, switching from EMA-based latency estimation to a sliding-window minimum (because the EMA was latching onto outlier packets in the wrong direction), adding a dead zone on the reconciliation blend so per-packet RTT jitter wouldn't keep yanking the position, and adding a queue mirror so the client and server made the same queue-vs-immediate decision against the same threshold. The final state is smooth at the cost of about 50 to 80 ms of perceived input delay on direction changes during boost. Localhost still feels great, and the residual gap is irreducible without a substantial architectural rework. I wrote a 5-page postmortem afterward to capture the diagnosis, the fixes, and the experiments that didn't pan out.

**The bandwidth bug.** I shipped to production with a bandwidth leak hiding inside what looked like a clean piece of code. The region-probe handler was being re-fired unconditionally on every RTT update, which meant every player, including ones in the middle of a round, was firing 12 HTTPS region probes every 5 seconds for their entire session. I caught it after deploy by reading the network panel out of curiosity. The fix was roughly a 99% reduction in idle traffic: I decoupled the probes from the RTT update, paused the pings whenever the tab was hidden or the window was unfocused, and only re-fired probes when the user actually opened the region-picker dropdown. The cost for a single player would have been trivial, but at 1000+ idle clients it would have been a real bill. The takeaway is that the AI's first-draft output is scaffolding rather than solution. The original code looked fine and passed every review.

**The Vite env file location.** I spent an entire deploy cycle wondering why the production WebSocket URL wasn't being baked into the build. The cause was that Vite reads `.env.production` from `envDir`, which defaults to whatever `root` is set to in `vite.config.js`. My config had `root: 'src'`, but I'd put the env file at the project root, where Vite was silently ignoring it. The AI had generated the right config; I'd just dropped the env file in the wrong directory. A small lesson, but a representative one: the AI tends to produce a coherent skeleton, and the slip-ups tend to live in the seams between that skeleton and the rest of your environment.

# What I'd do differently

* I'd spend more time on the rendering pipeline and dynamic LOD, because I hit performance ceilings late and had to retrofit fixes around features I'd already shipped.
* I'd treat the AI's first-draft output as scaffolding rather than as the solution. The bandwidth bug lived inside code that looked fine and passed every review, and that pattern repeats. The AI produces a coherent skeleton, but the load-bearing details deserve a second pass.
* I'd read the wrangler and Fly secret-handling steps end-to-end before the first deploy, because small misconfigurations were the largest chunk of solo debugging time in the entire build.

Live at [nodecontrol.gg](https://nodecontrol.gg). Feedback welcome, especially on netcode feel.

I've been in game dev for over 20 years and just tried vibecoding a production-quality competitive multiplayer .io game in 30 days. Here's the honest breakdown.