Designing a complete game economy solo - and shipping it to Steam
Role: Everything. Game design, economy design, UI/UX, pixel art, Unity development, store page, marketing.
Type: Personal project, built solo alongside full-time work.
Status: Playable demo live on Steam (store page).
Context
Spirit of ARX is a roguelike dungeon crawler: pick one of three character classes, descend into procedurally generated catacombs, fight monsters, collect coins, upgrade, beat the boss. I built it while running ARX, a boutique gaming media outlet, because I loved the genre (Enter the Gungeon and its kin) and wanted my own take on it.
I designed and built every system myself, learning Unity on the fly. There was no team, no budget, and no AI tooling - every mechanic below exists because I documented it, designed it, and coded it.
The design challenge
Roguelikes live or die on one thing: dying has to feel like the beginning of the loop, not the end of it. The player must restart voluntarily, hundreds of times. That meant three interconnected systems had to work together: an onboarding that reframes death, a progression loop worth repeating, and an economy that keeps every run tense.
Key decisions
1. Death is the tutorial. Instead of a text tutorial, the first run is a scripted death: the player enters a deliberately unbeatable level, dies, and wakes up as a Spirit - which is the story premise of the entire game. The core mechanic the player will experience most often (dying and retrying) is the very first thing they learn, framed as narrative rather than punishment. The conventional tutorial level comes after, once the player already understands what the game is about.
2. Seeded runs instead of pure randomness. Inspired by seed-based games like Inscryption, I chose seeded procedural generation over fully random maps. Every run can be reproduced or shared from its seed, which enables replayability and speedrunning - two of the strongest retention drivers in the genre. It also had a second payoff: the entire save system collapsed into three values (level, stage, seed), because the whole world state can be reconstructed from them. My design doc for it is literally titled "Save file, but not really."
3. Loot always has a price. Coins drop from enemies and from breakable urns and barrels. But the highest-value barrels also spawn an enemy when broken. Every economic gain carries a risk decision, which keeps combat and economy connected instead of letting looting become a passive chore. Shops, dash abilities, and levels gated behind specific abilities complete the progression loop, with a separate endless mode for players who want pure score-chasing.
4. Systems documented before they were built. The full game loop, map generation logic, difficulty scaling, story arcs, and first-run flow were mapped in design boards before implementation - the same discipline I use in product work. Designing the system on paper first is what made it buildable by one person.
Outcome
The demo shipped on Steam with three classes, procedural stages, bosses and mini-bosses, a working economy, endless mode, and localization into multiple languages. Several YouTube creators reviewed it unsolicited - people I had never contacted or met - and players asked for the full release.
The full game never shipped. A second act was nearly complete, but the scope of finishing it solo, while self-teaching game development, outgrew the time I had. I paused development rather than ship something below the bar.
What it taught me
Designing a system and building it are different estimates, and a solo project makes that gap brutally visible. It permanently changed how I scope work: I now design economies, progression, and retention loops as one interconnected system, because I have felt firsthand what happens when one of them is off. This is the same thinking I apply to gamification, reward mechanics, and engagement loops in product work - except here, I also had to make it fun.