DeepSeek新版、Godotでゲーム制作をデモ

DeepSeekは10月17日、V4.1-Flash-1017への更新に合わせ、Godotで作った「Portal 2」風ゲームのデモを公開した。映像ではキューブを持ってポータルを通り、橋を渡って出口へ進む。既存のゲームエンジンで、複数の動作をつないだ場面を見せた。DeepSeekの発表

では、AIとゲームを作る仕事は、実際にどんな工程になるのか。公開デモの観察に続き、「キューブを床スイッチへ置くと出口が開く一室」を共通の題材として、Godot、Unity 6、UE 5.8の制作フローを掘り下げる。各工程は公開仕様から組み立てた編集部の未実行の例であり、DeepSeekのデモの制作履歴ではない。

DeepSeekがGodotで見せたゲーム制作

発表中のGodot作例は、白いパネルと金属の構造物で囲まれた試験室から始まる。画面には「TEST CHAMBER 11」の表示と、右手側の銃状の装置が見える。キューブは視点の前で保持され、手放す操作を案内する表示も付く。Godotで制作したという情報は公式の説明に基づき、ここで述べる動作は公開アニメーションを確認したものだ。

キューブを持った視点が白い壁の青縁の楕円へ近づくと、その内側には別の角度から見た室内が映る。近づくにつれて向こう側の景色が大きくなり、通過後には高い足場へ出る。キューブはそのまま視点の前に残る。ポータルを通って位置が変わる描写まで、映像で追える。

その後、青く発光する橋を渡り、EXITと表示された入口へ向かう。入口付近でキューブが下へ移動し、操作案内は持ち上げる表示に変わる。視点がエレベータ状の区画へ入って振り返ると、扉が閉まり、上部の表示が11、10、09と変わる。部屋を描くだけで終わらず、物の持ち運びと空間の移動が一つの流れに組み合わされている。

ここから「Portal 2の全編を再現した」とまでは言えない。ポータルを設置する場面や、別の操作を試したときの挙動は収録されていない。読み取れる成果はPortal 2を思わせる部屋で、いくつかの動作をつないだゲーム場面を見せたことだ。

DeepSeekは掲載した作例をHarness内で、限られた指示と参考資料、少ない対話で制作したと説明する。ただし、確認した発表にはGodot作例の指示全文、プロジェクト一式、操作履歴は付属しない。映像で動作を観察できることと、同じ条件で制作を再現できることは分けて考える。作例の制作条件

1017版の改善と利用方法

1017版は、既存のDeepSeek-V4.1-Flashを更新したものだ。DeepSeekは自己フィードバックを取り入れた強化学習によって、まとまったプロジェクトを開発する能力が向上したと説明する。Godotの作例はその成果を示すために掲載されたデモの一つに当たる。10月17日の更新説明

視覚入力は9月10日からの機能で、1017版で初めて加わったものではない。また、10月17日のHarness rc.1で加わったMinimalモードの画像読取りは、モデルとは別の作業環境の更新だ。DeepSeekの過去の更新／Harnessのリリースノート

Web版とアプリも新版へ更新され、APIではdeepseek-flashを指定すれば利用できる。呼び出し方と料金は据え置きで、Harnessは0.2.1-rc.1以降への更新が推奨されている。利用方法と推奨版

一室のゲームを作るための要求を決める

ここから扱うゲームは小さくする。一室にプレイヤー、持ち運べるキューブ、床スイッチ、出口の扉を置く。保持していないキューブがスイッチの範囲内にある間だけ扉が開く。持ったまま重ねても開かず、範囲内で拾い直せば閉じる。reset操作ではキューブとプレイヤーを初期位置へ戻し、扉も閉じた状態にする。この内容を共通の仕様として、エンジンごとに必要な仕事を比べる。ポータルの実装は含めない。

最初の依頼には見た目だけでなく状態の変化を書く。「扉を作る」だけでは、初期状態も開閉の条件も伝わらない。「開始時は閉じている」「対象のキューブだけがスイッチを押せる」「持ち上げると解除される」「reset後に同じ操作を繰り返せる」とすれば、モデルは何を作るかに加え、何を確かめるかを決めやすい。床や壁の形は既存の素材で仮置きし、仕組みの確認を先に進める。

