BOSTON, JUNE 23, 2026 — 16bitfit, paused

16BitFit

A fitness fighting game where real workouts power your fighter. On pause to build its engine first.

What is this?

16BitFit is a fitness fighting game: real-world training powers a Game Boy-style champion through Street Fighter-style battles. I built the app shell around it, the onboarding, the avatar generation, the pixel-art component system, before I hit the wall that mattered: the fight loop needs a sprite that stays the same fighter across hundreds of frames of idle, punch, and hurt, and I had no pipeline that could produce that reliably. So I paused the game and pulled that pipeline out into its own project, Anima, the animation-pipeline case study on this same site. 16BitFit inherits it once Anima ships its first full short.

Why this approach?

The volume was the problem. A fighting roster needs hundreds of consistent frames, and hand-drawing pixel art at that volume on a one-person budget wasn't realistic. I looked at three ways through: draw it all by hand (too slow), generate it all and ship whatever came out (too inconsistent across a cycle), or generate it and clean each frame to a fixed look (the only one worth testing seriously). The game wasn't blocked by motivation, it was blocked by an asset factory I hadn't built yet. So I pulled that factory out into its own project rather than half-build it inside the game.

What would break?

Three things have to hold before I restart the game. Sprite identity drift: if the fighter's silhouette wanders even a pixel or two between idle and punch, it reads as flicker, which is the exact problem the pipeline exists to solve. Runtime performance: the battles have to hold 60 frames a second on a mid-range phone, and big sprite sheets are where that falls apart, so if it can't, the art direction changes before I build more game on top of it. And the fight itself: the loop has to be fun before the art is pretty, or I've polished a game nobody wants to play. The pause is what keeps me from finding all three out the expensive way.

What did I learn?

Every instinct said keep shipping sprites, but I'd have been building them twice, once badly here and once properly in the pipeline one repo over. The real lesson was about AI specifically: the generation step wasn't a game feature, it was the capability the whole thing depended on, so the right move was to build and prove it on its own before wiring a game to it. Pausing something I was excited about was the hard part, and harder because I'm the only stakeholder, so there was no one but me to say stop.

A hand-drawn pencil-test diagram on cream paper. On the left, a Game Boy-style handheld labeled 16BITFIT showing a pixel fighter, resting on a shelf with an amber pause icon and labels PAUSED, ON THE SHELF, PIPELINE 47%. Above it, a brick wall labeled NEEDS HUNDREDS OF CONSISTENT SPRITE FRAMES. A solid arrow leads right to a conveyor-belt pipeline labeled ANIMA, THE PIPELINE BUILT + PROVEN FIRST, producing a row of identical pixel-fighter frames. A dotted amber arrow curves back from ANIMA to the shelved game, labeled GAME INHERITS THE PIPELINE WHEN ANIMA SHIPS, 2026-08. — Paused the game on a sprite-volume wall; building its pipeline first as Anima, to inherit later.

─ METHODS ─

Tools, agents, and models used on this project
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