GodotとLLMを利用して、JRPGを作る

2026-08-09 · Views 14 · Updated 2026-08-09

ゲームエンジンGodotをLLMを使って活用し、ゲームを作る

きっかけ

ゲーム作成界隈のSNS投稿を見てみると、LLMを活用してゲームを作成し、手早くプロトタイプを作ろう、という試みを目にすることがある。

ABA GamesさんのGodotを利用して、LLMにGodotのCLI(headless)モードを活用させ、ゲームをビルド・gdファイルを作成させる手法が国内だと有名じゃないかな、と思う。

GodotはAIコーディングエージェントでのゲーム開発に向いている というABA Gamesさんの記事を目にした人もいるんじゃないだろうか。

この記事を見て、GodotのCLI(headless)を使ってゲームを試作すると楽しいだろうな、と考えるようになった。

Opus 5を利用し、ゲームを作ってみる

Claude Opus 5を使って、ゲームの作成をさせてみることにした。 新しいアイディアを持ち込むことはやめて、自分が知っているゲームに似た構成を作らせてみる。題材はJRPGとした。

出来上がったもの

出来上がったものは、itchにてプレイをすることが可能。ブラウザ上で動作するよう成果物を出した。リンク先でプレイが可能になっている。

https://skingold.itch.io/ryuouquest

ゲームシステムはJRPGの王道、ドラゴンクエストを模したもの。システムとしてはマップをキャラクターが歩き、敵とエンカウントする。シナリオとしては、りゅうおうが大陸の外からやってきてからモンスターが出るようになってしまったので、りゅうおうを倒さないといけない、というもの。

LLMに相談しながら、レベルデザインやマップ配置をし、進めていった。

初期に出来上がったもの

Opus 5に長期間タスクを走らせて、作らせてみた。 大枠はできており、ゲームをプレイすることはできた。 マップを歩かせて、敵と遭遇し、戦って倒すことでゴールドが得られる。基本的なことはできている。セーブ機能やRTA機能も作成してもらった。

03-save-ask

04-field

14-battle-field

16-battle-dragon

最終形態

敵のデザインやマップタイル、効果音やBGMなどを入れ、シナリオも調整して整えてみた。りゅうおうを倒すことで今いる世界は救われる、という目的を持たせてプレイヤーに何をすればいいのか、を明示する作り方はできた。 ゲームとしては小型ではあるが、完成したものとなった。ここまで作り上げるのにかかった時間は1週間弱である。

04-field

14-battle-field

16-battle-dragon

LLMだけでは解決できないもの

LLMだけに任せても、ゲームとして遊べるもの・閉じたものとして終わりが見えるもの、かつ解決可能なものにしなければならず、その点は全部任せるのは難しかった。

特に以下5点が気になったところ。

  • レベルデザイン
  • クリエイティブ
  • 目標を達成することに納得がいくシナリオ
  • 全体的なデバッグ
  • PRをレビューするシステムと噛み合わせが悪い
  • ビルドの課題

レベルデザイン

レベルデザインはなかなか難しい。自分はこの分野、全くの素人であるから言葉しかわからない状況ではあるが、敵を倒してもなかなか武器が買える状況にならなかったり、一番強い武器を買える頃にはさらに強く、硬い敵と戦うことになりゲームオーバーになって詰んでしまう、という全体を見通した設計ができていなかった。細かいタスク単位でゲームを作るから、全体を見通してパラメータや状態遷移・プレイヤーができることを考慮したデザインになっていなかったので、そこはLLMと対話しながら進めた。

LLMと対話の結果、ナレッジをMarkdownファイルに出力をして他のセッションでも利用可能な状態にLLMはしてくれる。大量の分析をしてくれたので、後々活用できるだろう。スクショは、なんでクリアできないのか?を分析していたMarkdownファイルの一部

image

レベルデザインについては、ゲームのボリューム・シナリオの展開、仕組みによって全然違うので使い回しは全てはできないかもしれないが、応用は効くだろう。レベルデザインの調整はかなり時間がかかった。

クリエイティブ

敵のデザイン・効果音・BGMはLLMで生成はできないので、外部のサービス・配布されているアセットを使わせていただいた。

敵のデザイン

Pixellabというサービスを使って、敵のデザインを作成した。ほしいイメージをプロンプトとして渡して生成すれば、希望のピクセル化したクリエイティブが得られる。自分は、Claudeを使い、PixellabのMCPを経由して生成した。APIの場合、大量に生成するなどリクエストを送る際は従量課金となるが、よほど大量に作成しなければ$5もかからないのではないだろうか。

wolfbatknightmagicrock

効果音

itch.ioで配布していただいている方の効果音を使わせていただいた

https://coffeevalenbat.itch.io/sweet-sounds-sfx-pack

BGM

PyxelComposerを利用させていただいた。BGMのテーマ・テンポを設定して、wavファイルとしてエクスポートをすることができる。

フォント

PixelMplusを利用させていただいた。

地形

地形はこちらを利用させていただいた。

https://hollyhart1.itch.io/my-8-bit-jrpg-tilesets

目標を達成することに納得がいくシナリオ

LLMに対して、JRPGを作るように依頼し成果物を作成することから入ったため、着手後出来上がったゲームは、システムはある程度完成された状態ではあるが目的は定まっていなかった。