受入条件は通常の成功だけでなく解除と繰り返しも含める。プレイヤーだけなら閉じる、保持中のキューブを重ねても閉じる、置けば開く、その場で拾い直せば閉じる、resetで初期状態へ戻る、の5条件を確認する。扉が開いた画像だけでは、解除やresetの条件は分からない。また、プレイヤーがスイッチに乗っただけで扉が開くなら、この例の仕様には合わない。こうした反例を先に用意すると、もっともらしい画面を完成と取り違えにくい。

次に、エージェントへ見せる範囲を決める。新規の部屋でも、既存プロジェクトには入力設定、単位、素材、命名、保存先の決まりがある。モデルへプロジェクト名だけを渡して新しい仕組みを作らせると、既存のプレイヤー制御と競合することがある。対象のシーン、使う素材、変更してよいファイルやオブジェクトを絞り、現在の状態を読んだ結果を受け取ってから編集へ進む。

モデル、Harness、エンジンは役割を分けて考える。モデルは依頼と取得した状態から次の作業を選び、Harnessなどの実行環境がファイル編集や道具の呼び出しを行う。エンジンがプロジェクトを読み込み、ゲームを動かす。MCPはその道具を呼ぶ接続方法の一つであり、モデルでもゲームの自動生成機能でもない。シェルからCLIを直接実行する経路もあり、MCPを使わなければ制作できないわけではない。Harnessの作業環境

変更は観察した症状と結び付く大きさに区切る。扉が開かないときに、入力、キューブの物理設定、スイッチ、扉の移動処理を一度に書き直すと、どの修正が効いたのか追いにくい。まず入力が届いたか、スイッチが対象を認識したか、扉へ状態を渡したかの順に調べる。モデルへは対象名、操作、期待した状態、実際の値やエラーを組にして返す。

Godotでファイルからゲームを組み立てる

実行環境とプロジェクトの入口をそろえる

Godotでは、まずHarnessが対象のファイルとGodotの実行ファイルへアクセスできるようにする。モデルの設定、APIキー、作業フォルダーを選び、使うGodotの版を記録する。チャットにフォルダー名を書くだけでは、モデルに読取や実行の手段は生まれない。クラウド上の実行環境なら、手元のプロジェクトやGodotへどう到達するかも必要になる。ここではGodot 4系のAPIを使う例を考えるが、公式デモで使った版を特定したわけではない。Harnessの設定

最初に読むのは、プロジェクト設定のproject.godot、対象シーンの.tscn、関連する.gdや素材だ。入口のシーン、入力の割当て、ノードの親子関係、スクリプトの参照先を確認する。TSCNはノードとプロパティ、資源への参照、接続を記述するテキスト形式なので、エージェントは構成をファイルとして調べられる。ただし、名前を変えたときの参照関係まで整合させなければ、読込み時や実行時に壊れる。ファイルとプロジェクトの関係／TSCNの構成

部屋の構造とゲームの規則を分けて作る

この例なら、部屋の下にPlayer、Cube、Plate、Doorを置く構成を提案できる。移動をスクリプトで制御するプレイヤーにCharacterBody3D、物理的に動くキューブにRigidBody3D、スイッチの検知領域にArea3Dを使う案だ。それぞれに必要な見た目と衝突形状を用意する。ノードの選択は設計例であって必須の組合せではないが、見える形、物理挙動、判定の役割を分けると、壊れた箇所を追いやすい。プレイヤーの物理body／キューブの物理body

拾う操作にも条件がある。たとえばカメラ前方のRayCast3Dで届く対象を調べ、キューブであり、距離の条件を満たすときだけ操作を受け付ける。どこまで届くか、何の衝突layerを見るか、プレイヤー自身を除外するかを決める。入力は「interact」「reset」などのactionへ割り当て、コード側の名前とそろえる。画面に操作案内があっても、入力名や検知対象が違えば拾えない。RayCastの検知／入力actionの設定

保持中のキューブは、見た目だけを毎フレーム移動させればよいわけではない。物理計算中のRigidBody3DのTransformを繰り返し書き換えると、意図しない挙動につながることがある。保持へ切り替える際の物理状態、離した際の状態、初期位置へ戻すresetを一緒に設計する。この例で重要なのは、どの方式を選んでもheldという保持状態を一か所で管理し、拾う・離す・resetの各処理から更新できることだ。RigidBody3Dの制御上の注意

