Vox Dungeon

Overview

スマートフォン向けの縦持ち・片手操作が可能なローグライク・デッキ構築型ゲーム。Slay the Spireに代表されるカード選択型の戦略性と、短時間で遊べるゲームサイクルを個人で設計し実装。Unity 6上で自作ゲーム基盤TFrameworkを統合し、FSMモジュールによるバトル進行、シーン遷移、UI管理をTFramework上に構築。VContainer / R3 / UniTaskを活用し拡張性のあるコードベースとなっている。

Role & Responsibilities

ゲームデザインから実装まで全工程を1名で担当。 - ゲームデザイン（GDD作成、カード・遺物・マップ・経済のルール策定） - アーキテクチャ設計（TFrameworkのFSMモジュールを活用したターン制バトルの状態管理、R3によるイベント駆動設計） - クライアント実装（バトルシステム、UI、シーン遷移、オブジェクトプール） - データ駆動基盤（ScriptableObjectを用いたカード・敵・マップのマスターデータ管理） - Codexを活用した開発フロー（仕様検討・設計の壁打ち、実装の高速化、デバッグの効率化）

Challenges

• FSMと非同期処理の整合: アニメーション、エフェクト解決、状態遷移が同時に走るターン制バトルにおいて、FSMの状態とUniTaskの非同期ライフサイクルを破綻なく整合させる必要があった。状態遷移中に次のカードがプレイされる、アニメーション完了前にFSMが先走るといった競合を防ぐため、FSMの遷移条件に非同期処理の完了を組み込む設計が求められた
• 複数システムの相互干渉の整理: エネルギー管理、手札制限、敵AIの意図表示、パッシブ効果の割り込みといった独立したシステム群が、カード1枚のプレイを起点に連鎖的に反応する。各システムの実行順序と通知タイミングを整理し、予測可能な解決順を保証する必要があった
• 個人開発におけるスコープと品質の両立: 1名体制でゲームデザイン・アーキテクチャ設計・実装を並行して進めるため、過剰設計によるスピード低下と、場当たり的な実装による技術的負債の蓄積という相反するリスクのバランスを常に意識する必要があった。M1では「まず動く閉ループを最速で作り、設計の課題は次のフェーズで整理する」方針を採用し、短期間で基本バトルループを完遂

Solutions & Architecture

• TFrameworkの実戦投入と検証: 個人開発のゲーム基盤として設計したTFrameworkを実際のゲームプロジェクトに統合。FSMモジュールによるバトル進行、シーン遷移、UIのPageスタック管理、AddressablesによるアセットロードをTFramework上で運用し、基盤の実用性と改善点を検証しながら開発を進行
• FSMによる厳格な状態管理: BattleStart → TurnStart → PlayerAction → CardResolve → EnemyIntent → EnemyAction → TurnEnd → Victory/Defeat の9状態をStateMachineで定義。各状態のEnter/Exitで非同期処理の開始と完了待機を行い、状態遷移の一貫性を保証。プレイヤー操作の受付可否もFSMの現在状態に応じて制御
• R3によるイベント駆動設計: カードプレイ、ダメージ、回復、エネルギー変化、敵の行動など、バトル中の全状態変化をObservableとして公開。UI表示やアニメーション再生、FSM遷移判定がそれぞれ独立して購読する疎結合なデータフローを構築
• ScriptableObjectによるデータ駆動: カード、敵、マップ構成、遺物の全パラメータをScriptableObjectとして分離し、コード変更なしでバランス調整が可能。モックデータを用いた即時プレイアブル化により、実装と並行してゲームデザインの検証が可能な基盤を確立

Results

M1フェーズ（基本バトルループ）を完了し、TitleScene → MainScene → BattleSceneのシーン遷移、5ノード+ボスのマップ進行、20種のカードと6種の遺物を含むゲームループがPlay Modeで動作済み。最終的にコンソールのエラー・警告ゼロの状態で验收を通過。現在はUI責務のView/Presenter分割と、ScriptableObjectからCSV/Excelを用いたマスターデータ自動生成への移行を進行中。

※画像はイメージです