Spare Knight: 13 days, no dice
Spare Knight was my first shipped game: a tactical roguelike built in 13 days for Gamedev.js Jam 2026, theme Machines. I directed it, wrote all the code (Phaser 3 + Vite), and hand-painted every tile, character, and UI element in Krita on a Wacom tablet. Nicholas Drabb joined as collaborator on game design consultation, sound, voice work, and the lore we co-wrote. It shipped open source, live on the jam page and on Wavedash.
The premise carries the theme: the machines have reached a philosophical consensus that organic life is inefficient. They call it the Absolution Mindset. You are a knight whose firmware is three generations out of date, too old to receive the update, with one human left to protect.
The core bet: no attack RNG
The first design decision was the one everything else hangs on: attacks never miss. No hit chance, no damage range. Combat happens on a 6x6 isometric grid with speed-based initiative, and every choice is committed the moment you make it.
The reasoning: runs are 15 to 20 minutes. In a run that short, a 75%-to-hit roll that misses twice in a row doesn’t read as variance, it reads as theft. XCOM can afford that feeling across a 30-hour campaign; a jam roguelike cannot. So the dice came out, and the tension had to come from somewhere else.
It moved into execution. Offense and defense run through souls-like timing reactions: multi-wheel strikes and defensive braces where you read an audio chime and commit on the beat. The math of an exchange is fully deterministic; whether you flubbed the timing is on you. Randomness still exists in the game, but it lives in the campaign layer (a Slay-the-Spire-style node map across two acts: cornfield, cathedral, silo, the Herald, then the Prelate), where variance creates replayability instead of resentment.
The companion decision: defeat is a moment, not a punishment. Short runs, instant restart, and a tone that treats falling as part of the fiction of being obsolete. Players retry an unfair-feeling game out of spite and a fair-feeling one out of curiosity. Only one of those survives a jam rating page.
Painting the whole world
The look I wanted was “Bright Ruins”: warm, sunlit, weighty, somewhere between Don’t Starve’s linework and a Ghibli afternoon. Hand-painting an entire isometric set as one person on a deadline taught me the real unit cost of art scope. Two things kept it survivable: the battle takes place on a single screen, so the tile vocabulary stayed small, and painting in Krita with a consistent brush kit meant each new asset inherited the style for free instead of needing a style decision.
The unexpected benefit: directing art and code in the same head removes a whole category of iteration. When a tile read poorly in-engine, the painter already knew exactly which layer to fix.
Working with a collaborator while building
Nicholas owned sound, voice, and half the narrative, and consulted on design. The handoff discipline that worked: I kept a single source-of-truth design doc, and his deliverables plugged into systems that already had placeholder hooks (audio events, dialogue beats). What I’d improve: I gave him lore context in bursts instead of up front, which cost us a rewrite on the late-game text.
Lessons that carried forward
Lock the mechanical core in week one. The timing wheels were the riskiest element, and they were prototyped and felt right before any content was built around them; if they had failed, the game would have become something else early instead of late. Scope the art to the camera, not to ambition. And ship to more than one storefront, because the jam page and Wavedash brought different players and different feedback.
Two months later I applied all three of those lessons in a 63-hour Godot jam. That one is covered in its own postmortem.