Event設計とは？状態とシーンを“ゆるく”つなぐ仕組み

これまでに、

• #13 Input設計 → 入力の整理
• #14 Scene管理進化 → シーンの切り替え
• #10 状態管理統合 → update / render の分離

まで進んできました。

ここまで来ると、こう感じませんか？

「クラス同士が、直接つながりすぎている…？」

そこで登場するのが Event設計（イベント駆動設計） です。

1. Event設計ってなに？

一言でいうと：

「直接呼び出さず、”知らせるだけ” にする仕組み」

❌ 直接つなぐ設計

button.onClick = () => {
  game.start();
};

Button が Game を直接知っています。

依存が強いです。

✅ Event設計

button.onClick = () => {
  eventBus.emit("GAME_START");
};

Game 側：

eventBus.on("GAME_START", () => {
  game.start();
});

Button は Game を知りません。

これが 疎結合（Loose Coupling） です。

2. なぜ必要？

規模が小さいうちは問題ありません。

でも…

• Sceneが増える
• UIが増える
• 入力が複雑になる
• 状態が増える

すると、

「どこから呼ばれているのか分からない」状態になります。

Event設計は、

「責任を分離するための構造」

です。

3. 最小EventBusを作る

初心者向けに、最小構成を書きます。

class EventBus {
  constructor() {
    this.events = {};
  }

  on(type, callback) {
    if (!this.events[type]) {
      this.events[type] = [];
    }
    this.events[type].push(callback);
  }

  emit(type, payload) {
    if (!this.events[type]) return;
    this.events[type].forEach(cb => cb(payload));
  }
}

これだけです。

4. どう使うの？

const bus = new EventBus();

// 購読
bus.on("PLAYER_HIT", (damage) => {
  console.log("ダメージ:", damage);
});

// 発火
bus.emit("PLAYER_HIT", 10);

出力：

ダメージ: 10

5. Sceneとの統合

#14 Scene管理進化 では、Sceneを切り替えました。

Eventを使えば：

bus.on("SCENE_CHANGE", (nextScene) => {
  sceneManager.change(nextScene);
});

どこからでも：

bus.emit("SCENE_CHANGE", "game");

SceneManagerを直接呼ぶ必要がなくなります。

6. Event設計のメリット

7. でも注意点もある

• 乱用すると「どこで起きたかわからない」
• イベント名が増えすぎる
• デバッグが難しくなる

だからこそ、

• 命名規則を決める
• Event一覧を整理する
• 責任を明確にする

ことが重要です。

8.実験：Eventあり / なし 比較実験

手順①：まず普通に押す

1. Direct Call を押す
2. Event Call を押す

→ どちらも Game が start する

読者の気持ち：

「え？同じじゃん？」

ここが狙いです。

手順②：Gameを差し替える

Swap Game を押す。

もう一度両方押す。

→ どちらも動く。

手順③：構造を観察する

ここで読者に問いかけます。

Direct Call の構造

UIがこうなっている：

Button → game.start()

UIは「Gameの存在」を知っている。

依存が強い。

Event Call の構造

Button → EventBus → Game

UIは「イベント名」しか知らない。

Gameの実装を知らない。

🔍 観察ポイント

1. 動きは同じ
2. でも設計思想が違う
3. Gameを別クラスに差し替えてみる

Event経由なら、Button側は一切変更不要です。

8. シリーズの位置づけ

• #13 Input設計 → 入力の整理
• #14 Scene管理 → シーンの整理
• #15 Event設計 → 通信の整理（Event）
• #16 実践構築 → すべて統合

Event設計は、

システムを「構造化」する最後のピース

です。

9.まとめ

Event設計とは、

「直接呼ばず、知らせる」

構造。

これにより、

• 拡張性
• 保守性
• 責任分離

が実現します。

次はいよいよ #16 実践構築（統合）です。

ここまで積み上げた

• ループ
• 状態管理
• Scene
• Input
• Event

をすべて統合します。

🔎 このラボの全体像はこちら
→ UI Architecture Roadmap