第11部: ケーススタディ¶
ここまでの知識を「実際のゲーム機能の設計判断」として使う章です。各ケースは共通の型で進みます:
- 素朴な実装(まず動くもの)
- 機能追加で破綻する過程(何が要求されると崩れるか)
- 複数の設計案(継承案/コンポジション案/パターン適用案/パターンを使わない簡潔案)
- 利点と欠点の比較
- 規模別の判断(小=ジャム・プロト/中=数人・数ヶ月/大=チーム・長期運用)
「正解」は規模と要求で変わります。どの案も選べる状態になることがこの章のゴールです。
ケース一覧¶
| ケース | 主に効いてくる知識 |
|---|---|
| 01. プレイヤー入力 | Command、入力抽象化、DIP |
| 02. 武器切り替え | Strategy、継承vsコンポジション |
| 03. 敵AI | FSM、BT、Type Object |
| 04. ステート異常 | Decorator、効果リスト、State |
| 05. 実績システム | Observer、Pub/Sub、データ駆動 |
| 06. セーブデータ | Memento、SRP、バージョン互換 |
| 07. ダメージ計算 | パイプライン、Chain of Responsibility、純粋関数 |
| 08. UI通知 | Observer、MVP、Event Queue |
| 09. オブジェクト生成 | Factory、Prototype、Object Pool |
| 10. 画面遷移 | State/Stack、Facade |
| 11. サウンド管理 | Facade、Adapter、Event Queue |
| 12. アイテム効果 | Type Object、Command、データ駆動 |
| 13. クエスト | Composite、Observer、Interpreter |
| 14. イベント通知 | Observer vs Queue vs Bus 総合判断 |
| 15. 照準制御 | Strategy、補正パイプライン、Update順序 |
仕上げに 演習。
読み方のコツ¶
- 自分のプロジェクトに近い規模の判断を最初に読む(全部の案を実装する必要はない)
- 「破綻する過程」が自分の経験と一致するかを確かめながら読む——破綻を経験する前に設計を上げるのは早すぎる抽象化(YAGNI)になりがち