We Shipped Our Second Game Faster Than I Thought Possible — Here’s What Changed
I’ve been building games as a solo indie developer under Compliment Circle Games for a while now. Our first game taught me a lot about scope creep, about how long polish actually takes, and about the gap between “it works” and “it ships.”
For our second game — American Simulator, a satirical Oregon Trail-style road trip game set on Route 66 — I decided to try something different. I leaned hard into AI-assisted development with Claude Code and a set of structured workflows called Superpowers skills. The results genuinely surprised me.
Here’s what I learned.
What Is American Simulator?
It’s a mobile game where you drive Route 66 from Chicago to Santa Monica, facing real-world American crises along the way — rent increases, SNAP cuts, ICE detainments, surge pricing, wildfires, drunk drivers. Every choice shifts a hidden ideology score that determines one of three satirical endings: Trump’s America, Blue State Status Quo, or Socialist America.
Dark? Yes. Funny? Also yes. Timely? Uncomfortably so.
You can play the web beta right now at americansimulator.czrber.net.
The Workflow That Changed Everything
It started with a loose idea document — bullet points, half-formed concepts, vibes. Not something you could build from.
The first skill I reached for was brainstorming. I fed it my rough notes and it asked clarifying questions one at a time, pushed back on scope, proposed a few different approaches with tradeoffs, and then synthesized everything into a proper Product Requirements Document. That PRD became the foundation for every planning and implementation conversation that followed. Without it, I’d have been building against a moving target the whole time.
From there I used writing-plans to kick off every feature. Instead of jumping straight into code, I’d describe what I wanted to build and the skill would generate a detailed implementation plan — specific files to create or modify, exact code to write, commands to run, and expected outputs at every step.
Then I’d hand that plan to subagent-driven development, which dispatched a fresh AI subagent per task, ran a spec compliance review after each one, then a code quality review. Nothing moved forward until both reviews passed.
The result: I could describe a feature at a high level and watch it get built, reviewed, and committed — task by task — without losing track of what was done or what still needed doing.
For a solo developer wearing every hat, this felt like suddenly having a small team.
TDD Kept Me From Shipping Broken Things
Every task in every plan started with a failing test. Write the test. Watch it fail. Implement the minimum code to make it pass. Commit.
Using GDUnit4 for Godot, this discipline paid off in ways I didn’t fully appreciate until mid-project. When I added supply choices to the event system — a mechanic where owning camping gear or a gas can unlocks better options during certain events — the test-first approach meant the data validation tool, the scaffold tool, and the event JSON format were all verified before a single new event was written. The five new events that followed were essentially data entry.
TDD doesn’t just catch bugs. It keeps you focused. When you have to write the test first, you’re forced to define what “done” actually means before you write a line of implementation. That clarity is underrated.
Manual UI Testing Is Still Non-Negotiable
I want to be honest about one thing: the AI couldn’t replace me clicking around in the game.
The most stubborn bug of the project was the companion health HUD floating half off the top of the screen. The AI made changes to the scene file, I’d rebuild the web container, and… nothing moved. We went through several rounds before discovering the root cause: Godot 4 resets offset_top and offset_bottom to zero when a parent scene overrides layout_mode on an instanced child node. Changes in the .tscn file had zero effect at runtime.
The fix was a one-liner in _ready() — set the offsets in code, not in the scene file. But finding it required me to actually look at the game, describe exactly what I was seeing, and iterate. No automated test would have caught that. No static analysis either.
UI bugs live in the gap between “what the code says” and “what the player sees.” That gap still requires human eyes.
Quick Turnaround on Changes — Including Merging Two Screens
One thing I genuinely didn’t expect was how fast I could change my mind.
Midway through development I decided two separate screens needed to become one. I described the change, and it was done — including updated navigation logic, shared state, and regression-tested — faster than it would have taken me to fully context-switch into that part of the codebase alone.
The same was true for smaller requests. The How To Play overlay, the bottom-of-screen legal footer with live links, the version number display — each of these was a five-minute conversation, not a two-hour implementation session.
When you can iterate that quickly, you stop self-censoring good ideas because they feel like “too much work.”
What I’d Tell Other Indie Developers
Write the plan first. Even if you don’t use AI to execute it, having a written plan with specific files and expected outputs forces clarity that saves time.
TDD is not overhead — it’s a forcing function. The discipline of writing failing tests first keeps scope honest and gives you a safety net when you inevitably touch something you didn’t mean to.
Use AI for execution, not judgment. The subagent workflow was excellent at implementing well-specified tasks. It was not a replacement for playing the game, noticing that something felt wrong, and deciding what to fix next. That part is still yours.
Ship something real. American Simulator is a satire, but it’s a real game — real events, real choices, real endings, real AI-generated art and sound effects. The goal was always a playable product, not a technical demo.
American Simulator launches July 4th, 2026 on iOS, then Android, then web. The beta is live now — play it here.
If you’re building something and wrestling with scope or velocity, I’m happy to talk about what worked and what didn’t.
— Seth Surber, Compliment Circle Games
Built with Godot 4.6.3, Claude Code, and an uncomfortable amount of reading the news.