I've been building a post-apocalyptic geo-location game with Claude Code for months. Here's what that actually looks like.
I'm a solo dev building Scorched Reach (app link here). Claude loves to call it "Pokemon GO meets Fallout," but I prefer post-apocalyptic Foursquare - the old app where you could be king of your favorite restaurants and bars. Players move through real-world space to claim POIs, scavenge for gear, send recruits on missions, and eventually fight each other. The stack is vanilla HTML/CSS/JS, Leaflet.js with OpenStreetMap, Supabase (Postgres 17 + PostGIS + Edge Functions), and Cloudflare Pages for deployment. No framework. No React. Just ES modules and a deep appreciation for what PostGIS can do.
My workflow started with two separate sessions. One in ChatGPT for planning, eventually migrated to Claude, handling design work, system breakdowns, DB schemas, and drafting prompts for implementation. The second session was always Claude Code with direct filesystem and Supabase MCP access for execution. Keeping them separate prevented the implementation session from accumulating so much context that it started making assumptions about code it hadn't actually read. After a few weeks I learned to prompt CC more efficiently and dropped the planning session entirely.
One of the most satisfying parts of the project has been finding places to pull in real-world data. The map layer uses OpenStreetMap tile data, but the POI engine also reads OSM tags to classify what's claimable in your area. A hospital becomes a Medic-class bonus POI. A warehouse becomes a Scrapper/Engineer zone. The game reads your actual neighborhood and renders it through a post-nuclear HUD filter until your city looks like a wasteland.
Another real-world hook I was proud of in concept is the Flare Gun system. Firing a Flare Gun in-game calls the OpenSky Network API to query real airspace over your coordinates. If there's actual air traffic overhead, an airdrop event triggers. If the skies are clear, nothing happens. It failed in production because Deno Deploy kept timing out on outbound connections to OpenSky, so it's sitting in the backlog. But when I was prototyping it locally, it was one of those moments where real-world and game-world collapse into each other in a way that's hard to explain. After years of playing Seven Days to Die, my daughter and I still look at each other when a plane flies overhead and say, "Airdrop!"
The third real-world integration is GPS-gated gameplay. Most actions require the player to be physically within a configurable radius of a POI, enforced server-side by PostGIS's ST_DWithin against the player's reported coordinates. You can't trust the client, so the boundary check lives in a Supabase Edge Function with a service-role client after JWT verification, not in the browser. Players who try to spoof their location get a clean rejection, not a client-side illusion.
What's going really well is the admin control panel. I built a full ACP that lets me tune basically every number in the game at runtime without a deploy. Scavenge yield rates, recruit travel speeds, XP multipliers, gear condition decay, combat modifiers. All of it flows through a game_balance_settings table with a profile system for overriding individual values. Tuning a live game is chaotic by default, and having the ability to just turn a knob and watch the effect without a push has been essential. Claude Code is particularly good at this kind of tooling work because it can hold the whole schema in context and wire up UI to RPC to table in one shot.
What hasn't worked cleanly is the gap between "Claude is very confident" and "Claude has actually read the file." Early on I got burned repeatedly by the model making plausible-sounding edits to files it had hallucinated the structure of. The fix was a hard rule I call Recon-Before-Fix. No implementation pass, ever, without a read-only diagnostic pass first. It sounds obvious, but it's non-obvious how often the model will skip it if you let it. Now every implementation prompt explicitly states "recon first" and I don't accept a diff until I've seen evidence that CC read the relevant files.
The other thing that bit me hard was Supabase's PostgREST behavior around ambiguous foreign key joins. I had a query that worked in development and silently returned empty arrays in production with no error and no log entry. When a table has two foreign keys pointing to the same target, PostgREST returns HTTP 300 with no rows and no Postgres-level error. I only found it by reading raw network responses. The fix is explicit FK column hints in your join syntax, but it cost me an afternoon to isolate. That kind of silent failure is genuinely dangerous in a vibe-coded project where you're moving fast and relying on the model to flag obvious problems.
My agent naming system has been unexpectedly valuable. I had ChatGPT create a whole roster of specialized personas (see them here). Each one has its own context file I load at the start of a relevant session. It keeps prompts scoped without burning context on irrelevant history. When I'm working on a complex Edge Function deploy, I load Cassidy's context and the conversation stays tight. It's not real multi-agent orchestration. It's more like having a different hat for different work. But it prevents the drift that happens when one session tries to hold everything.
The honest reflection on vibe coding at this scale: it works, but it requires a different kind of rigor than traditional solo dev, not less. The failure mode isn't "the code doesn't run." It's "the code runs, does something plausible, and is subtly wrong in a way that only surfaces under a specific player sequence six weeks from now." The discipline I've had to build is not trusting output without recon, not accepting confident diffs that touch more than three files, and not letting the model refactor adjacent code while fixing a bug. The project is genuinely further along than I could have gotten without AI assistance. But the sessions that went sideways all had one thing in common: I let the model move before it had read the terrain.
Anyhoo, feel free to check it out here until I get the actual app built. There are a ton of bugs. but it's still fun to lay claim to your favorite places. It's still very much in development, so be patient with me.
