確かにいい指摘だね。まだ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が自分が何を生産しているかを見る手段がないこと。コードは正常にコンパイルされるけど、アセットは浮いてるし、道はどこにも繋がってないし、レイアウトはゴミみたい。実際にそう言ってたよね。Godogenはそのループを閉じるんだ。コードを書いた後、実行中のエンジンからスクリーンショットをキャプチャして、ビジョンモデルがそれを評価する。これが「コンパイルはするけど壊れてる」と「実際にプレイ可能」の違いだよ。そして、デザインドキュメントを提供することはすごく助けになる。パイプラインはそれを自動生成するけど（ビジュアルリファレンス、アーキテクチャ、タスクプラン）、自分のものを提供して、ビジョンに合わせてスキルをカスタマイズすることもできる。

「情熱を持ってゲームを作るという失われたアートを悼むために、1分間の黙祷を捧げましょう。まだ…私たちは数十人残っています！」

これだね。僕はAIの助けなしでGodotでゲームを作ってる。楽しんでるからね。変なコーディングの問題を解決するのが楽しいし、直しながら学ぶのも楽しい。競争が激しい今の状況を知りつつ、プロセスへの愛からやってるんだ。市場が溢れるのは分かってるけど、それでもいい。だって、他の選択肢は辞めることだもん。

コーディングは死んでないよ。誰も君たちを止めようとはしてないし、そんなつもりもない。最近、OpenClawの発明者が言ってた編み物のアナロジーが好きだな。プログラミングは趣味としては続くけど、職業としては続かないだろうね。

個人的には、プロトタイピングに費やす時間のほとんどが、ツールやエンジン、アセットと格闘するのに取られちゃう。で、気づくと自分のゲームデザインがあんまり楽しくない。LLMを使ってプロトタイプを早く作る実験をしてるのは、ゲームデザインや感触を調整する時間をもっと増やしたいから。ゲームが楽しくないなら、解決する問題は無意味だからね。

キュレーションが今後数年の王者になると思う。ゲームが存在するだけでは、努力が注がれた保証もないし、開発者が実際にプレイしたかどうかも分からない。ゲームをマーケティングするためには、パブリッシャーやジャーナリストを見つける必要があるよ。友達に何をプレイしてるか聞くようになるだろうし、ストアページをスクロールする代わりにね。信頼できるプラットフォームは、実際に見る価値のあるゲームをプロモートするだろう。この問題はSteamのような現代のプラットフォームでもすでに存在してるけど、AIがそれを加速させてる。

みんなシュベルウェアは見たことあるけど、今度はエクスカベーターウェアが登場。1つのシュベルウェアスタジオが、月にキログラム単位のゲームを届けられるようになったんだ。

どうかな？代わりにフラッシュやゲームメーカーみたいなものが見られると思う。エージェントが簡単に作れる新しいアートスタイルや、子供たちが面白いと思うものが出てくるんじゃないかな。ゲームはクオリティに対する即時フィードバックループがあるから、楽しいか楽しくないかがすぐに分かるよね。

AIツールは素晴らしいけど、最終的にはセンスや意図（ゲームの場合は楽しさ）が重要で、それが質の高いものに繋がるといいなと思ってる。

CD-ROMが登場した瞬間、シャベルウェアが急増したよね。

もしかしたらRobloxゲームを生成できるかも。次のスキビディみたいに一つがヒットすれば、ドカッとお金が入るかもね。

そうそう、100個くらいのストックゲームテンプレートを作って、モデルに必要に応じて設定・修正させればいいんじゃない？ほとんどの使い方に対応できるよ。

これが小規模なプロジェクトでのシングルプロンプト生成だって考えると、そんなに得意げにはなれないよね。Two Minute Paperがいつも言ってるように、今の見た目だけじゃなくて、次の3つのブレイクスルーがあったときにどうなるかが大事なんだ。さらなるブレイクスルーを保証することはできないけど、進歩のスピードを考えると、もう一つもブレイクスルーがないと賭けるのは勇気がいるよ。

スタイルやコンセプトを探してるときのプロトタイピングにはどう？ 何が響くかを見たいだけなら、これ結構役立ちそうだよね。

自分が幸せになることをやればいいと思うよ。こういう人のことは気にしないで。