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. It features a CSV/Excel master-data auto-generation pipeline, multi-enemy combat, Shop/Event/Reward economy systems, RunSave (progress saving and resuming), and Status/Buff effect mechanics. The current UI uses development placeholder assets, with polished visuals planned for a future pass.

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: CSV/Excel master-data auto-generation via TFramework generator, with full migration from ScriptableObject mocks
• 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 running concurrently. The FSM had to remain consistent with UniTask-based async lifecycles to prevent the battle loop from racing ahead of effects or cards being played mid-transition.
• Ordering across multiple systems: Energy, hand limits, enemy intents, and passive-effect interrupts all react to card play in chains. Ensuring predictable execution order and notification timing across these independent systems was a central challenge.
• Balancing scope and quality in solo development: As a solo developer handling game design, architecture, and implementation in parallel, the constant tension between overengineering (slowing progress) and tactical shortcuts (accumulating tech debt) required ongoing judgment.

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.
• CSV/Excel master-data auto-generation: All parameters for cards, enemies, maps, shops, events, and reward tables are managed in CSV/Excel and auto-generated into C# code via the TFramework generator. Fully migrated from early ScriptableObject mocks to enable code-free balance tuning.
• View/Presenter separation and service decomposition: Completed UI responsibility split aligned with TFramework’s Page/Dialog flow. Further decomposed BattleSceneFlowService into BattleRewardService, BattleShopService, BattleEventService, BattleSnapshotFactory, and BattleDisplayTextService following the single-responsibility principle.
• Multi-enemy combat and advanced AI: Extended from single-enemy to multi-enemy formations with per-enemy HP/Block/Intent/Status/Buff management. Implemented five enemy behavior patterns: OpeningOnly, RepeatAfterOpening, AfterOpeningRandom, Random, and Cycle.

Results

Key features implemented to date:

• Strict FSM-driven turn-based battle flow across 9 states (BattleStart → TurnStart → PlayerAction → CardResolve → EnemyIntent → EnemyAction → TurnEnd → Victory/Defeat)
• CSV/Excel master-data auto-generation pipeline via TFramework generator (covering cards, enemies, maps, shops, events, and reward tables)
• Multi-enemy combat with per-enemy HP/Block/Intent/Status/Buff tracking and TargetSide.AllEnemies support
• Five enemy AI behavior patterns: OpeningOnly, RepeatAfterOpening, AfterOpeningRandom, Random, and Cycle
• View/Presenter separation with service decomposition (BattleRewardService, BattleShopService, BattleEventService, BattleSnapshotFactory, BattleDisplayTextService)
• RunSave for progress saving and resuming (auto-save at Map/RestShop, Save & Quit flow)
• Shop system (card purchase, removal, sold-out display, MasterData-driven pricing)
• Event system (branching choices, randomized event selection, localization support)
• Reward system supporting multiple reward types (Card, Gold, Potion, Relic) with dynamic generation
• Status effects (Weak, Vulnerable, Slimed) and Buff effects (Strength, Ritual, Enrage)
• Combat draw and discard piles with in-battle visualization
• Addressables-based asynchronous loading for all scenes and prefabs

In development: Relic (artifact) passive effect system. Remaining: complete UI redesign (currently grayscale development mockups), animation and presentation throughout, OutGame scenes (TitleScene / MainScene), auto-generated map nodes, rest sites (HP recovery and card upgrades).

*Image shown is illustrative.