BOSTON, JUNE 2, 2026 — 16bitfit, paused
16BitFit
◐ PIPELINE 47% · GAME ON SHELF
─ OPENER ─
I had every intention of making a 16-bit fitness game where you punch your way through a roster of cartoon brutes between sets of actual pushups. I had the fighter sketches, the punch-frame storyboards, a Phaser project with a working hit-stun timer, and the kind of unearned optimism that comes from picking a side project with a name as pleased with itself as “16BitFit.” What I did not have, three months in, was a sprite pipeline I could trust to produce the same fighter twice in a row.
So I looked at the two unfinished bets on the desk and picked one. The pipeline went one way. The game went on the shelf with a date on it. The pipeline became the case study. A system that spits out the same fighter through idle, punch, hurt, and KO (same hairline, same belt buckle, same stupid grin) turns out to be more interesting than the game it was supposed to feed. The game is going to inherit a tested production system. It is not going to inherit a half-built one I duct-taped to itself at 11pm.
What got cut when the pause landed: a v1 gameplay loop that wasn’t carrying its own weight without the polish layer, a Phaser atlas-streaming experiment I’d talked myself into mid-scope-creep, and an evening I would have spent angrily exporting frames I knew weren’t right yet. What’s below is the pipeline’s progress through May, the pause decision, and the gameplay-loop work that got marked KILLED with no hard feelings.
─ INVESTIGATION BOARD ─
Pause decision board
DECISION: pause game work; continue pipeline work. Return condition: animation pipeline ships first full short. Rationale: the game can't inherit a production system that isn't tested yet.
Killed: v1 gameplay loop
KILLED: v1 gameplay loop. The fight loop wasn't carrying its own weight without the polish layer. Decision: rebuild the loop after the pipeline ships and sprites stop drifting between cycles.
Killed: Phaser atlas-streaming experiment
KILLED: atlas-streaming experiment for large sprite atlases at 60fps on mid-range mobile. Deferred until the sprite pipeline produces stable cycles worth optimizing.
Avatar generation pipeline: Smooth-to-Pixel architecture
AI generates cel-shaded vector art; server-side CLAHE + Bayer dithering enforces the DMG 4-color palette. Separation of generation and palette enforcement.
Direct pixel-art generation was unreliable across cycles: palette drift, identity drift between idle and punch. Separating generation (Lightning-style cel-shaded source) from palette enforcement (deterministic post-processing) makes the pipeline trustworthy enough to feed a roster.
Design lock: 6 cosmetic champions + no-defeat philosophy
Design locked. 6 champions, cosmetic only, no stat-bearing advantage (the Mario Party model). Battle outcomes are victory or continue_training. There is no defeat state, by design.
─ METHODS ─
| TASK | AGENT / TOOL | MODEL / COST |
|---|---|---|
| game engine | Phaser 3 (WebView bridge) | open-source / $0 |
| mobile shell | React Native + Expo + TypeScript | open-source / $0 |
| backend | Supabase Cloud (PostgreSQL + Edge Functions + Storage) | SaaS |
| sprite generation | Gemini Nano Banana 2 via pixel-art Gemini skill | ~$0.034/image (1K) |
| animation pipeline (sibling) | Animation Pipeline | see case study |
─ 4Q ─
A-5.Q1 What is this?
A 16-bit fitness battle game with AI-generated sprites. The fight loop is the build target. The sprite pipeline behind it is the artifact, and right now the artifact is further along than the game.
A-5.Q2 Why this approach?
The volume target (a few hundred frames across a roster of fighters and idle cycles) was incompatible with hand pixel-art on a one-person budget. Three pipeline approaches got considered: full-hand pixel-art (cut on volume), full-generative without cleanup (cut on consistency across cycles), and AI-generated with a manual cleanup pass (kept). The third one is the production system the animation pipeline case study is also using; the game was supposed to be the second project that inherited it.
A-5.Q3 What would break?
Three named failure modes. One, sprite identity drift between animation cycles: the fighter's silhouette wandering by a pixel or two between idle and punch, which reads as flicker. Two, Phaser performance under large sprite atlases at 60fps on mid-range mobile. Three, the gameplay loop not carrying its own weight without the visual polish layer: the fight mechanics being interesting enough to play before the sprites get pretty.
A-5.Q4 What did I learn?
Pausing was right. The return condition is the animation pipeline shipping its first full short; until then, the game can't inherit a tested production system, and any sprite work I do now is a duplicate run of work happening one repo over. Sequencing the bets (pipeline first, then the game that consumes it) was a PM call I almost didn't make on a project where I'm the only stakeholder.