ハクソク

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

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

2026年3月17日原文(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に頼んだんだ。そうすればアセットをテストして、気に入ったものを選べるからね。最初はアセットをランダムに使ってゴミみたいなものを作った。次に既存のデモをコピーしようとしたけど、ドアや道がどこにあるか全然わからなくて、ある時点では「使えるエリアをデザインできない。機能的だけど見た目が悪いものを作るか、既存のデモをコピーして適応するけど、何が何だかわからなくなる」って言ってた。ゲームを開発したことなんて一度もないから、基本的な概念すら知らないけど、この使い方は私には全然合わなかったかも。フルデザインを提供すれば、ゲームのコードを生成できるかもしれないけど。

Hacker Newsで議論の続きを見る