PlateのArea3Dでは、検知する衝突layerとmaskを合わせ、監視と衝突形状を設定する。bodyの入退出で候補を管理し、その中に対象のCubeがいて、かつ保持されていないかを判定する。保持状態の変化は独自signalなどで通知し、候補の入退出と同じ判定へ集める。Doorはその判定結果を受けて開閉する。この分担なら、扉の見た目を変えても、キューブを受け付ける規則を別に確認できる。Area3Dの検知／signalによる通知

読み込めることと遊べることを順に確かめる

ファイルを書いたら、素材のimport、スクリプトの構文確認、ゲーム実行を分ける。Godotの--importは取り込みを待って終了し、--check-onlyは--scriptと組み合わせて指定スクリプトの構文を調べる。どちらも5つの受入条件を実際に操作する検査ではない。続いて対象シーンを実行し、どのプロジェクトとシーンを起動したか、出力と終了状態を記録する。Godotのコマンド操作

Harnessのシェルは標準出力、エラー出力、終了状態をモデルへ返せる。長い処理を背景で実行する構成ならjob IDを受け取り、後から出力を取得する。起動の返答だけでゲームが最後まで動いたとは決めず、失敗したコマンドと関連するログを読む。毎回新しいシェルを使う実装なので、前の処理で移動したディレクトリを当てにせず、作業先も指定する。Harnessの実行結果とjob

自動検査を行うなら、このゲーム用の試験シーンやスクリプトを作る。キューブを保持・解除した状態を用意し、物理更新を待ってからPlateとDoorを確認し、不一致なら結果を返す。Area3Dの重なり情報は物理処理で更新されるため、位置を書き換えた直後の値だけで判定しない。これは規則を確認する方法で、実際のキー入力から拾えるかという経路は別に試す。フレームと実行の管理／重なり情報の更新時点

画面の確認には描画する実行が必要だ。headlessは描画とウィンドウ管理を無効にするため、そこでエラーがなくてもカメラや操作案内は確認できない。画像をモデルへ渡すなら、Godotで描画後のViewportを画像として保存し、Harnessのread_imageへ渡すなどの経路を用意する。画像読取り自体は画面の撮影もキー入力も行わない。headlessの範囲／描画結果の画像化／Harnessの画像入力

スイッチ上で離しても開かない場合を調べる

想定する不具合は、キューブを持ってPlateへ入り、その場で離しても扉が開かず、いったん外へ出して置き直すと開く、というものだ。Plateが検知した対象、heldの変更、Doorへ渡した開閉値を同じ試行で記録する。重なりは既にあり、heldだけがtrueからfalseへ変わったのにDoorへの通知がないなら、body_enteredでしか判定していない可能性がある。

修正候補は持ち運びの処理から保持変更を通知し、入退出時と同じ開閉判定を呼ぶことだ。Plateを作り直す前に、通知先、接続、保持状態の所有者を確かめる。直したらその場で離す条件を再実行し、保持したまま重ねる条件と、その場で拾い直す条件も戻して試す。resetでは位置だけでなく保持や判定の状態が初期化されるかを確認する。

扉が見た目には開くのに通れない場合は、開閉判定とは別に衝突形状を調べる。実際に出口を通る入力を試し、扉の表示と衝突位置がそろっているかを見る。検証後はシーン、コード、設定の差分を保存し、次の起動で同じ初期状態から始まるかを確かめる。シーン再読込みをresetに使う場合も、autoloadなどに残る状態まで消えると決めつけない。最後に人が操作距離、案内、行き詰まりから戻れるかを試す。シーンの再読込み／実行中の状態を調べる道具

Unity 6でシーンを読み変更を確かめる

接続先を決めて既存の部屋を読む

Unityの公式経路では、Unity 6.0 LTS以降のプロジェクトにPipelineを入れ、実行中のEditorへUnity CLIから接続する。MCPを使う場合は、クライアントがstdioでunity mcpを起動し、CLI内のサーバーがローカルPipelineへ操作を渡す。CLIをシェルから直接呼ぶ方法もある。ここではExperimentalのPipeline 0.8.0-exp.1の文書を基準にする。公式MCPの構成／Pipelineの導入

