DEV Community

Cover image for AI Doesn't Replace Experience. It Compounds It.
Zeppelin_Tsai
Zeppelin_Tsai

Posted on

AI Doesn't Replace Experience. It Compounds It.

AI Doesn't Replace Experience. It Compounds It.

How I deliberately reduced scope until I finally shipped a game.

My previous project was a Godot RPG.

Every month it became larger.

Every month it got further away from release.

At some point, I realized I wasn't building a game anymore. I was building an endless project.

So I did something that felt completely backwards: I deliberately reduced the scope until I could finish a commercial game in three days.

A little context first: I'm a software engineer by trade, not a hobbyist picking up code for the first time. That matters for how this story goes.

Stage 0: The Plan

I wanted one more finished commercial project for my portfolio — something with real scope, not a toy demo. My existing Godot RPG kept growing every time I touched it, so I deliberately picked a different kind of project this time.

I evaluated a few genres and landed on a card game. The reasoning was practical:

  • The rules already exist. Players already understand them.
  • No enemy pathfinding, no level editor, no procedural generation to debug.
  • A small amount of content can still feel complete.

Big Two was the obvious fit.

My goal wasn't to build my dream game. My goal was to relearn how to finish one.

Dream games don't disappear. Momentum does.

For the tech stack, I went with what let me move fastest: HTML5 + Phaser 3 + Vite + TypeScript. Not because it's the most powerful option out there — because I already knew it well enough to stop thinking about tooling and start building.

Then I wrote a real design doc — not a novel, just enough to build on: core Big Two + item system rules, a rough story outline, and the first two opponents' names and personalities. Everything else was allowed to evolve during development.

Stage 1: Building the Skeleton

First priority: get the core loop playable and prove it was actually fun.

I kept repeating one rule to myself:

If the base card game isn't fun, nothing built on top of it matters.

Claude Code did the initial heavy lifting on the rules engine. After that, I rotated between Codex and Copilot to keep development moving — not because of some elegant multi-agent strategy, but because agent usage limits are real, and switching tools was just what happens when you burn through one and need to keep going. I also kept a web chat window open the whole time for architecture decisions. Think of it as a rotating shift schedule, except the workers were AI agents and the shift changes were dictated by rate limits, not the clock.

During this stage, every visual asset was a placeholder — plain shapes, icons, or SVGs. No feature was allowed to wait for final artwork. The priority was making sure the systems were actually wired together: save/load, multiple endings, a full playthrough from start to finish. If I couldn't click through the entire game with colored rectangles standing in for art, no amount of polish later would fix that.

Stage 2: Art

For art, GPT Plus was enough — but the prompting had to be deliberate. Consistency was the hard part, not raw output volume.

Before generating any story CG, I locked in character designs and room/background references first. Every new illustration reused those references, so characters and locations kept the same visual identity instead of looking like a pile of unrelated generated images stitched together.

Most of the work wasn't generating images. It was preventing visual drift.

One concrete example: instead of generating expressions one by one, I generated them as a single sprite sheet and sliced them afterward — same character, same lighting, same style, no drift between frames.

This stage also ran in parallel with something I had zero control over: itch.io's publisher onboarding — payout mode, tax interview, PayPal linking. That process wasn't something I could speed up by working harder, so I started it as early as possible and let it run in the background while the art pipeline continued.

Game development isn't just writing code. You also need to finish the boring administrative work before launch.

Stage 3: Audio, Polish, and the Debugging Pit

Audio came from two sources: Kenney (CC0 sound effects) and StockTune (subscription-based music, public-domain licensed). Once the bulk of content was in place, I built out a gallery/unlock mode, then hit what I can only describe as debugging hell — chasing down BGM lifecycle bugs, save-state edge cases, and animation polish, one at a time.

Shipping an EXE didn't end debugging. It simply introduced an entirely new species of bugs.

The Three-Day Thing

I never planned to market it as "a game made in three days."

Near the end, I looked at the Git history and realized something. If I pushed a little harder, it could actually be finished in three days. So I did — with some late nights involved.

Ironically, the biggest productivity boost wasn't AI code generation. It was automated testing.

That's the part I'd actually recommend to other solo devs: HTML5 + AI-assisted development pairs extremely well with Playwright. Automated browser testing cut my manual QA time dramatically — every rules-engine change, every UI tweak, got verified by an actual browser session instead of me clicking through the same fifteen steps by hand, again and again.

Automated testing multiplied everything AI generated.

But if I'm honest, the real reason this moved fast wasn't the tooling at all. It was that I was building for myself, wearing two hats at once.

As a player, I already knew what kind of experience I wanted.

No filler.

A few genuine surprises.

Good-looking art.

A satisfying ending.

As an engineer, I already knew how to get there.

How to structure the systems.

How to keep the code maintainable.

How to stop adding features.

Knowing both sides meant I rarely got stuck asking, "What should I build next?" The design doc, for what it's worth, took about three hours to write. Everything after that was execution, not discovery.

Tools & Resources

Tooling: VS Code, GitHub, HTML5, Phaser 3, Vite, TypeScript, Claude Code, Codex, GitHub Copilot, ChatGPT Plus, Playwright, Electron, and a small custom Python + Pillow script (asset_builder.py) for batch PNG → WebP conversion.

Audio: Kenney (CC0 sound effects) and StockTune (AI-generated public-domain music).


Three days sounds impossible.

Until you look at the Git history.

Here is what those three days actually looked like in Git:


No giant leap. Just hundreds of tiny steps.

Looking back, I don't think the interesting part of this story is the three days.

It's something else.

As a player, I'd already spent years learning what kind of games I enjoy.

As an engineer, I'd already spent years learning how to build software.

AI didn't give me those experiences.

It simply let me move through them much faster.

AI accelerated execution.

Experience accelerated decisions.

Reducing scope made shipping possible.

That experiment eventually became DULAN: a story-driven Big Two game in which every opponent has their own room, music, personality, and reactive dialogue, with multiple endings tied to how you choose to play.

Every commit was small. None of them felt important while I was making them.

Looking back, they weren't just building a game.

They were compounding years of experience into something I could finally ship.

Top comments (0)