ゲームアーキテクチャパターン

構造の整ったブラウザゲームを構築するためのリファレンス知識。これらのパターンはThree.js（3D）とPhaser（2D）の両方のゲームに適用されます。

リファレンスファイル

詳細なリファレンスについては、このディレクトリ内の関連ファイルを参照してください：

• system-patterns.md — オブジェクトプーリング、デルタタイム正規化、リソース破棄、ウェーブ/スポーンシステム、バフ/パワーアップシステム、触覚フィードバック、アセット管理

コア原則

1. コアループを最初に: ポーランディングの前に、最小限のゲームプレイループを実装します。順序は：入力 -> 移動 -> 失敗条件 -> スコアリング -> 再開。コアループが機能した後でのみ、ビジュアル、オーディオ、またはゲーム的な演出を追加してください。初期スコープは小さく保つ：1シーン/レベル、1メカニクス、1失敗条件。

2. イベント駆動通信: モジュール同士が直接通信するために互いをインポートしません。すべてのモジュール間メッセージングは、事前定義されたイベント定数を持つシングルトン EventBus を通じて行われます。

3. 集中管理された状態: 単一の GameState シングルトンがすべてのゲーム状態を保持します。システムは状態を直接読み取り、イベントを通じてそれを修正します。モジュール全体に散在した状態はありません。

4. 設定の集中化: すべての魔法の数値、バランス値、アセットパス、スポーン地点、タイミング値は Constants.js に配置します。ゲームロジックファイルにはハードコードされた値は含まれません。

5. オーケストレーターパターン: 1つの Game.js クラスがすべてのシステムを初期化し、ゲームフロー（ブート -> ゲームプレイ -> 死亡/勝利 -> 再開）を管理し、メインループを実行します。システムは自己初期化されません。デフォルトではタイトルスクリーンはありません — ゲームプレイに直接ブートします。ユーザーが明示的に要求した場合のみ、タイトル/メニューシーンを追加してください。

6. 再開セーフで決定論的: ゲームプレイは完全な再開サイクルをクリーンに乗り越える必要があります。GameState.reset() は完全にクリーンなスレートを復元します。すべてのイベントリスナーはクリーンアップ/シャットダウンで削除されます。再開後に残る古い参照、ぶら下がったタイマー、漏れたトゥイーン、孤立した物理体はありません。3回連続で再開してテストします — 3回目の実行は1回目と同じように動作する必要があります。

7. 懸念の明確な分離: コードは機能レイヤーに編成されます：

   • core/ - 基盤（Game、EventBus、GameState、Constants）
   • systems/ - エンジンレベルのシステム（入力、物理、オーディオ、パーティクル）
   • gameplay/ - ゲームメカニクス（プレイヤー、敵、武器、スコアリング）
   • level/ - ワールドビルディング（レベル構築、アセット読み込み）
   • ui/ - インターフェース（メニュー、HUD、オーバーレイ）

イベントシステム設計

イベント命名規約

フィーチャーエリアごとにグループ化された domain:action フォーマットを使用します：

export const Events = {
  // Player
  PLAYER_DAMAGED: 'player:damaged',
  PLAYER_HEALED: 'player:healed',
  PLAYER_DIED: 'player:died',

  // Enemy
  ENEMY_SPAWNED: 'enemy:spawned',
  ENEMY_KILLED: 'enemy:killed',

  // Game flow
  GAME_STARTED: 'game:started',
  GAME_PAUSED: 'game:paused',
  GAME_OVER: 'game:over',

  // System
  ASSETS_LOADED: 'assets:loaded',
  LOADING_PROGRESS: 'loading:progress'
};

イベントデータコントラクト

常に構造化されたデータオブジェクトを渡し、プリミティブを渡しません：

// 良い例
eventBus.emit(Events.PLAYER_DAMAGED, { amount: 10, source: 'enemy', damageType: 'melee' });

// 悪い例
eventBus.emit(Events.PLAYER_DAMAGED, 10);

状態管理

GameState 構造

状態を明確なドメインに編成します：

class GameState {
  constructor() {
    this.player = { health, maxHealth, speed, inventory, buffs };
    this.combat = { killCount, waveNumber, score };
    this.game = { started, paused, isPlaying };
  }
}

ゲームフロー

2Dおよび3D両方のゲームの標準フロー：

ブート/ロード -> ゲームプレイ <-> ポーズメニュー（リクエストされた場合）
                      -> ゲームオーバー -> ゲームプレイ（再開）

デフォルトではタイトルスクリーンはありません。 ゲームはゲームプレイに直接ブートします。Play.fun ウィジェットはゲームの上部のデッドゾーンで、スコア表示、リーダーボード、ウォレット接続を処理するため、ゲーム内スコア HUD は不要です。ユーザーが明示的に要求した場合のみ、タイトル/メニューシーンを追加してください。

一般的なアーキテクチャの落とし穴

• 配線されていない物理ボディ — 静的な物理ボディ（例：グラウンド、壁）を作成する際に、physics.add.collider() または physics.add.overlap() 経由で他のボディに配線しないことは、ゲームプレイに効果がありません。すべての境界または障害物は、相互作用する必要があるエンティティへの明示的な衝突配線が必要です。静的ボディを作成した後、すぐにコライダー呼び出しを追加します。

• オーバーラップ表示オブジェクトでブロックされたインタラクティブ要素 — UI（ボタン、メニュー）を構築する場合、シーンリストの最上位の表示オブジェクトがポインターイベントを受け取ります。インタラクティブ要素を装飾レイヤーの後ろに隠さないでください。ビジュアル要素自体をインタラクティブにするか、ヒット領域の上に何もレンダリングされないようにします。

• ゲームプレイの前にポーランディング — コアループが機能する前にパーティクル、スクリーンシェイク、トランジションを追加することは、一般的な時間の浪費です。入力 -> アクション -> 失敗条件 -> スコアリング -> 再開を最初に機能させます。その他すべてはポーランディングです。

• 再開時のクリーンアップなし — shutdown() でイベントリスナーの削除、タイマーの破棄、リソースの処理を忘れると、再開後にゴーストビヘイビア、ダブルファイアリングイベント、メモリリークが発生します。

出荷前検証チェックリスト

ゲームが完成したと見なされる前に、すべての項目を確認してください：

• コアループ — プレイヤーは開始、プレイ、失敗/勝利できて、結果を見ることができる
• 再開 — 3回連続で同じ動作でクリーンに機能する
• モバイル入力 — タッチ/タップ/スワイプ/ジャイロが機能。最小44pxタップターゲット
• デスクトップ入力 — キーボード＋マウスが機能する
• レスポンシブ — ウィンドウリサイズ時にキャンバスが正しくリサイズされる
• 定数 — ゲームロジックでハードコードされた魔法の数値がない
• EventBus — 通信のための直接的なモジュール間インポートがない
• クリーンアップ — すべてのリスナーがシャットダウンで削除され、リソースが処理される
• ミュート切り替え — mute-button ルールを参照
• デルタベース — すべての移動がフレームカウントではなくデルタタイムを使用する
• ビルド — npm run build がエラーなく成功する
• エラーなし — 実行時にキャッチされない例外またはコンソールエラーがない