導入後はコンパイルが終わるのを待ち、接続対象のプロジェクトを確認する。複数のEditorを開いていればパスを指定する。list_open_scenesで開いているシーンと未保存の状態を調べ、get_scene_hierarchyで部屋、プレイヤー、キューブ、扉を探す。既に未保存の変更があれば、それは作業開始時の状態として残す。同じ名前の扉を新しく作る前に、既存の扉を使うのかを決める。シーンと階層の読取

階層だけで動作は分からない。部品のプロパティを読み、スイッチから扉への参照、キューブのColliderやRigidbody、既存の入力処理を確認する。素材やC#はfind_assetsやread_text_fileで探して読む。ここで、保持状態を持つ部品と、扉を開閉するための参照の関係を確かめる。部品の操作／素材とソースの読取

シーンの部品とC#を別々に完成させる

部屋を新しく組むなら、床、壁、キューブ、スイッチ、扉を作り、位置と部品を設定する。PipelineにはGameObjectの作成、Transformの変更、componentの追加・設定を行う命令がある。返答の対象を読み、意図したオブジェクトが変わったかを確かめる。この例の「保持していないキューブだけを受け付ける」という規則は、シーンの形から自動で決まるものではなく、ゲーム側のコードとして作る。GameObjectとcomponentの命令／編集結果と対象参照

部品同士は、スイッチのtrigger Colliderが接触候補を集め、保持担当がCubeのheldを更新し、Plateの判定結果を参照先のDoorへ渡す関係にする。接触通知が必要な組合せのColliderとRigidbodyを確認し、描画用の床と検知用の領域を区別する。拾う・離す処理はheldを変えるだけで終えず、Plateにも知らせる。こうすれば、領域内で状態だけ変わった場合も同じ開閉規則へ届く。接触を通知する部品の条件

新しいC#部品は、ファイルを書いた直後には取り付けられない。公開手順はcreate_script、recompile、recompile_status、attach_scriptの順だ。たとえばPressurePlateという部品を作るなら、型がコンパイルされてからシーンへ付け、扉の参照を設定する。PressurePlateはこの例で付けた名前で、Pipelineに元からあるゲーム機能ではない。スクリプトの作成と取付け

コンパイルの開始応答だけでは次へ進まない。recompile_statusの状態に加え、failed、errors、compilationFailedを読み、完了と失敗を分ける。domain reloadで接続が途切れた場合も、同じ作成処理をすぐ送り直さず、再接続して型や対象の現在値を確認する。応答がない間に変更まで済んでいれば、再送は部品やオブジェクトの重複を招く。コンパイル結果／再接続と処理状態

Play開始から入力と結果の確認へ進む

取付け後はシリアライズされた扉やキューブの参照を読み戻す。正しく配線できたらEdit Modeで初期状態を保存し、editor_playで実行する。ただしPlayに入る命令は、プレイヤーを歩かせたりキューブを拾わせたりする命令ではない。まずeditor_statusで状態を確かめ、consoleでエラーを読み、必要ならscreenshotが返すPNGのパスを画像読取機能へ渡す。Playと画面取得／ログの取得

入力の確認には、人が操作する方法と、Input Systemの試験コードなどを使う方法がある。InputTestFixtureなら仮想デバイスを使った入力試験を組めるが、対象のテストを用意する仕事は残る。Pipelineにも入力シミュレーションはあるものの、Input Systemとruntime側の設定を必要とする別の経路だ。通常のEditor接続だけで、任意のゲーム操作まで自動で済むとは扱わない。入力のテスト／runtime接続の条件

この部屋なら、まずスイッチの判定を試すテストと、拾う入力から扉までを通すテストを分ける。run_testsで対象を絞り、非同期実行ならtest_statusで終了と結果を取得する。開始が受理されたことや、選択したテストが0件だったことを合格としない。5条件のどれを検査し、どの条件で失敗したかをモデルへ返せば、次の修正箇所を絞れる。テストの選択と非同期結果

その場で拾うと扉が閉じない場合を調べる

