犬にキーボードを叩かせてゲームを作る、というCaleb Leak氏の記事 I Taught My Dog to Vibe Code Games がある。小型犬MomoがBluetoothキーボードを叩き、そのランダムな入力をClaude Codeが「天才ゲームデザイナーの暗号的指示」として解釈しゲームを生成する。
おやつディスペンサーの自動化まで含めた一連の仕組みは、読み物として単純に面白い。それに加えて興味深いのは、ゲームエンジンとしてGodotを採用していたことだ。筆者はBevy、Unity、Godotを比較検討した上でGodotを選んでいる。理由は、Godotのシーンファイル（.tscn）がテキスト形式であり、Claude Codeが直接読み書きできるからだ。Unityについては、エディタとの間のMCPブリッジが頻繁にハングし、シーン階層の読み取りもうまくいかなかったと書いている。
この選択理由が気になり、自分でも調べてみた。
なぜGodotとCLIエージェントの相性が良いのか
GodotがCLIベースのAIエージェントと組みやすい理由はいくつかある。
CLI経由のビルドが簡単
Godotは --headless と --export-release を 公式CLIで直接提供 している。エージェントがコードを編集した後、1コマンドで Webビルド まで到達できる。Unityも -batchmode と -nographics を持つが、カスタムスクリプト対応などの都合で、-executeMethod による独自ビルドメソッドの整備が必要なこともある。
テキストベースのリソース管理
Godotの .tscn や project.godot はプレーンテキストである。エージェントがファイルを直接読み書きしても参照が壊れにくい。Unityは .meta ファイルとGUID整合性がリソース参照の前提であり、エージェントによる自動編集ではその運用に気を付けなければならない。
MCPサーバなしで始められる
Godot向けMCPサーバは複数公開されているが、実はそれらは使わなくても良い。CLIエージェントがファイルを直接編集し、godot --headless でビルドとテストを実行すれば、それだけで開発ループが成立する。セットアップの手間が少ない分、実験に入るまでの距離が短い。
試してみた
実際に自分でも試すことにした。定番のフラッピーバードを、WSL2上のCodex CLI、--headlessで使うGodot 4.6.1のLinux版、この組み合わせで作った。具体的な作り方は以下だ。
- CLIエージェントがGDScriptとシーンファイルを編集する
- Godot headlessでビルドとWebエクスポートを実行する
- ブラウザで人間がプレイして確認する
ビルドは以下のように1コマンドで完結する。
godot --headless --path /home/me/godot-project \ --export-release "Web" /home/me/godot-project/build/web/index.html
※ コーディングエージェントのサンドボックス制約により、Godotが標準で使うユーザーデータ保存先（
~/.local/share/godot、~/.config/godot、~/.cache/godot）に書き込めず、--export-releaseでエラーが出たり--script実行がクラッシュしたりする。この場合は、これらの保存先（XDG_DATA_HOME/XDG_CONFIG_HOME/XDG_CACHE_HOME）をプロジェクト内の.tmp-godot-data/.tmp-godot-config/.tmp-godot-cacheに切り替えて実行する。
エクスポートが終わったら、build/webをローカルサーバで配信し、ブラウザで開く。この「編集→ビルド→ブラウザ確認」のループは短く、開発体験は良い。
当たり判定とスクリーンショット
開発中、パイプと鳥の当たり判定がずれる問題が起きた。見た目では鳥がパイプにぶつかっているのにすり抜けてしまう。CLIエージェントに「当たり判定がずれている」と文章で伝えても直らない。エージェントはコードを修正するが、ずれの方向や程度がわからないため、的外れな修正を繰り返す。
解決したのは、デバッグ描画として当たり判定の矩形を画面上に表示させ、そのスクリーンショットをエージェントに渡したときだった。視覚情報を与えた途端、エージェントはずれの方向と量を正確に把握し、一度で修正を完了した。
dog-game記事の筆者も同じ結論に達している。スクリーンショットツールと自動プレイテストを導入した途端、ゲームの品質が跳ね上がったという。筆者はこう書いている。
the bottleneck in AI-assisted development isn't the quality of your ideas - it's the quality of your feedback loops.
今回の体験もこれと一致する。エージェントが自分の出力を確認できる手段をどれだけ持っているかが結果を左右する。
headlessテストという保険
視覚的な確認は人間が担うとして、機械的に検証できる部分は自動化しておきたい。そこでheadlessテストを書いた。GDScriptで SceneTree を継承したスクリプトを --script オプションで実行する。
godot --headless --path /home/me/godot-project \ --script res://scripts/tests/run_collision_tests.gd
このテストでは3点を検証している。
- パイプの当たり判定Shapeがインスタンス間で共有されていないこと（GodotのShapeインスタンスを共有すると、全てのパイプのサイズが同時に変化してしまう）
- 見た目の矩形と当たり判定矩形が意図どおり整合すること
- 鳥をパイプの間の中央・上端・下端に配置したときの衝突判定が正しいこと
一度直した当たり判定のずれが再発しないように、このテストをリグレッションテストとして使っている。エージェントが何かを壊したとき、テストが落ちるので気づける。
ただ、前述のように当たり判定矩形には問題があったのだが、このテストではそれが見つけられずにパスしてしまっていた。複雑なゲームエンジンの動作をheadless環境で完全に再現することは難しく、どうしてもスクリーンショットや人間でのプレイによる検証が必要となる。
この開発環境の作り方
headless版Godotが動く環境にしておけば、どのコーディングエージェントに頼んでもたぶん簡単に開発環境を整備してくれると思う。この記事をヒントに与えても良いだろう。
Webエクスポートする場合は、Export Templatesの準備も必要なことに注意。WSL環境だと、ブラウザ上でゲーム動作を確認するほうが、環境設定が楽な場合も多いだろう。
ヘッドレスGodot + CLIエージェントは良い選択肢
ちなみに私はGodotを触ったことは一回もなく、GDScriptを書いたこともない。なので今回は完全なるバイブコーディングでのゲーム開発である。それでもGodot上で動くゲームは作れたし、その後の効果音を足してとか、それっぽいタイトル画面を作ってとか、追加のお願いもうまく反映された。
ゲームエンジンの備える強力な機能群を、それに対する知識がなくてもうまく使えるという面では、このような開発環境は非常に良さそうだ。怖いのは、エージェントが太刀打ちできない欠陥をゲームが抱えた時で、その時に私のGodot知識がゼロのままだと、詰みである。
より高度なゲームを制作しようとした時、そしてなんらかの壁にぶつかった時、そこからリカバリーする手段があるか。もしそこがうまく乗り越えられるのであれば、ヘッドレスGodot + CLIエージェントは、AI時代の有効なゲーム開発環境になりそうである。
追記：ヘッドレスGodot向けのエージェントSkillを作った
いくら.tscnファイルがテキストファイルであると言っても、それをエージェントが直接編集すると壊れてしまう可能性はある。.tscn を直接編集せず、JSONパッチを godot --headless --script で適用して Godot API 経由で更新すれば、エージェントはより安全にシーンを編集できる。そのようなテクニックをマークダウンファイルとして記述し、エージェントSkillとしてつかえるようにした。Godot 4.2+（Web出力するならExport Templates）が入っていれば、以下のリポジトリの .agents/ をプロジェクトにコピーするだけで利用できる。
