JAMIE
A persistent AI development partner built on agent harnessing and context engineering.
[ read case study ][ Case Study ]
Party Wipe
A single-player D&D combat roguelike — the tabletop's hardest half, distilled to a 20-minute run with no DM.
In development · Engine and UI complete
- Next.js
- Tailwind CSS
- TypeScript
- Three.js
[ The Problem ]
D&D has a gatekeeping problem. A committed group, a willing DM, four-plus-hour sessions, paper bookkeeping, a rules tome longer than most novels. Two audiences bounce off it: gamers who'd be receptive to tabletop but won't commit, and non-gamers who'd try a shortplay if the rules barrier disappeared.
Most of that friction lives in combat. Story tracking is solvable — campaign wiki, DM-managed objective tree, prepared encounters. Combat is the harder problem: conditions, action economy, dice math, resource bookkeeping, damage-type interactions. New players bounce off the rules density before they ever feel the strategic loop underneath.
I wanted to find out what "consumable D&D combat" could look like, with no good way to learn it from the table. So I built Party Wipe — a single-player roguelike that runs the combat layer end-to-end without a DM, on a heavily curated SRD subset. Longer-term, this becomes the combat engine inside a DM/player dashboard that lowers the barrier for casual table play.
[ Architecture ]
The game is five things working together.
Phase-driven UX, no menus
Every game phase is a full-screen takeover with a persistent floating HUD. Phases:
room-preview,combat,loot,rest,level-up,game-over. No inventory menu, no character-sheet dialog opened mid-combat. The current phase is the screen. Removes the rules-research detour that loses new players at tabletop.Zone-based combat
Three abstract zones — front, mid, back. Distance determines melee (same zone), ranged (adjacent), or far (skip one). No grid tiles, no positioning within a zone. The tactical layer is which zone you're in, not which five-foot square. It gives up exact positioning, but turns take seconds and the battlefield reads in one glance.
Curated content as MVP discipline
The official D&D 5e rules ship 304 monsters, 9 classes with 30-plus subclasses, 400-plus spells. Party Wipe runs on 18 monsters, 6 classes, 23 spells, 14 weapons, 6 consumables. Every survivor earns its slot by teaching a distinct tactic — a skeleton punishes the wrong weapon; a mummy that hits hard but burns easy rewards the player who brings fire. The trim is a prototype constraint; breadth comes back when the engine's earned it.
Cycling bosses that scale with depth
Three boss templates — chimera, young black dragon, stone giant — cycle by floor, scaling up as you descend. A Floor 3 chimera and a Floor 23 chimera are the same fight beat-for-beat, just bigger. Endless runs stay sustainable on three boss designs.
Visual feedback that teaches
Every combat event renders as a full-card overlay on the affected token — a themed flourish (fire embers, ice shards, lightning forks, one of ten families) plus the damage number and a small ribbon marking a crit, a vulnerability, or a resist. A new player reads "fire damage on a vulnerable enemy, critical hit" without ever opening a rules reference — the whole thing is in what they see, not what they'd have to look up.
Party Wipe is built on Loom, the same design-system pipeline behind Paperboy — one questionnaire in, two visually distinct products out.
[ Decisions ]
Combat first, story later. Most D&D digital adaptations render the whole experience: narrative, exploration, character relationships, combat. Party Wipe deliberately doesn't. Story tracking is the solved-ish half (wikis, objective trees, prepared encounters); combat is where the friction lives. Building only the combat half means the engine gets sharpened on the actual hard problem before it has to plug into a larger system.
Zone abstraction over grid. Most digital D&D either keeps the grid (BG3, Solasta) or abstracts to a text-only combat log (most computer RPGs). Three zones is the middle ground that keeps positioning a real tactical choice without making turns expensive. Newcomers read the battlefield instantly.
One source of truth per visual concern. Damage, condition, intent, and class colors each live as a TS registry reading from CSS custom properties in game-tokens.css. No component owns its own color map. Adding a new damage family is one file. Theming a new screen is reading existing tokens. The architecture survives expansion when the trimmed content grows back to full breadth.
[ By the numbers ]
~20mRun lengthconsumable session
18Monstersstrategy loops
10Feedback familiesthemed flourishes
0Menusphase is the screen
[ Under the Hood ]
The roster is the load-bearing artifact — every monster annotated with the strategy loop that earns it a slot.
> src/data/v1-roster.ts
/**
* V1 Roster — Curated game content
*
* Every entry here is distinct, functional, and intentional.
* Generators and UI filter against these lists.
* Nothing outside the roster appears in gameplay.
*
* Philosophy: FF GBA / BG1 / Fallout 1 — small scope, everything works.
*/
// ─── Monsters (18 curated from 304) ────────────────────────────
export const V1_MONSTERS = new Set([
// ─ Floor 1 — CR 0.125–0.25 ─
'giant-rat', // 0.125 — mob: vanilla cleanup fodder
'goblin', // 0.25 — mob: vanilla flexible attacker
'skeleton', // 0.25 — bludgeoning-vulnerable + poison-immune (damage-type teacher)
'wolf', // 0.25 — Bite inflicts prone (STR save)
// ─ Floor 2 — CR 0.5–1 ─
'shadow', // 0.5 — resists nonmagical physical, vulnerable to radiant
'ghoul', // 1 — Claws inflict paralyzed (CON save)
'giant-spider', // 1 — Bite inflicts poisoned (CON save); the poison creature
// ... 11 more, each carrying one strategy loop the engine actually wires
]);[ More Case Studies ]
Loom
A design-system pipeline that scaffolds application UI from a single config source.
[ read case study ]Availo
A digital bulletin board for spontaneous event planning — events are posters, your people and calendars are the boards.
[ read case study ]