MILES GERMER · TECHNICAL ARTIST · CINEMATIC SYSTEMS · AI-AUGMENTED PRODUCTION
← All work

Rift Fighters — Playable Combat Prototype

A fully playable card-combat prototype, eleven versions deep, with an in-game tuning drawer and an automated balance harness. Play it in your browser.

Rift Fighters combat prototype splash screen
01 · Problem

Can a two-button input carry a whole fighting game? Does a card-driven exchange (pressure, reaction, feint, result) read and feel good with time dilation as the resource? You cannot settle those questions from a design doc. You have to play them. So I built something to play.

02 · What I did

I built a self-contained, browser-playable combat prototype for Rift Fighters and iterated it across eleven versions. It runs the real design: a five-slot stamina-gated hand where the same card is offense or defense depending on context, three weight tiers each with a distinct job (lights buy tempo, heavies pay off, mids blend), a colorblind-safe card face tuned for a five-second read, and a full grab/guard/dodge triangle behind a rules flag so the team could A/B a rules change inside one build.

Two things make it more than a toy. First, an in-game tuning drawer: the entire card pool (damage, weights, costs, even deck composition) lives in config, so anyone can retune balance by editing data and export or import a balance pack, no code change. Second, an automated tuning harness that runs thousands of simulated fights and produces balance reports no five-person team could hand-generate. The prototype also exports a full markdown log of any fight for feedback.

Alongside it I wrote the design canon it implements: an operational card schema, a naming grammar with the rule that a card's name may never lie about what it does, and a documented card-face priority order. Unproven decisions are tagged in the docs as strawman, so the team always knew what was settled and what was still contestable.

03 · Credits
Game design, card system, combat model, tuning framework, direction, daily playtestingMiles Germer
Prototype and tuning-harness implementation, under my directionAI (Claude and others)
Self-contained HTML applicationNo engine, no install
04 · AI's role

I designed the game and directed the build; AI wrote the prototype's code and the simulation harness against my specs and playtest notes. The loop was mine: play, diagnose what did not read or did not feel right, decide the fix, direct the change, verify by playing again. The design judgments (what each weight tier is for, why pure-mid is deliberately weak, what the card face must show first) are the part no model produced.

05 · Result

A real game you can play right now in a browser, eleven iterations refined, with a tuning drawer and a balance-simulation harness behind it. It answered its core question (the exchange loop reads and plays) and it is the clearest single artifact of how the studio turned design questions into playable answers fast.

06 · What I learned

Build the thing you are arguing about. Every hour spent debating whether the loop would feel good was worth less than one build you could actually play.

The prototype also proved the data-not-code discipline: once the whole card pool was config, tuning stopped being engineering and became design, which is where it belongs.