AIゲーム開発

まず完成した小さなゲームループから始める

最初の目標には、開始と終了が観測できる一つの活動が適しています。ラウンドを開始し、移動または選択を行い、課題に遭遇し、勝敗に到達して再開する流れです。エージェントにファイルを書かせる前に、各遷移でプレイヤーに何が見えるかを定義します。洗練されたタイトル画面だけでは、ループが機能することは証明できません。

最初は対象プラットフォームを一つと、入力デバイスの小さな集合を選びます。追加レベル、ネットワーク、プロシージャルコンテンツは後の範囲として扱います。そうすればプロトタイプが失敗しても診断しやすくなります。壊れた衝突ルールと未完成の機能を区別でき、プロンプトの範囲を繰り返し広げずに済みます。

ワークフローを選び、その後でエンジンを選ぶ

オリジナルの小規模2Dプロジェクトなら、まずGodotの文書化されたCLIで、検査、編集、実行のループを評価します。既存プロジェクトやチームがすでにエディタワークフローに依存している場合は、Unityが有力な出発点です。最初のプロトタイプと同じくらい、成果物を維持できるかどうかを選択基準にしてください。

自分のマシンで失敗を再現するために必要な作業を比較します。プロジェクト構造、ビルド前提条件、エラーを説明できるものが、最初の出発点として適しています。エージェントを使っても、エンジンのアップグレードやサードパーティーパッケージへの責任がなくなるわけではありません。

モデルへのアクセスとエンジンツールを分けて管理する

エージェントには異なる二つの接続があります。推論と編集を生成するモデルサービスと、プロジェクトを検査または操作するローカルツールです。Godot MCPとUnity MCPはツール側に属します。どちらかをインストールしても、モデルプロバイダーが選ばれることや、ゲートウェイ統合が証明されることはありません。

エージェントクライアントではモデル接続を、ツール設定ではエンジン接続を選びます。それぞれを小さな操作で独立に検証してください。ローカルプロジェクトのパスが間違っているなら、そのパスを直します。モデルのエンドポイントを変えても、意図したシーンは表示されません。

最初のブリーフをテスト可能にする

必要なシーン、プレイヤーの操作、状態遷移、永続化の動作に名前を付けます。それらを満たす最小実装と、未解決の判断を明示した一覧を求めてください。以下の例示ブリーフを出発点にし、実際に作りたいゲームに合わせて範囲を置き換えます。

最初のブリーフは変更せずに記録します。要件を追加したら、範囲の変更としてラベルを付けます。失敗を説明したり自分でファイルを編集したりした場合は、介入として記録します。これにより、最初の一つのプロンプトと、その後に続く多数のモデルおよびツールの反復を区別できます。

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

レビュー可能な変更で進める

最初の足場ができたら、移動、次に衝突、次にラウンド終了の遷移というように、一度に一つの動作を求めます。変更されたファイルを確認し、各変更後に同じ受け入れ経路を実行します。外部パッケージを追加したりインポート設定を変更したりする前に、既知の動作状態を保持してください。

エージェントには、単にもっと頑張るよう求めるのではなく、関連するエラー、シーンのコンテキスト、観測した動作を渡します。同じ症状が編集を繰り返しても残るなら、停止して境界を切り分けます。インポートされていないリソースと誤ったノード参照は、どちらも空のシーンを生じさせても、必要な修正は異なります。

アセットとローカライズを制作入力として扱う

ソース、権限、作者またはツールの識別情報、変更内容、想定用途を含むアセットマニフェストを保持します。スプライトはゲームプレイ時の大きさで確認し、透明度、フレームの整列、コントラスト、衝突範囲を確認してください。もっともらしい画像が、そのまま使えるスプライトシートになるわけではありません。

プレイヤー向け文字列は、安定した識別子で参照できるようにします。翻訳コンテキストを渡し、フォーマット引数を保護します。画像、音声、フォント、翻訳テキストは、配布前にそれぞれレビューが必要です。画像生成の支出はテキストモデルによるコーディング作業とは別に記録してください。アセットのライセンスやエンジンのライセンスがあっても、プロジェクト内のすべてのファイルの権利が確定するわけではありません。

各提供状態を独立に証明する

プレイ可能なデモには、誰かが意図したループを完了できることが必要です。エクスポートには生成された成果物が必要です。テスト済みエクスポートには、対象プラットフォームでその成果物を起動することも必要です。Steamへの提出とリリースは、さらに後のプラットフォーム状態です。進捗を共有するときは、これらのラベルを正確に使ってください。

ビルドの識別情報、テスト入力、実際のプレイから得たスクリーンショット、残っている失敗を保持します。ブラウザのキャプチャには、単なるローディング画面ではなく、入力後に変化するゲームプレイを表示します。別のOSでエクスポートしたWindows実行ファイルには、なおWindowsでの検証が必要です。Steamのアカウントとスケジュール要件は、Steamガイドで別途確認してください。

Playcoの例からワークフローについて分かること

OpenAIの2026年9月3日のカスタマーストーリーでは、Playcoがゲームエンジンに接続したIDEであるPlaybotでAstraを使ったと説明されています。チームはテーマ付きのプロトタイプを作る前に、グレーボックスの基盤を反復しました。これはベンダーが公開した顧客事例であり、APIsRouterのベンチマークではありません。

実務上の要点はワークフローの形です。まずプレイ可能なメカニクスを確立し、その後で共通の基準を保ったまま見た目を変えます。創作上の好みと不具合修正を分けて、各反復で何を達成したかを確認できるようにします。報告された結果を自分のゲームの予測として扱わず、元の事例を読んでください。

ローカルGodotプロトタイプを検査する

Switchyardは、ローカルのCodex開発実行で作られた3部屋の小さな回路パズルです。ソースプロジェクトには、キャラクター移動、スイッチ、ドア、収集セル、部屋のクリア、敗北と再開、設定、保存された進行状況が含まれます。自動化されたエンジンチェックでゲームプレイループを検証し、別プロセスでセーブを再び開きました。以下のスクリーンショットはコンセプトアートではなく、実際のGodotビューポートのキャプチャです。

記録された実行ではGodot 4.5.1を使いました。モデルの識別情報とAPI課金は観測できなかったため、Astraの性能またはコストのベンチマークとして提示していません。ダウンロード可能なソースとPCKはローカルプロジェクトを示しますが、PCKにはGodotが必要です。スタンドアロンWindowsビルド、ブラウザエクスポート、人間によるプレイテスト、Steamリリースは別の作業として残っています。この例は、提供状態を主張する前にエージェントへ求めるべき具体的な成果物を示します。

ボトルネックに応じて次のガイドを選ぶ

環境が決まっていないならエンジン選択から、ツールの検出に失敗するならMCPセットアップのページから、プロジェクトは開くが動作が正しくないならデバッグガイドから始めます。修理の繰り返しが支出の大部分を占めるならコストガイドを使います。モデルを変えるより範囲を縮小することが重要な場合もあります。

これらのガイドはソースに基づくワークフローと例を提供するもので、測定済みのエンジン順位ではありません。リンク先のAstra実験では、個別のケースに必要な証拠を説明しています。自分のプロジェクトでは、具体的な障害を解消する次の一歩を選び、ゲームを拡張する前に結果を保持してください。

よくある質問