Back to Directory
Games

Deadhead - Robotaxi Fleet Sim

Autonomous robotaxi dispatch simulator packed into a single 1.5 MB HTML file.

Built bykotyzap
usingClaudeCursor
Build Time: Days
AI Coded Ratio95%
Launch Live AppShare on X
https://game.deadhead.cc
Deadhead - Robotaxi Fleet Sim

Description

Site: https://deadhead.cc - free, open source, no account, runs offline.
Game: https://game.deadhead.cc - free browser game

How it got built

Whole thing is one HTML file, under 1.5 MB (19,500 lines). No build step, no framework, no bundler. That constraint was the single best decision I made - the model can hold the entire game in context, so "the charger panel overlaps the offer board on ultrawide" is a fix, not an archaeology expedition.

What worked

  • Simulation first, UI second. I got the economics loop correct in plain JS before a single pixel existed - deadhead miles, time-of-use electricity tariffs, 25% vs 15% platform commission, depreciation/energy/maintenance/insurance/software cost lines. Once the numbers were honest, the UI was just a readout.
  • Real data as a guardrail. Six real cities (Austin, Dallas, Miami, Tampa, Orlando, SF), real charging sites with actual stall counts and peak kW, real tariff curves. Hallucinated plausible-sounding numbers are the default failure mode of vibecoding a sim; pinning to reality kills it.
  • One screen, twelve elements. Every feature request had to earn a slot on a console that already had a city selector, bank, speed control, fleet roster, offer board and cost breakdown on it. Nothing got its own page.
  • Time compression as a difficulty dial. 1× / 4× / 20×, locked to 1× in the final act. Cost nearly nothing to implement and does most of the pacing work.

What didn't

  • Mobile. By far the hardest part. The rule was: the game has to stay playable on a phone, not just render - no cut-down "mobile version", the same twelve-element console, same economy, same dodge mini-game. That rule cost more rounds than any feature. Touch targets came in at 23–30px and had to grow without breaking the desktop layout; the dodge pad needed touch-action / user-select hardening because iOS turned rapid taps into text selection; the tutorial's "dim everything except this control" spotlight turned out to be impossible with CSS filters (they clip), so it became a separate scrim layer; and anything below the fold on narrow layouts needed explicit scroll-into-view calls. The model is bad at this: it can't see the phone, so every fix was me on a device, describing what I saw, round after round.
  • Saves. Save shape is on v9 with migrations. The worst bug shipped in v0.123: reload, click Resume, your cash is back to the starting $800. Cause: the render loop kept ticking under the resume modal and one line wrote the fresh-state cash into the progress record before restore ran. A player with $5k lost $4.2k. Vibecoding is great at adding features and quietly terrible at state that has to survive a reload.
  • Balancing. Starting cash went $7,500 → $3,000 → $1,000 → $800 across four rebalances. The SF end goal went from $38k to $100k, then goals got reframed as ceilings instead of targets. A financed car had no loan balance for ~20 versions - an infinite money glitch nobody noticed because the numbers looked right. Honest economics is not the same as balanced economics.

Stack and tools

Claude (Cowork + Claude Code), one HTML file, 81 jsdom test files, a Cloudflare Worker + D1 for optional cloud saves. First commit 25 July, v0.123.6 a week later — a couple of those nights were not nights — then polish through early September, 151 release notes total. Saves are local or cloud with key derivation done in-browser, so I never hold anything.