The pipeline behind ChampChase

A premium game is not a big website. It is a fight engine, a campaign, an economy, an inventory, a shop, a save system, a dialogue system, an audio director and a hundred screens that all have to agree with each other. A studio solves that with fifteen to thirty people and a year. I had one person and no prior game-development experience.

The naive version of "use AI for it" fails immediately and predictably: one session, one conversation, and a codebase that drifts out from under you until nothing compiles and nobody — human or otherwise — can say which change broke it. Throughput was never the hard part. Knowing what was true after each change was the hard part. So I built for that instead.

A launcher script opens six sessions in a grid across two monitors. Each is assigned a non-overlapping set of files — the fight engine here, the campaign manager there, UI, audio, saves, content validation — so two of them can never be editing the same thing at the same time. Ownership is enforced by a lock protocol: a folder of lock files, claimed before work starts and released after. Deliberately the dumbest mechanism that could work, because a coordination system nobody can debug at 2am is worse than no coordination system.

I sat in a seventh window as the coordinator. That role is not supervision, it is the actual job: assigning work so the slices stay disjoint, holding the architectural picture none of the six can see, and reconciling documentation when parallel sessions inevitably contradict each other. When six things move at once, the scarce resource is not code — it is a single consistent account of what the system now is.

It is not tidy. After one six-way run I spent an hour reconciling thirty-five missing history entries, and eight passes were never recovered — I still don't know what they did. I'm including that because a method described only by its good days is a sales pitch, not a method.

Nothing here is a conversation. The unit of work is a pass, and a pass has a fixed shape:

Weeks of fast iteration left every screen in the game holding broken references — the engine stores component links by ID, and after enough restructuring those IDs pointed at things that no longer existed. Eleven attempts to repair one screen conventionally all failed. So I stopped repairing.

The replacement pattern: disable everything the editor had serialised rather than destroying it, rebuild the entire interface from code at runtime, then re-point every reference at the freshly built objects. Downstream code cannot tell the difference. Applied across all thirteen screens, the worst offender went from 1,713 lines to 913 — smaller, faster, and it actually worked.

That call — stop fixing this, replace the mechanism — is not something a build pipeline arrives at on its own. It came from watching eleven failures and concluding the approach was wrong rather than the attempts. It is the same judgment I get paid for on client work, and it is the part that does not come out of a tool.

The same pass discipline ran the asset production, because a game is mostly content and content rots the same way code does:

• Art — 36 unique fighter portraits, 15 background environments and 702 item icons, every one produced through the same generate-review-regenerate-export loop. No asset store, no stock sprites, no placeholder that quietly became permanent. It all looks like it belongs together because it all came out of one pipeline.
• Music — 366 original tracks across 23 mood packs, scored to the moment rather than looped over it.
• Voice — over 3,600 generations across 20 characters, taking the campaign to 1,002 fully voiced lines.

The unglamorous half is the half that matters: one pass was nothing but placing 702 icons into the exact folders the loader expected. Pipelines are mostly that, and skipping it is why most of them quietly stop working.

A studio budgets this scope at somewhere between half a million and a million dollars: two or three engineers, an artist, a composer, a sound designer, a QA function, and six to twelve months. The tooling for this build came to roughly €800.

That gap is the argument for the method, and it is worth being precise about what it isn't. It is not an argument that the work is cheap — the fifteen weeks were mine, and the judgment in them is the expensive part. It is an argument that the ceiling on what one person can responsibly ship has moved, and that a business sitting on a backlog of "we'd need to hire for that" should re-check its assumptions.

Strip out the game and the architecture is the deliverable: work split into slices that can run at once without colliding, a lock or ownership rule so they don't, a fixed pass shape ending in verification, and a written record so the next pass starts from fact instead of assumption. That is what a custom workflow build is — an audit of where your repetitive work actually goes, then a pipeline that removes it, built around the process you already run.

It is also the reason the rest of the work on this site holds up. The same discipline audited a multi-tenant SaaS against itself, found 355 things wrong with it, and closed every one before it went live. A pipeline that cannot fail its own output is not a pipeline. It is a very fast way to ship a mistake.