ハクソク

世界を動かす技術を、日本語で。

Show HN: 完全なGodotゲームを構築するClaudeのコーディングスキル

45日前原文(github.com)

概要

Godogenは、テキストプロンプトからGodot 4ゲームプロジェクトを自動生成するAIパイプライン。
2D/3D対応、資産生成・コード記述・ビジュアルQAまで一貫自動化。
Claude CodeとGeminiなど複数AIの協調動作で工程を分担。
GDScript特有の課題を独自リファレンスで解決。
誰でもPC一台で動作可能、オープンソースで公開。

Godogen：AIによるGodot 4ゲーム自動生成パイプライン

  • テキストプロンプトを入力するだけで、AIがゲームの設計・アート生成・コード記述・動作確認まで自動実行
  • Claude Codeによる2段階AIスキル構成
    • オーケストレーター：全体設計と工程分割
    • エグゼキューター：各タスクを個別コンテキストで実行
  • Godot 4対応：2D/3D両対応、正規のシーンツリー・スクリプト・アセット構成
  • 資産生成：Geminiで2Dアート・テクスチャ生成、Tripo3Dで画像から3Dモデル変換
  • コスト最適化：予算内で最大のビジュアルインパクトを実現
  • GDScript対応：独自リファレンス・APIドキュメント・クイックDBでLLMの知識不足をカバー
  • ビジュアルQA：Gemini Flash visionが実際のゲーム画面を解析し、z-fightingや物理バグなどを検出
  • 汎用PCで動作：GodotとClaude Codeが動く環境ならOK

導入方法・前提条件

  • Godot 4（headlessまたはeditor）をPATHに追加
  • Claude Codeのインストール
  • APIキーの環境変数設定
    • GOOGLE_API_KEY：Gemini用（画像生成・QA）
    • TRIPO3D_API_KEY：Tripo3D用（3Dモデル変換、3Dゲームのみ）
  • Python 3とpipインストール（アセットツールが依存関係を自動導入）
  • Ubuntu/Debianで動作確認済み、macOSは未検証（X11/xvfb/Vulkan依存）

ゲームプロジェクト作成手順

  • このリポジトリはスキル開発用ソース
  • 新規プロジェクト作成はpublish.shを実行
    • 例：./publish.sh ~/my-game
  • .claude/skills/とCLAUDE.mdが生成され、gitリポジトリ初期化
  • Claude Codeを起動し、作りたいゲーム内容を指示
  • /godogenスキルが全工程を自動実行

VM・クラウドでの運用

  • 1回の生成に数時間かかる場合あり
  • クラウドVM（GCE T4/L4 GPU等）ならローカルPCを占有せず運用可能
  • デフォルトCLAUDE.mdはTeleforge（Telegramブリッジ対応）設定済み
  • Teleforge不要ならカスタムCLAUDE.mdをpublish.shで指定、または生成後に編集

Claude Code以外の選択肢

  • 他の環境でもスキルテスト済み
  • Claude Code Opus 4.6が最良、Sonnet 4.6は追加指示が必要
  • OpenCodeも移植容易でおすすめ

ロードマップ

  • 画像生成をgrok-imagine-imageへ移行（コスト削減）

  • スプライトシートをgrok-imagine-videoへ移行（動画からアニメスプライト生成）

  • ゲームビルド用レシピ追加（Androidエクスポート対応）

  • 完全なエンドツーエンド公開デモの制作

    • 進捗は @alex_erm で公開

技術的な課題と解決策

  • LLMのGDScript知識不足
    • 850以上のGodotクラスを網羅した独自言語リファレンス/クイックDB/APIドキュメントを構築
    • 必要なAPIのみlazy-loadで参照し、コンテキストウィンドウ圧迫を回避
  • ビルド時とランタイムの状態差異
    • シーンはヘッドレススクリプトでノードグラフを生成し、.tscnファイルへシリアライズ
    • @onreadyやシグナル接続など、ビルド時に利用不可なAPIの扱いをAIに学習させる
    • 各ノードのowner設定ミスによる消失もプロンプトで防止
  • 評価ループのバイアス排除
    • コード生成AIとは別に、Gemini Flashがレンダリング画像のみでビジュアルQAを実施
    • テキスト分析で見逃すバグ（z-fighting、物理爆発、グリッド配置ミス等）を画像解析で検出
  • アーキテクチャ
    • 2つのClaude Codeスキル（プランナー/エグゼキューター）がcontext: forkで状態管理
    • 各タスク独立実行でエラーや状態の累積を防止

