【要約】MVC / MVP でゲームを作るとぶつかる壁 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
ゲーム開発者が、MVC/MVPを用いて設計を行う際、演出による時間差の制御に直面する。従来の設計では、Modelの更新とViewの描画が即時同期されることを前提としている。しかし、ゲームでは演出を挟む必要があるため、以下の問題が生じる。
- ・Modelのデータ更新と、Viewの演出完了タイミングが一致しない。
- ・演出中に「1撃ごとのHP減少」などの途中経過を表示したい場合、Viewが最終状態しか参照できない。
- ・演出の複雑さに応じて、単純なフラグ管理では状態を制御しきれなくなる。
// Approach
開発者は、演出の複雑さとロジックの分離度合いのトレードオフに基づき、3つの手法を検討する。それぞれの設計は、時間軸の制御方法が異なる。
1.案1（MVCの拡張）: Viewに演出中フラグを持たせ、演出終了後に描画を更新する。
2.案2（MVPの採用）: PresenterがUniTask等を用いて、演出の待機とModel更新を交互に制御する。
3.案3（イベント駆動型MVP）: BattleLogicが戦闘結果を
BattleEventのリストとして返し、Viewがそれを順次再生する。// Result
開発者は、対象となるシステムの性質に応じて最適なパターンを選択できる。設計手法の使い分けにより、開発効率と品質のバランスを最適化できる。
- ・メニューUIなどの単純な画面には、案1（MVC + フラグ）が適している。
- ・一般的なインゲーム実装には、案2（MVP）が開発効率と仕様変更への強さのバランスが良い。
- ・スロットゲーム等のシミュレーション重視の用途には、案3（イベント駆動）が極めて有効である。
Senior Engineer Insight
> ゲーム開発における「時間軸」の概念は、Web等の設計思想とは根本的に異なる。単なる状態同期ではなく、演出という「遅延」をどう設計に組み込むかが鍵となる。案3のようなイベント駆動は、リプレイ機能や自動テストの観点から極めて強力だが、Event定義の肥大化という保守コストを伴う。プロジェクトの性質（シミュレーション重視か、インタラクティブ性重視か）を見極めたアーキテクチャ選定が、長期的な開発速度を左右する。