失敗例として、キューブを置けば開くのに、その場で拾い直しても扉が閉じない状況を考える。まず重なっている対象、保持状態、扉の開閉状態を同じ試行のログへ出す。キューブが領域内に残り、保持状態だけが変わっているなら、入退出イベントだけで扉を更新していないかをコードで調べる。OnTriggerEnterは物理的な接触の通知であり、「持ったかどうか」というゲームの意味までは判定しない。Triggerの通知条件

この症状への修正候補は重なりの候補と保持状態を別々に管理し、どちらが変わっても開閉条件を再評価することだ。保持の通知先が違うなら参照を直し、条件式が正しいのに扉へ届かなければ呼び出し先を追う。修正後はコンパイルを確認し、拾い直す場合だけでなく5条件を再実行する。コンソールが静かなことと、解除条件が正しいことは別なので、実際の値を確認する。

最後はPlayを止め、恒久的な修正をEdit Modeへ残し、保存後のdirty状態とファイル差分を確認する。save_sceneやsave_allはPlay中には使えず、Prefabの変更には別の保存・適用が関わる。Unity Undoへ登録した編集は戻せても、C#の書込みや素材の作成まで一律にUndoできるわけではない。今回のファイルとシーンの変更を人が確認し、操作の分かりやすさを実際に遊んで評価する。保存条件／Undoの範囲

UE 5.8でactorとゲームの状態をつなぐ

公開された道具と追加が必要な操作を見分ける

UE 5.8では、ExperimentalのUnreal MCPと必要なtoolsetを有効にし、再起動後にサーバーを起動する。外部クライアントはローカルHTTPで接続し、list_toolsets、describe_toolsetから実際の操作と入力形式を調べる。ここでは、部屋のactorを編集する道具と、ゲームの規則を作る手段を分けて選ぶ。MCPがつながっただけで「キューブのゲームを作る」という一式の機能が現れるわけではない。Unreal MCPの導入と道具の取得

UEにはBlueprintの構成を読むEditor APIもあるが、すべてが標準MCPの道具として公開されているとは扱えない。導入版に必要な操作があればそれを使い、なければ範囲を絞った独自toolやEditorスクリプト、人による編集を選ぶ。以下でBlueprintEditorLibraryなどのAPI名を挙げる箇所は、その追加実装で使える機能の説明だ。PythonはEditor内の制作を自動化する手段で、実行時の拾う・開く処理はBlueprintやC++として残す。Editor Pythonの役割

actorの配置からBlueprintの関係を読む

最初に対象mapと既存の変更を確かめ、床、Cube、Plate、Doorのactorを特定する。独自の読取toolを作る場合、EditorActorSubsystemは読み込んだEditor側のactorを列挙し、パスから参照を解決できる。ただし、この一覧はPIEで動くactorを含まない。編集画面に置いたCubeと、実行中のCubeの状態は区別して記録し、同じ名前だから同じ値を読めていると思い込まない。Editor actorの参照範囲

Blueprintで作る案なら、Cubeの保持変数、Plateの重なり候補、Doorへの参照、reset時の処理を先に図にする。BlueprintEditorLibraryにはgraph名、member変数、event実装を調べるAPIがあり、既存の仕組みを読む入口になる。空のBlueprintを作るだけでは規則は完成しない。どのeventで候補を更新し、どの保持変更から再評価を呼び、どのDoorへ結果を渡すかを、接続まで含めて確かめる。Blueprintの構造を読むAPI

作る関係は、Plateのoverlap用componentが対象actorを候補へ追加・除外し、Cubeの保持担当がheldの変化を通知し、Plateの再評価からDoorの開閉処理を呼ぶ、というものだ。通知するCubeと候補のCubeが同じインスタンスか、Doorの参照が対象の扉かを確かめる。resetは各actorの位置だけでなく、保持と候補の状態も戻す。これらは編集部のゲーム設計であり、MCPの接続だけで供給される規則ではない。

追加toolでgraphを編集するときも、接続できたという文章だけで終わらせない。BlueprintGraphPinにはpinの型や接続先を読む機能、接続の可否を調べる機能があり、実際の接続や値の設定は失敗を返すことがある。たとえばDoorの参照を渡すpinへ別の型をつなごうとしていないか、実行順の線が判定から開閉へ届いているかを読み戻す。このAPIの存在は標準MCPだけで全ノードを自動生成できるという証拠とは別だ。pinの型と接続結果