城を起点として、洞窟でアイテムを手に入れ、ラスボスに挑戦する、そのような流れになるように相談をし、シナリオに肉付けしていくことにした。

LLMに相談しながらゲームを作成するには、プロンプトを渡して、成果物となるゲームという出力を操作する作業となる。最初からシナリオを固めて渡せば良いかというとゲームのシステムが固まってなければ作ることはできないので、この辺りは悩ましい。

全体的なデバッグ

レベルデザインをはじめ、通しでゲームをプレイすることでわかるゲーム進行の矛盾、難しさをチェックしてみたところ、レベルを上げても全然敵を倒せない、お金を得て武器を得てもその武器で敵は倒せない、全体的に弱くなると難しい、主人公の成長曲線と敵の配置などやればやるほど課題が見つかった。

デバッグをやることによって発見した矛盾・ゲームの改善方法についてはLLMと相談を続けていく中で、ナレッジとしてMarkdownに書き出して使えるようにした。また、デバッグをしやすいようGDScriptを使ってゲーム状態を操作し、戦闘・ダンジョン攻略・会話・ゲーム画面の破綻の調査をしてもらうようLLMと相談しながら作成した。

ゲームサイズが膨らみ、できることが多くなる・分岐が多くなるとデバッグは総じて大掛かりなものとなることが簡単に予想ができるので、ここはLLMによってゲーム作成を軽量化したとしても課題となり続けるのだろう、と感じる。ツールを作りやすくしたり、デバッグモードを改良するなど定型のタスクに切り出せば、デバッグに対して歯が立つ成果物を作成できるが、何が問題で、どう解決するのか?という問題定義は人間が用意しないとうまくいかない。

PRをレビューするシステムと噛み合わせが悪い

GodotのコードはGitHubを利用して管理をしている。コードの管理を行うだけではなく、品質管理もできたら良いと考え、PR Agentを利用しLLMがコードレビューをする環境を整え、レビューするようにしてみた。

しかし、今回は活用できる機会は少なかった。ゲーム本体に対してのコードレビューをさせると巨大であるので、ツール単位で細かくレビューさせられるようにした方が良かったかもしれない。

PR Agentについて少し説明すると、GitHub Actionsという仕組みで、GitHub上に保存されているリポジトリの成果物をLLMに解釈させ、出力としてレビュー結果を得られる仕組みを構築できるOSSプロダクト。私はPR AgentにOpenrouterというサービスを使って、Deepseek v4 Flashを使わせてレビューをさせた。

Opus 5やFable 5、またはKimi K3など高機能・高価格なModelを指定すれば、もうちょっと違うレビュー結果が得られたのかもしれない。ここは生産性に関わりそうなので今後も注力してみたいところだ。

ビルドの課題

開発終了後、ゲームを実際に遊べる形にするためにパッケージに変えなければならない。書き出しに関して考慮した形で開発に入らなかったため、必要なアセットが読み出せない・音楽が出ない、フォントが豆腐になるなどいろいろな問題が出てきた。

パッケージとして動作させるようにするためのビルド周りについては、LLMと相談しつつパッケージ化できるようにするスクリプトを作成、アセットの不足も確認できるようにシステムを組んだ。

書き出しは Godot の import を通すため、import を避けて直接ファイルを読む作りにしていたことが裏目に出た。しかも素材が無いときの代替表示を用意してあったため、アセットが全部落ちた状態でも普通に起動して遊べてしまったが、最終的な成果物生成ではうまくいかない場面もある。

今回の感想

今作成したJRPGのプロダクトは、成果物+LLMに渡すための今後のナレッジとして利用をする。様々なゲームを作成するが、共通して利用できるシステム・ナレッジはあるはず。

LLMを利用したゲーム制作については、クリエイティブから何から全てを作成させるのは難しく、実験としては面白いが遊べるものを作るとしてもうまくはいかなそう。将来ゲームシナリオを外部から評価したり、実際にプレイをして評価をするサービス・ツールが出るかもしれないが、感性や納得まで揃わないとだし、しかしそこまでやったら果たして何がおもしろいところにつながるのだろう?とは思ってしまう。

LLMを利用して成果物を求める・プロダクトを作成するものに共通する悩み・課題があるという認識で、成果物の品質やアウトプットそのものを測るためには自分自身が課題や目標を認識できている必要がある、というもの。ゲームに限らずさまざまなLLMを用いたプロダクトに共通していると言えるが、ここは今後のLLM関連のツール改善に期待を寄せれば良いだろうか。

今後

ここ1年ぐらいのLLMのModelそのものの進化、計算資源を有効に使うための工夫、例えばMoEなど。技術面での進化が早い。また、中国で現在盛んに出されている比較的性能の高いオープンウェイトモデルの登場でコストを抑えめに、長い時間大量にトークンを使える環境が整うなど、コスト面の問題も課題は抱えつつあるが、安いモデルが定期的に出ており競争環境が維持されているので今後を見据えるとそこそこの安さで非常に賢いModelを利用できるようになるのではないだろうか。

何かしらツールを使って、自分で組み上げるのも楽しいんだけど、さまざまな技術が更新される昨今、うまい具合に成果物を作って楽しめる環境が整ってきているので、こういうものは試していきたい。

この記事は AI を補助として利用して書かれました (AI Agent / アシスタントツールなど)