game-architect

ゲームアーキテクトスキル

ゲームアーキテクチャのドメイン知識リファレンスです。ゲームプロジェクトのアーキテクチャにおけるパラダイムの選択やシステム設計の参考情報を提供します。

メモ

このスキルに含まれるのはドメイン知識のみであり、ワークフローではありません。構造化された設計フローのために、ワークフロースキル（OpenSpec、SpecKit など）またはエージェントのプランモードと組み合わせてください。

利用モード

ワークフロースキルとの併用（推奨）

ワークフロースキル（OpenSpec、SpecKit など）と併用する場合、またはエージェントのプランモードで使用する場合、このスキルはドメイン知識プラグインとして機能します。

• 要件／仕様フェーズ：パラダイム選択ガイドとシステム固有のリファレンスを参照して、アーキテクチャの決定に役立てます
• 設計／計画フェーズ：以下のリファレンス検索ガイドを使って、関連するreferences/ドキュメントを読みます

ナレッジモード（クエリ）

ユーザーがゲームアーキテクチャに関する知識の照会を求めた場合、このスキルはタスクに応じた関連するreferences/ドキュメントのリファレンス検索ガイドを提供します。

---

リファレンス検索ガイド

ゲームアーキテクチャを設計する際は、タスクに応じて関連するreferences/ドキュメントを読みます。

アーキテクチャのリファレンス

条件	参照先
常に（高レベルの構造）	references/macro-design.md
常に（基本原則）	references/principles.md
要件分析	references/requirements-analysis.md
DDD パラダイムの選択	references/domain-driven-design.md
データ駆動型パラダイムの選択	references/data-driven-design.md
プロトタイプパラダイムの選択	references/prototype-design.md
進化と拡張性のレビュー	references/evolution.md
既存の実装における要件の変更	references/requirement-change-strategy.md
パフォーマンスの最適化が必要な場合	references/performance-optimization.md
マルチプレイヤー対応が必要な場合	references/multiplayer-overview.md

• 物理アーキテクチャの設計については、以下の物理アーキテクチャのリファレンス表を参照してください。
• システム固有の設計については、以下のシステム固有のリファレンス表を参照してください。
• マルチプレイヤーシステムの設計については、以下のマルチプレイヤーのリファレンス表を参照してください。

注：マルチプレイヤーが必要な場合にのみ、マルチプレイヤーのリファレンスを読んでください。

物理アーキテクチャのリファレンス

条件	参照先
プロジェクト構成とファイル整理	references/project-structure.md
データ形式、処理、カスタム形式、バンドル、メタデータ	references/data-files.md
ゲームプレイコンテンツのエディターアプリケーションとオーサリングパイプライン	references/content-editor.md
アセット規約とパイプライン	references/asset-conventions.md
配布、パッケージ化、ホットアップデート、CDN、デプロイ	references/distribution.md

システム別リファレンス

システムカテゴリ	リファレンス
基盤とコア（ログ、タイマー、モジュール、イベント、リソース、オーディオ、入力）	references/system-foundation.md
時間とロジックフロー（更新ループ、非同期処理、FSM、コマンドキュー、コントローラー）	references/system-time.md
戦闘とシーン（シーングラフ、空間分割、ECS/EC、読み込み）	references/system-scene.md
UIとモジュール（モジュール管理、MVC/MVP/MVVM、UI管理、データバインディング、リアクティブ）	references/system-ui.md
スキルシステム（属性、スキル、バフ）	references/system-skill.md
アクション戦闘システム（ヒットボックス、ダメージ、近接攻撃、飛び道具）	references/system-action-combat.md
カメラ、キャラクター、コントローラー3C（PlayerController、物理演算、カメラ、アクターの状態）	references/system-3c.md
エフェクトとフィードバックシステム（画面揺れ、VFX、ヒットストップ、触覚フィードバック、SFX、フローティングテキスト、UIフィードバック、オーケストレーション）	references/system-effect-feedback.md
ナラティブシステム（会話、カットシーン、ストーリーの流れ）	references/system-narrative.md
ゲームAIシステム（移動、経路探索、意思決定、戦術）	references/system-game-ai.md
MODとDLCシステム（プラグインアーキテクチャ、設定データベース、スクリプティング、フック、拡張性）	references/system-mod.md
プロシージャルコンテンツ生成（PCG）（ワールド／レベル生成、ローグライク、ノイズ、シミュレーション）	references/system-pcg.md
アルゴリズムとデータ構造（経路探索、検索、物理演算、汎用ソルバー）	references/algorithm.md
パズルゲームシステム（マッチ3、ジグソーパズル、水の仕分け、ブロック、物理パズル、ボードゲーム、コンテンツとプレゼンテーションの境界）	references/system-puzzle.md

マルチプレイヤーのリファレンス

