Inspiration
Our bloodline is cursed: every hero in HITSUGI dies in exactly 2 in-game years. We wanted to reinterpret the Japanese cult-classic dark-fantasy RPG Oreshika (Ore no Shikabane wo Koete Yuke) with fully original systems and modern UX — and to see how far a two-person team could push content volume and system depth in a short build window by treating AI coding agents as real teammates rather than autocomplete.
What it does
HITSUGI is a generation-succession dark-fantasy RPG, free to play in the browser. Marry star-gods to conceive children who inherit stats, skills, and keepsakes. Lead your family into procedurally generated night dungeons where a depleting "lantern gauge" forces push-your-luck decisions between one more room of treasure and a safe retreat. When a hero falls, they leave behind an auto-generated death poem (辞世), and their legacy — equipment, memories, unfinished rivalries — passes to the next generation via a family-tree UI spanning your whole 1000-year chronicle.
Current content scale: 180 gods, 540+ base enemies (with elite/aged variants), 810 equipment, 270 story events, 1,370 unique death poems, and 40 hand-tuned regions across 171 dungeon floors — all machine-verified for zero duplicate IDs/text.
How we built it
- Stack: React 19 + TypeScript + Vite, PixiJS 8 for the dungeon renderer (5-layer scene + dynamic lighting), Zustand for state, procedural Web Audio for all BGM/SE (no audio files shipped).
- Multi-agent build process: we ran OpenAI Codex CLI and Claude Code side-by-side on the same repo as independent contractors, not a single copilot. Each major feature (e.g. the 40 region-specific dungeon overhaul, rare-encounter system) was scoped as a "mission": a written contract (definition of done, out-of-scope, protected files), a task breakdown, an implementation pass, and an independent audit before it counted as complete. A single design doc (GDD) and decision log (WORKLOG) — not chat history — is the source of truth both agents read from, so work stayed coherent across agents and sessions.
- Content pipeline: bulk content (equipment lineages, death poems, events) is generated from small authored formulas + expansion tables, then validated by script for zero collisions before it ships. Dungeon floors are procedurally generated (Prim's MST + superellipse room shaping + cellular-automata smoothing) with automatic deterministic reseeding if a floor fails reachability/openness checks.
- Art: a local ComfyUI (SDXL-anime checkpoint) image factory fills in portraits/sprites/icons as data grows, with a graceful fallback (silhouette/emoji) for anything not yet generated — so the game is always fully playable even mid-pipeline.
Challenges we ran into
- Two AI agents, one repo: Codex and Claude working the same codebase in parallel risked silent overwrites. We solved it with explicit mission contracts (protected file lists, scope boundaries) and required an independent audit pass before any parallel work was considered mergeable.
- 1.5x content scale-up with zero duplication: hand-authoring 1,370 death poems or 810 equipment names risks collisions; we moved to deterministic generation formulas (trait × cause-of-death, lineage × tier) validated by script, not human proofreading.
- Procedural dungeons that don't feel procedural: getting open-area ratio, connectivity, and hand-crafted-feeling landmark placement (bonfires, shrines, monuments) right took a validate → reseed → re-validate loop (stress-tested over 300 seeds, 0 unrecoverable failures).
Built With
- claude-code
- comfyui
- github-actions
- openai-codex
- pixijs
- react
- sdxl
- typescript
- vite
- web-audio-api
- zustand
Log in or sign up for Devpost to join the conversation.