変更後のコンパイルも対象を区別する。BlueprintEditorLibraryのcompile_blueprintは、エラーなくコンパイルできたときにtrueを返すAPIだ。これを追加toolで使うなら、そのbool結果を返し、診断は別に収集できた場合に添える。一方、C++を変更した場合の公式CompileLiveCodingは、Live Codingを有効にしたEditorで完了を待ち、状態とエラー・警告を返す。両者は同じ「compile」という言葉でも、調べた成果物が違う。Blueprintのコンパイル／Live Codingの結果

PIEの起動とゲームの合格を分ける

Playの操作も、呼び出した後の状態を見る。たとえば追加連携からLevelEditorSubsystemのeditor_request_begin_playを使うと、返り値はNoneで、合格結果ではない。is_in_play_in_editorでPIEに入ったかを別に確かめる。その後に人の入力や試験処理を行い、実行中のCubeのheld、Plateの候補、Doorの状態を読む。Editor側の配置を再取得しただけでは、この確認の代わりにならない。Play要求と状態取得

5条件を反復して検査するなら、対象レベルにFunctional Testを用意する方法がある。準備が整ってから試験を開始し、各条件の期待値と実際の値を比較して、FinishTestで結果を返す。試験用に作ったactorや変更状態は終了時に片付ける。毎回きれいな部屋から試せなければ、前の試験で開いた扉が次の失敗を隠すことがある。テストを起動する機能と、正しい条件を記述する仕事は分かれている。Functional Testの開始と終了

導入済みMCPに必要なテスト操作があれば使えるが、CLIからAutomationを実行してレポートを出す経路もある。公式の-ReportExportPathではJSONと関連HTMLを保存できる。追加toolがこの経路を使うなら、プロセスの開始、終了、対象テスト、結果ファイルの場所を分けて返す設計にする。モデルが読むのは「実行した」という要約だけでなく、どの条件が失敗し、どのログが出たかという内容だ。Automationの実行と結果出力

画面の証拠にも完了待ちがある。追加実装で高解像度スクリーンショットAPIを使う場合は、返ったtaskの完了を確認し、実際に保存された画像をモデルへ渡す。画像比較のAPIにも、trueが比較の成功ではなく、比較要求を受け付けたことを意味するものがある。また、ゲーム画面だけの撮影とUI込みの撮影は別なので、操作案内まで確かめたいときは対象を合わせる。画像取得と比較のAPI／画像taskの完了

保持変更が扉へ届くまでを切り分ける

ここでは、保持したCubeをPlateへ運ぶと扉が開いてしまう失敗を考える。最初にPIE側の重なり対象とheldを記録し、Plateがプレイヤーや別actorまで候補に入れていないかを見る。対象は正しいのに開くなら、Blueprintの分岐が「重なっている」だけを見て、保持条件を使っていない可能性がある。heldを読む参照が別インスタンスを指している場合も、見た目が同じ変数名だけでは気付けない。

証拠に応じて、候補の絞込み、保持条件の参照、再評価の呼び出しのいずれかを直す。保持中は閉じるようになっても、離す処理が再評価を呼ばなければ今度は開かない。そのため、Begin／EndOverlapに加えて保持変更からも同じ条件へ到達することを確かめる。コンパイル後は5条件を実行し、扉の表示だけでなく通行できる衝突状態も確認する。

保存ではmapとcontentのdirty packageを分けて読む。EditorLoadingAndSavingUtilsはそれぞれを列挙し、明示したpackageの一覧を保存できる。開始前からdirtyだった無関係の素材まで、今回の成果としてまとめない。UE 5.8.1ではAssistantによるscript実行中の変更を一つのtransactionへまとめなくなっているため、MCPの依頼一つをUndo一回で戻せるとは約束できない。対象package、graph、参照を人が確認して保存し、やり直せる版を残す。dirty packageと保存／5.8.1のtransaction変更

公式と外部MCPをどう選び分けるか