主な対象	リファレンス	使用する場面
マルチプレイヤーの概要	references/multiplayer-overview.md	クライアント／サーバーの責務、権限の分担、ゲームプレイの同期方式を決める
マルチプレイヤーのプロトコルと接続	references/multiplayer-protocol.md	メッセージ、シリアライズ、Req/Resp/Notify、ハートビート、再接続を設計する
マルチプレイヤーのサーバーアーキテクチャ	references/multiplayer-server-architecture.md	所有権の境界、プロセスの役割、デプロイ、永続化、復旧を設計する
共通サーバーコンポーネントとサービス	references/multiplayer-implementation-common.md	認証、ゲートウェイ、コネクター、データベース、キャッシュ、サービスディスカバリー、キュー、可観測性などの共有インフラを構築する
ルームサーバー構築プレイブック	references/multiplayer-implementation-room.md	参加フロー、ルームの所有権、精算、再接続に対応する、具体的な小～中規模のルームベースのリアルタイムサーバーを構築する
エンカウントサーバー構築プレイブック	references/multiplayer-implementation-encounter.md	チェックポイント、冪等なアクション、精算に対応する、具体的なターン制または戦闘ワークフロー型のサーバーを構築する
永続ワールドサーバー構築プレイブック	references/multiplayer-implementation-world.md	リージョンの所有権、移動、位置レジストリ、再接続に対応する、具体的なAOIワールドサーバーを構築する
決定論的同期、ロックステップ、ロールバック	references/multiplayer-deterministic-sync.md	決定論的な入力同期アーキテクチャ、フレームパイプライン、ロールバック、リプレイ、同期ずれへの対処を設計する

---

パラダイム選択ガイド

パラダイム	主な特徴	適用範囲	例	参考資料
ドメイン駆動設計（DDD）	OOP とエンティティ優先	ルールの複雑性が高い。 ドメインの概念が豊富。 異なるエンティティが多数存在する。	戦闘の中核ロジック、物理的な相互作用、ダメージ／バフのルール、複雑な AI の意思決定。	references/domain-driven-design.md
データ駆動設計	データ層優先	コンテンツの複雑性が高い。 フローのオーケストレーション。 シンプルなデータ管理。	コンテンツ：クエスト、レベルデザイン。 フロー：チュートリアルのフロー、スキルの実行、ナラティブ。 管理：インベントリ、ショップ、メール、リーダーボード。	references/data-driven-design.md
ユースケース駆動プロトタイプ	ユースケースの実装優先	迅速な検証	ゲームジャム、コアメカニクスのテスト。	references/prototype-design.md

ここでのデータ駆動設計は、特に設定駆動のゲームプレイを指すのではなく、データ構造を優先するプログラミングパラダイムを意味します。用語の範囲については references/data-driven-design.md を参照してください。

パラダイムの組み合わせ

ほとんどのプロジェクトでは、複数のパラダイムを組み合わせます。

1. マクロな一貫性：すべてのモジュールが同じモジュール管理フレームワークに従います。
2. 中核となるエンティティとルールにはドメインを適用：ルールの複雑性が高く、ドメインの概念が豊富で、異なるエンティティが多数存在するシステム（例：戦闘アクター、ダメージ計算式、AI の意思決定）には DDD を使用します。
3. コンテンツ、フロー、状態にはデータを適用：拡張可能なコンテンツ（クエスト、レベルデザイン）、フローのオーケストレーション（チュートリアル、スキルの実行、ナラティブ）、シンプルなデータ管理（インベントリ、ショップ）にはデータ駆動設計を使用します。
4. ハイブリッドパラダイム：
   • 4.1 エンティティをデータとして扱う：ドメインエンティティは、データ（フィールド）と振る舞い（メソッド）の両方を自然に保持します。別個のデータ層を設けなくても両方の役割を果たせるよう、シリアライズしやすいエンティティを設計します（ID を使用し、状態を通常のフィールドとして保持します）。
   • 4.2 フロー＋ドメイン：シーケンス／パイプラインのオーケストレーションにはデータ駆動のフローを使用し、各ステップのルール処理にはドメインロジックを使用します。例：スキルシステムでは、フローが詠唱→チャネリング→適用を進め、ドメインがダメージ計算とバフの相互作用を処理します。
   • 4.3 データ層とドメイン層の分離：編集時と実行時の表現が実際に異なる場合にのみ分離します。それらをつなぐにはベイク／コンパイルのステップを使用します。例：ビジュアルノードグラフエディター、コンパイル済みアセット。
5. パラダイムの相互置換性：多くのシステムは、どちらのパラダイムでも適切に実装できます。例：アクターの継承階層（ドメイン）↔ ECS コンポーネント＋システム（データ駆動）；ルールをカプセル化したバフオブジェクト（ドメイン）↔ 汎用パイプラインで解決するタグ＋効果データ項目（データ駆動）。トレードオフを判断する際の手がかりについては、上の選択基準の表を参照してください。
6. 統合：アプリケーション層が異なるパラダイムをつなぎます。

選択基準

DDD とデータ駆動設計のどちらも適している場合は、次の手がかりを参考にしてください。

手がかり	DDD を優先	データ駆動設計を優先
エンティティ間の相互作用	複数エンティティにまたがる複雑なルール（攻撃側 × 防御側 × バフ × 環境）	主に CRUD＋表示で、エンティティ間にまたがるルールが少ない
振る舞いの定義元	エンティティの種類ごとに異なり、純粋なデータとして表現しにくい	設定テーブルやデザイナーが作成するコンテンツによって決まる
変更頻度	ゲームバランスの調整に伴ってルールが変わる	コンテンツ／フローがロジックよりはるかに頻繁に変わる
パフォーマンス特性	豊富なオブジェクトグラフによるオーバーヘッドを許容できる	バッチ処理やキャッシュ効率の良いレイアウトが必要
ネットワーク	状態を持つオブジェクトを許容できる	フラットな状態スナップショットが望ましい（同期、ロールバック）
チームのワークフロー	プログラマーがロジックを担当する	デザイナーがコードを変更せずに反復できる

---