mcpField
U
unity-architecture

unity-architecture

github.com/besty0728開発1.9k90 回インストール今日更新
リポジトリ

unity-architecture について

unity-architectureは、コード構成やリファクタリングを計画するUnity開発者向けのアドバイザリースキルです。プロジェクト規模に応じた構成を提案し、初期化順序や更新の前提条件を明示して過剰な抽象化を避けます。

主な機能

  1. 01規模に応じた構成提案
  2. 02モジュールと層の責務整理
  3. 03明示的な起動順序
  4. 04更新時の準備状態チェック
  5. 05過剰設計の回避

活用シーン

  1. 01新しいゲームのコード構成計画
  2. 02リファクタリング時の結合度低減
  3. 03初期化と更新の前提確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/besty0728/unity-skills --skill unity-architecture

インストール後、Claude Code で/unity-architectureを入力して読み込まれたか確認します。

詳細

このモジュールのスキルを呼び出す前に： スキル名や説明から推測したパラメーターでスキルを呼び出そうとしている場合は、いったん停止し、まずこのファイルを読むか、GET /skills/recommend?includeSchema=true でスキーマを取得してください。recommend/schema からすでにパラメーター定義を取得している場合は、そのまま dryRun に進んでかまいません。

トリガー

  • コード構成を計画する
  • 責務を分割する
  • 結合度を下げる
  • リファクタリングの方向性を決める
  • コード構成の計画、責務の分割、結合度の低減、リファクタリングの方向性の決定

Unity アーキテクチャアドバイザー

ゲームプレイ用スクリプトを大量に生成する前、またはユーザーからよりすっきりしたアーキテクチャを求められたときに使用します。

ワークフロー

  1. 範囲を特定します。プロトタイプ、小規模ゲーム、長期運用プロジェクトのいずれかです。
  2. コアとなるループと、必要最小限のランタイムシステムを定義します。
  3. 範囲に適した、最小限のアーキテクチャを推奨します。
  4. 次の要素を分離します。
    • シーン／ブートストラップ層
    • ゲームプレイ／ドメインロジック
    • データ／設定アセット
    • ビュー／プレゼンテーション層
  5. 今はシンプルに保つべきものと、抽象化する価値のあるものを示します。

出力形式

このスキルを使用する際は、次の形式でアドバイスを構成します。

  • プロジェクトの規模：プロトタイプ／小規模ゲーム／長期運用
  • 推奨モジュール：3～7個のモジュールと、それぞれの役割を示す1行の説明
  • シーン／ブートストラップ計画：構成と初期化を行う場所
  • データの所有者：シーンオブジェクト、ScriptableObjects、純粋な C# クラスのどれに属するか
  • 通信ルール：直接参照、インターフェース、イベント、コマンドのいずれを使うか
  • パフォーマンス上のリスク：影響するホットパスのみ
  • 今やること／今は避けること：過剰な設計を避ける

デフォルトの指針

  • MonoBehaviour スクリプトは、構成をつなぐ薄いブリッジとして使います。
  • 可能な場合は、再利用可能なゲームプレイのルールを通常の C# クラスに配置します。
  • ScriptableObject は、作成者が編集する設定や共有の静的データに使用し、ランタイム状態を何でも格納する場所にはしません。
  • 依存関係を明示します。プロジェクトの規模から小規模なサービス層が明らかに妥当でない限り、隠れたグローバル状態は避けます。
  • フレームワークに大きく依存するアーキテクチャより、シンプルなモジュール境界を優先します。

実行順序とエントリーガードを明示する

「ランダムな」ゲームプレイのバグの多くは、2つの暗黙の前提に起因します。スクリプトが予測可能な順序で実行されること、そしてデータの準備ができるまで Update が実行されないことです。どちらも、明示的に設定しない限り成り立ちません。

起動順序を明示する

Script Execution Order パネルや、偶然の Awake の実行順序に依存しないでください。次のパターンを、上から優先して使用してください。

  • 単一の Bootstrap スクリプトを唯一のエントリーポイントにします。初期化の順序を管理し、生成したマネージャーに対して sub.Init() を呼び出します。[DefaultExecutionOrder(-10000)] を持つのは、このスクリプトだけにします。
  • プッシュせず、プルする：データを必要とする購読側は、必要に応じて source.GetValue() を呼び出すか、イベントを購読します。パブリッシャーが自身の Awake 中に他のオブジェクトへデータをプッシュすると、隠れた順序依存が生まれます。
  • [DefaultExecutionOrder(n)] は、重要なシングルトン（Bootstrap、InputRouter、SceneController など）に限って使用します。 必要とするスクリプトが3～4個を超える場合、問題は実行順序ではなくアーキテクチャにあります。

類似する ECS のパターンである [UpdateBefore(typeof(BarSystem))]／[UpdateAfter] が機能するのは、フレームワークがソート時に矛盾を検証するためです。MonoBehaviour のコードではコンパイラーが矛盾を検出しないため、慎重に使用してください。出典：EntitiesSamples/Docs/systems.md:32 —「グループの子の順序属性が矛盾を生じさせる場合、例外がスローされる」。

更新の前提条件を明示する

すべての Update／LateUpdate／FixedUpdate の先頭にガード節を置き、システムの準備ができていない場合は早期リターンするようにします。最もコストの低いチェックを先に行ってください。

void Update() {
    if (!_isInitialized) return;       // construction-time
    if (_dataSource == null) return;   // dependency-level
    if (_paused) return;               // gameplay-state
    // real work here
}

ガードがない場合、「まだ実行されない」（安全）か、「古いデータや null データを使って実行され、状態を気づかれないまま破損させる」（デバッグ上の悪夢）かの違いが生じます。ECS で同等の処理を行うには、OnCreate で state.RequireForUpdate<Config>() を使い、前提条件をシステムレベルの不変条件にします。出典：Dots101/Entities101/Assets/HelloCube/3. Prefabs/SpawnSystem.cs:17-19 — Spawner エンティティが存在しない限り、システムは更新されません。

ガードレール

モード：ドキュメントのみ — 制限対象となる REST スキルはありません。どの動作モード（Approval / Auto / Bypass）でも自由に読み込めます。

  • プロジェクトで本当に必要でない限り、巨大で再利用可能なフレームワークから始めないでください。
  • 教科書的な SOLID の表現を満たすためだけにレイヤーを追加しないでください。
  • イテレーションを遅らせる見栄えのよいアーキテクチャではなく、成長できる小さなアーキテクチャを優先してください。

必要に応じて関連するアドバイザリーモジュールを読み込む

コメント

Markdown 対応