Unity AIゲーム開発

既存プロジェクトの契約から始める

エージェントに書き込み権限を与える前に、選択したUnityエディタ、プロジェクトパス、対象プラットフォーム、パッケージ、レンダリング設定を特定します。プロジェクトのバージョンと依存関係のロックを実験記録とともに保持します。必要なエディタアクセス権と対象モジュールが運用者にあることを確認してください。モデルアクセスでこれらの前提条件を補うことはできません。

プロジェクトで確立した規約を使い、一つの小さなプレイ可能シーンを定義します。チームにすでにキャラクターコントローラーや入力抽象化があるなら、置き換えを提案する前にエージェントへ検査させます。これにより生成変更をレビューしやすくなり、ゲームの他の部分が依存するシステムを迂回した、見かけ上独立したプロトタイプを防げます。

エディタ自動化を別の接続として扱う

CoplayDevのUnity MCPプロジェクトは、互換性のあるクライアントにエディタ操作を公開します。インストールガイドには、エディタパッケージとサーバー接続が説明されています。エージェントのモデルサービスは別物です。モデルの認証情報を変えても、利用できないエディタインスタンスは直りません。

まず読み取り専用のプロジェクト検査を行い、どの開いているインスタンスがリクエストを受けるか確認します。変更の承認は、使い捨てのシーンや明示的に所有する機能に限定してください。ツールが成功を返すのは、そのツール自身の境界で操作が完了したことを意味します。結果のシーンに誤った参照が残っていたり、プレイ中に失敗したりする可能性はあります。接続確認とバージョン記録は専用のMCPガイドで扱います。

目に見える結果を伴う範囲限定の変更を求める

失敗のたびにシーン全体を書き換えさせるのではなく、コントローラーの調整、一つのメニュー遷移、小さな永続化機能などを求めます。プレイヤーが何をし、どの状態が変わり、結果をどう観測するかを明示します。生成された変更を受け入れる前に、以前の動作状態を保持してください。

以下の例示ブリーフを使い、範囲を限定した変更とレビュー基準を定義します。シーンとプレハブでは、スクリプトの差分だけでなく、オブジェクト参照と保存された状態も検査します。ゲームプレイを決める設定がソースファイルだけに含まれているとは限りません。編集前に、影響を受けるオブジェクトをエージェントに特定させます。

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

プレイ結果を解釈する前にコンパイルを待つ

コードのコンパイル、エディタの準備完了、ゲームプレイを観測ログで分けます。コンパイルに失敗したら、最初に関係するエラーと変更されたソースのコンテキストを取得します。エディタが対象スクリプトを読み込めない間に移動調整を求めないでください。無効なベースラインに対する追加編集が生じます。

コンパイル後、プレイに入る前に想定したコンポーネントと参照を確認します。修正後は同じプレイヤー操作を再現します。エラーのないコンソールは有益な証拠ですが、ゲームが意図した状態に到達する必要があります。症状を変えない編集が続くなら、より大きな置き換えではなく、より小さい再現に切り替えます。

プロジェクトのテストフレームワークを意図的に使う

Unity Test Frameworkには、コマンドラインでのテスト選択と結果出力が文書化されています。以下の例では、フレームワークがすでに設定され、テスト結果ディレクトリが存在することを前提にしています。UNITY_BINとPROJECTは、既存のエディタとプロジェクトを指す説明用のシェル変数です。リファレンスドキュメントをインストール済みパッケージに合わせてください。

適切な分離ロジックにはEditModeチェックを、実行が必要な動作にはPlayModeチェックを実行します。これらのカテゴリーは、操作と見た目の実地レビューの代わりにはなりません。テスト数、失敗数、結果ファイルをテスト対象のリビジョンとともに保持します。テストを一件も検出しない実行から、ゲームが通過したとは判断できません。

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

プレイヤーを生成する前にビルド入力をレビューする

ビルドには、レビュー済みのシーン選択と対象設定を使います。現在エディタで開いているシーンが起動時に含まれるとは限りません。後の失敗を正確な成果物に結び付けられるよう、ビルドの識別情報とログを保持してください。

UnityのCLIでは、-executeMethodを通じて既存のstaticなエディターメソッドを呼び出せます。このフラグがビルド実装を作るわけではありません。プロジェクトには、明示的なビルド動作と失敗処理を持つ実際のメソッドが必要です。存在しないのに実行できそうに見えるサンプルメソッドを作るのではなく、チームの既存ビルドエントリーポイントを優先してください。

エディタの外でゲームプレイを検証する

宣言したOSで、期待する操作とクリーンな開始状態を使って提供プレイヤーをテストします。最初の画面から入り、ラウンドを完了し、再開し、設定を変え、再起動します。ウィンドウが開くかだけでなく、受け入れブリーフと永続化および遷移を比較してください。

その成果物から真正なスクリーンショットと、入力で操作した短いシーケンスを記録します。エディタ実行は通るのにビルドが失敗する場合は、エージェントにゲームプレイの中核を書き直させる前に、シーンの同梱、リソース依存関係、プラットフォーム固有の動作を調べてください。変化した境界は原因の手がかりになります。

人間の作業と未解決の依存関係を追跡する

手動のインスペクター変更、アセット編集、追加した指示、環境修理を介入記録に残します。モデル使用量を生まない場合でも、それらは制作作業の一部です。コストをレビューするときは、テキストのコーディング呼び出し、画像生成、エンジン作業、対象デバイスでのテストを区別します。

このドキュメントに基づく手順は、選択したエディタとパッケージのバージョンで検証してください。引き継ぎには、接続、変更、コンパイル、プレイ、エクスポートという最小限の完全ワークフローを残します。別の開発者が再現できるようになったら、そのベースラインを次の機能に使い、依存関係やビルド対象が変わるたびに確認をやり直します。

よくある質問