10月17日の新発表はDeepSeekのモデル更新と制作デモであり、ここで比較するUnityやUE、外部bridgeが同日に登場したわけではない。以下は2026年10月18日に確認した文書と固定版の実装に基づく。Unity CLIは10月7日の1.0.0-beta.13、外部MCP for Unityは10月4日のv10.3.0を確認した。Unity CLIの更新記録／外部bridgeのrelease

ここまでの工程を比べると、同じMCP対応でも任せられる作業はそろわない。現在のEditorを操作する接続と、別プロセスから保存済みファイルを変更する接続では、見える状態も保存の意味も違う。公式か外部実装か、対応版、取得できる結果をそろえて比較し、使いたい道具の名前があるだけで選ばない。

Godotの外部例であるCoding-Solo版では、create_sceneやadd_nodeが別のheadless Godotプロセスを使ってシーンを保存する。3Dの部屋ならrootの型も明示する。run_projectは起動の返答を返し、動いている間の出力はget_debug_outputで読む。確認commitには画面撮影、キー入力、既存Editorの生きたシーン階層を読む道具はなく、その部分は別の手段を組み合わせる。確認した実装／シーン編集の処理

この実装ではゲームの自然終了後に追跡中のプロセスが消えるため、後から同じ道具で出力を取り戻せるとは限らない。短い自動検査ならファイルにもログを残す、といった設計が役立つ。Harnessへstdioサーバーとして設定する場合も、設定項目を書いたことと接続成功は別だ。実際に取得できた道具と対象のGodotを確認する。今回、この組合せを実行して確かめてはいない。プロセスとログの寿命／HarnessのMCP接続

Unityの外部例では、同じrun_testsという名前でも戻り方が違う。Aura保守のv10.3.0はjob IDを返し、get_test_jobで進捗と終了時の結果を読む。待機時間が切れて進捗が返っただけなら、テストはまだ終わっていない。テストgroupの有効化と、プロジェクトに検査対象のテストを用意することも必要だ。公式Pipelineのtest_statusをそのまま呼ぶことはできない。外部実装の非同期テスト／jobの状態と結果

料金と権限も接続とは別に確認する。Unity CLIは無料で、挙げたGodot・Unityの外部bridgeはMITライセンスだが、モデル利用料やエンジン・素材の条件まで共通になるわけではない。また、道具を一覧から隠すこと、人が実行を承認すること、実行環境が書込みを制限することは別の仕組みだ。たとえばUEのRegistry設定は公開toolを絞れるが、それを任意のスクリプトに対する包括的な制限とは扱えない。Unityの利用条件／UEの公開範囲設定

動く場面から修正を続けられるゲームへ

3つの工程に共通する成果物は、動いている画面だけではない。変更したシーンや素材、コード、初期状態、5条件の確認結果が必要になる。モデルの「完成した」という返答に加えて、どのファイルとオブジェクトを変え、どの実行で何を確かめたかを残せば、次の修正を別の人や別のセッションへ渡しやすい。今回は工程を説明したもので、この部屋を実装して検査に通したという実績ではない。

機械的な5条件に通っても、人が遊ぶと別の問題が見える。どの距離で拾えるか、持っている状態が伝わるか、扉が閉じる理由が分かるか、失敗した後にresetへ戻れるか。キューブを置いた瞬間の反応が遅ければ、動作は正しくても操作を取り違えやすい。画面とログで判定できる部分をエージェントへ渡し、操作感や説明の分かりやすさは実際のプレイで評価する。

この分担は、継続するエージェントが作業と記録を引き継ぐ問題にもつながる。エージェントの比較記事で扱ったように、次の判断へ渡せる記録があるかが、長い仕事では効いてくる。ゲームなら、完成画像だけでなく、どの状態で扉が開き、どの検査をやり直せばよいかを残すことになる。

DeepSeek新版のGodotデモは、物を運び、ポータルを通り、出口へ進む場面を見せた。その先の制作を考えると、モデルがコードを書く能力に加えて、プロジェクトを読む手段、変更を実行する道具、失敗を次の修正へ戻す情報が必要になる。Godot、Unity 6、UE 5.8ではその入口が異なる。どの工程の結果まで受け取れるかを具体的に見ることで、任せられる仕事と人が判断する仕事を分けられる。