オープンソース・デモ・情報発信

まとめ

  • Godogenはテキスト指示だけでGodot 4ゲームを一貫自動生成するAIパイプライン
  • GDScript特有の課題を独自技術で克服
  • 2D/3D両対応・資産生成・ビジュアルQAまで自動化
  • 誰でも導入可能・オープンソースで積極開発中

Hackerたちの意見

いい仕事だけど、GDScriptの代わりにC#を使ったらどう？LLMはC#に強いし、tscnファイルも得意みたいだから、「LLMはGDScriptが苦手」って問題が解決するよ。それに、C#はトークンの使用量が安くなることもあるし（追加のAPIを読み込まなくて済むから）、一つのエージェントがインターフェースを書いて、別のエージェントが詳細を埋める感じで進められる。C#でGodotのゲームを作るのがすごく楽しかったから言ってるんだけど、GDScriptでの作業は本当に辛かった。
└
確かにいい指摘だね。まだC#は試してないから、このコメントの後にやってみるつもり。元々の理由としては、GDScriptがGodotのデフォルトの道で、ほとんどのドキュメントやコミュニティの例がそれを使ってるし、エンジンとの統合も密接だから。C#にはまだいくつかのギャップがあるけど（ウェブエクスポートがないとか、GDExtensionのバインディングがないとか）。でも、LLMの観点から見ると、C#は根本的な問題をひっくり返すよね。強力なトレーニングデータ、静的型付けでコンパイラのフィードバックが良くなるし、クリーンなアーキテクチャのためのインターフェースもある。カスタム言語仕様を読み込まないことで、コンテキストウィンドウの節約もかなり大きいかも。試したいのは、ヘッドレスシーンビルディングがC#でもスムーズに動くかどうか。これを実験してみるつもり。
└
現在、C#でのウェブ出力は機能してないと思う。間違ってたら嬉しいけど。
└
GPT5.4で書かれたC#エディタースクリプトを使って、ユニティをヘッドレスで自動化してるんだけど、その能力は素晴らしいよ。GUIができることはほぼ全部できて、スクリプトも初回で約80%の確率で正しく作成できる。十分なリトライと標準出力からのフィードバックがあれば、失敗するところは見たことがないよ。
└
Claude Codeを使って人間がループに入った形でゲームを作っている者として、OPが「LLMはGDScriptをほとんど知らない」と言っているのは、私の現在の経験とは全然合わないな。あなたの経験には合っていたみたいだけど。以前はそうだったのかもしれないけど、あなたの「vibecode」試みはいつのことだったの？Opus 4.5、4.6、Sonnet 4.6からは、問題なくGDScriptが得られたし、プレースホルダー品質のTSCNファイルも十分に機能するものが得られたよ。特別なトリックは使ってなくて、ただCLAUDE.mdファイルとプロジェクト自体、変更の前にプランモードを通るだけ。ある程度手書きの足場が整ったプレイ可能なプロジェクトから始めたけど、それが違いを生むかは分からないな。たまにGodot 4の代わりにGodot 3に適したものが得られることがあるけど、言語の類似性にもかかわらずPythonは一度も出てこなかったよ。
デモ動画見たけど、正直言って、すごく無機質に感じた。スノーボードのやつが一番気になったけど、キャラクターの動きやメカニクスがすごく悪い物理に見えた。これらのデモじゃなくて、試せる公開ゲームはないの？気になるんだけど。
└
確かに、その通りだね。これらのデモは基本的に生の単発出力で、選りすぐりや磨き上げたものじゃないから。目的はパイプラインがエンドツーエンドで機能することを示すことで、完成したゲームを作ることじゃなかったんだ。もっと反復を重ねたちゃんとしたフルゲームを作って、プレイ可能なビルドとして公開するつもりだよ。そうすれば、実際のクオリティの上限がもっとよくわかるはず。
└
このデモは、ワンショットプロンプトから期待していたものよりも遥かに良いよ。私たちの期待がどう変わったかも興味深いね。
└
これがある意味では素晴らしいんだけど、商業ゲームを求めるマネージャーがこういうのを開発チームに押し付けて「もっと早くしろ」って言うのが問題だね。プロフェッショナルな仕上げをプロンプトで得るのは、特にコードが何をするのか分からない状態で、かなり大変な経験になるだろうな。
└
スキルのポイントは、エンドゲームが良いことじゃなくて、クラウドがGodotエンジンのどの部分でも作業できることだと思う。LLMには物理のスキルが必要だと思うけどね。物理関連のコードを書くのが一貫して苦手だから。たくさんのプロンプトとフィードバックがないと、うまくいかないことが多いよ。
└
> ... でもキャラクターの動きやメカニクスが、すごく悪い物理法則に見えるんだよね。それに、バイブコードされたアプリが、ここでのゲームと実際のゲームの関係みたいなものであることに気づくと、ちょっと不安になるよ。まあ、結局は自分のClaude Code CLIに戻るけど、クソみたいなコードが大量に生成されてるのは分かってる。
背景として、私は日常の仕事や個人プロジェクトでエージェント（Claude CodeとCodexの両方）を使ってるけど、いつも自分がある程度知識のある分野で使ってて、今は満足してる。Claude Codeを使ってGodotとGDScriptでRPGゲームを作ろうとしたけど、無料で使えるアセットを使ったら、完全に失敗した :/ ゲームは多くの実装ステップが必要だったけど、最初に一つのエリアのデモを作るようにClaudeに頼んだんだ。そうすればアセットをテストして、気に入ったものを選べるからね。最初はアセットをランダムに使ってゴミみたいなものを作った。次に既存のデモをコピーしようとしたけど、ドアや道がどこにあるか全然わからなくて、ある時点では「使えるエリアをデザインできない。機能的だけど見た目が悪いものを作るか、既存のデモをコピーして適応するけど、何が何だかわからなくなる」って言ってた。ゲームを開発したことなんて一度もないから、基本的な概念すら知らないけど、この使い方は私には全然合わなかったかも。フルデザインを提供すれば、ゲームのコードを生成できるかもしれないけど。
└
まさにこのプロジェクトが解決しようとしている失敗のパターンだね。根本的な問題は、Claude Codeが自分が何を生産しているかを見る手段がないこと。コードは正常にコンパイルされるけど、アセットは浮いてるし、道はどこにも繋がってないし、レイアウトはゴミみたい。実際にそう言ってたよね。Godogenはそのループを閉じるんだ。コードを書いた後、実行中のエンジンからスクリーンショットをキャプチャして、ビジョンモデルがそれを評価する。これが「コンパイルはするけど壊れてる」と「実際にプレイ可能」の違いだよ。そして、デザインドキュメントを提供することはすごく助けになる。パイプラインはそれを自動生成するけど（ビジュアルリファレンス、アーキテクチャ、タスクプラン）、自分のものを提供して、ビジョンに合わせてスキルをカスタマイズすることもできる。
情熱を持ってゲームを作るという失われたアートを悼むために、一分間の黙祷を。ゲームがあれますように！そして、生成されたゲームが何百万もあれますように。80年代に戻れないかな？
└
>「情熱を持ってゲームを作るという失われたアートを悼むために、1分間の黙祷を捧げましょう。まだ…私たちは数十人残っています！」
└
これだね。僕はAIの助けなしでGodotでゲームを作ってる。楽しんでるからね。変なコーディングの問題を解決するのが楽しいし、直しながら学ぶのも楽しい。競争が激しい今の状況を知りつつ、プロセスへの愛からやってるんだ。市場が溢れるのは分かってるけど、それでもいい。だって、他の選択肢は辞めることだもん。
└
コーディングは死んでないよ。誰も君たちを止めようとはしてないし、そんなつもりもない。最近、OpenClawの発明者が言ってた編み物のアナロジーが好きだな。プログラミングは趣味としては続くけど、職業としては続かないだろうね。
└
個人的には、プロトタイピングに費やす時間のほとんどが、ツールやエンジン、アセットと格闘するのに取られちゃう。で、気づくと自分のゲームデザインがあんまり楽しくない。LLMを使ってプロトタイプを早く作る実験をしてるのは、ゲームデザインや感触を調整する時間をもっと増やしたいから。ゲームが楽しくないなら、解決する問題は無意味だからね。
└
キュレーションが今後数年の王者になると思う。ゲームが存在するだけでは、努力が注がれた保証もないし、開発者が実際にプレイしたかどうかも分からない。ゲームをマーケティングするためには、パブリッシャーやジャーナリストを見つける必要があるよ。友達に何をプレイしてるか聞くようになるだろうし、ストアページをスクロールする代わりにね。信頼できるプラットフォームは、実際に見る価値のあるゲームをプロモートするだろう。この問題はSteamのような現代のプラットフォームでもすでに存在してるけど、AIがそれを加速させてる。
└
みんなシュベルウェアは見たことあるけど、今度はエクスカベーターウェアが登場。1つのシュベルウェアスタジオが、月にキログラム単位のゲームを届けられるようになったんだ。
└
どうかな？代わりにフラッシュやゲームメーカーみたいなものが見られると思う。エージェントが簡単に作れる新しいアートスタイルや、子供たちが面白いと思うものが出てくるんじゃないかな。ゲームはクオリティに対する即時フィードバックループがあるから、楽しいか楽しくないかがすぐに分かるよね。
└
AIツールは素晴らしいけど、最終的にはセンスや意図（ゲームの場合は楽しさ）が重要で、それが質の高いものに繋がるといいなと思ってる。
└
CD-ROMが登場した瞬間、シャベルウェアが急増したよね。
└
もしかしたらRobloxゲームを生成できるかも。次のスキビディみたいに一つがヒットすれば、ドカッとお金が入るかもね。
ゲーム開発者です。動画を見たけど、ひどい結果だった。テンプレートから始めた方がいいね。
└
そうそう、100個くらいのストックゲームテンプレートを作って、モデルに必要に応じて設定・修正させればいいんじゃない？ほとんどの使い方に対応できるよ。
└
これが小規模なプロジェクトでのシングルプロンプト生成だって考えると、そんなに得意げにはなれないよね。Two Minute Paperがいつも言ってるように、今の見た目だけじゃなくて、次の3つのブレイクスルーがあったときにどうなるかが大事なんだ。さらなるブレイクスルーを保証することはできないけど、進歩のスピードを考えると、もう一つもブレイクスルーがないと賭けるのは勇気がいるよ。
└
スタイルやコンセプトを探してるときのプロトタイピングにはどう？ 何が響くかを見たいだけなら、これ結構役立ちそうだよね。
HNの人たちにはウケが悪いだろうね。彼らはコードを書いたり理解したりできるから。このツールは、AIについて何も知らないTikTokや非技術者の人たちには素晴らしい。ランダムなアイデアをゲームに変えたい人には最高だね！
このスレッドのソフトウェアエンジニアたちは、ゲーム開発者の本質を誤解してる気がする。ここにいる多くの人は、新しいコーディングの方法を探るためにゲーム開発をしてるんだ。私の妹はインディー開発者で、彼女にとってコードはゲームを作るための避けられない手段なんだよね。多くのゲームは内部がスパゲッティ状態だけど、クリエイターがコードのアートに全然興味がないからなんだ。だから、LLMはクリエイターがもっと自由に実験できる素晴らしいものだと思うよ。ちなみに、私はプラットフォームエンジニアで、プロダクションコードに対する信頼性や配慮が失われていくのを悲しんでる。ゲームはこの問題があまり関係ない分野だと思うんだけどね。
これは、たった一つのまともなゲームすら作れないものに対して、（君が書いてない）たくさんの言葉だね。コードを学び、文章を書き、何かを作る方法を学んで、こんな風にならないようにしよう。
└
自分が幸せになることをやればいいと思うよ。こういう人のことは気にしないで。
いろいろ考えると、これは結構クールだと思う。ワンショットで作られたものに、あまり磨きや魅力を期待するのは非現実的だよね。驚いたのは、ユニットテストが全然ないこと。エージェントはテストを作るのがすごく得意で、GUTテストもかなり発展してるから、いいユニットテストがあれば、コントロールを磨いたり機能を追加したりする後のステップで本当に助けになると思う。これがないと、すぐに脱線しちゃうと思うよ。
ClaudeはGoDotでちゃんと動くよ。作業しているバージョンを明示的に指定しないといけないけど。GoDotで動いてるのはClaudeだけなんだ。