Vox Dungeon

Overview

A smartphone-oriented roguelike deckbuilder designed for portrait, one-handed play. I designed and implemented the core loop personally, taking inspiration from the strategic card-flow of games like Slay the Spire while optimizing for shorter play sessions. The project integrates my own foundation, TFramework, on Unity 6.

Responsibilities

I am responsible for the full development flow.

• Game design, including rules for cards, relics, maps, and economy
• Architecture design built on TFramework’s FSM modules and R3-based event handling
• Client implementation for battle systems, UI, scene transitions, and object pooling
• Data pipeline design with ScriptableObject for cards, enemies, and map data
• A development workflow that uses Codex for design review, implementation speed, and debugging support

Challenges

• FSM and async coordination: Turn-based battles combine animation, effect resolution, and state transitions. The FSM had to remain consistent with UniTask-based async lifecycles so the battle loop could not race ahead of effects.
• Ordering across multiple systems: Energy, hand limits, enemy intents, and passive-effect interrupts all react to card play. Their order and notification timing had to stay predictable.
• Balancing scope and quality in solo development: I needed to avoid both overengineering and fast-but-fragile implementation while pushing toward a playable loop quickly.

Solutions

• Practical validation of TFramework: I integrated TFramework directly into the project and used it to run battle flow, scene transitions, page-stack UI management, and Addressables-based loading.
• Strict FSM state design: BattleStart → TurnStart → PlayerAction → CardResolve → EnemyIntent → EnemyAction → TurnEnd → Victory/Defeat are modeled as explicit states, with async start and completion handling inside Enter/Exit.
• Event-driven architecture with R3: Card play, damage, healing, energy updates, and enemy actions are all exposed as observables so UI, animation, and transition logic can react independently.
• ScriptableObject-based data design: Cards, enemies, maps, and relics are separated into data assets so balancing can proceed without frequent code edits.

Results

The M1 phase for the core battle loop is complete. Scene transitions from TitleScene to MainScene to BattleScene, a five-node-plus-boss map flow, and a playable loop with 20 cards and 6 relics are already running in Play Mode. The project is currently moving toward clearer View/Presenter separation and automated master-data generation from CSV and Excel sources.

*Image shown is illustrative.