コンテンツにスキップ

第11部: ケーススタディ

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

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

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

ケース一覧

ケース 主に効いてくる知識
01. プレイヤー入力 Command入力抽象化DIP
02. 武器切り替え Strategy継承vsコンポジション
03. 敵AI FSMBTType Object
04. ステート異常 Decorator、効果リスト、State
05. 実績システム ObserverPub/Sub、データ駆動
06. セーブデータ MementoSRP、バージョン互換
07. ダメージ計算 パイプライン、Chain of Responsibility、純粋関数
08. UI通知 ObserverMVPEvent Queue
09. オブジェクト生成 FactoryPrototypeObject Pool
10. 画面遷移 State/StackFacade
11. サウンド管理 FacadeAdapterEvent Queue
12. アイテム効果 Type ObjectCommand、データ駆動
13. クエスト CompositeObserverInterpreter
14. イベント通知 Observer vs Queue vs Bus 総合判断
15. 照準制御 Strategy、補正パイプライン、Update順序

仕上げに 演習

読み方のコツ

  • 自分のプロジェクトに近い規模の判断を最初に読む(全部の案を実装する必要はない)
  • 「破綻する過程」が自分の経験と一致するかを確かめながら読む——破綻を経験する前に設計を上げるのは早すぎる抽象化(YAGNI)になりがち

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