コンテンツにスキップ

第11部: ケーススタディ

ここまでの知識を「実際のゲーム機能の設計判断」として使う章です。各ケースは共通の型で進みます:

  1. 素朴な実装(まず動くもの)
  2. 機能追加で破綻する過程(何が要求されると崩れるか)
  3. 複数の設計案(継承案/コンポジション案/パターン適用案/パターンを使わない簡潔案)
  4. 利点と欠点の比較
  5. 規模別の判断(小=ジャム・プロト/中=数人・数ヶ月/大=チーム・長期運用)

「正解」は規模と要求で変わります。どの案も選べる状態になることがこの章のゴールです。

ケース一覧

ケース 主に効いてくる知識
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)になりがち

全体目次 | 次: プレイヤー入力