LLMなしでゲームを作ると3か月、LLMと一緒なら3日
(marianogappa.github.io)- 15年のキャリアを持つソフトウェアエンジニアが、子どもの頃のカードゲームをGo言語で開発した経験を共有
- **LLM（大規模言語モデル）**なしで「Truco」を開発した際は、UI設計やサーバーレス配備などあらゆる問題を手作業で解決し、3か月を要した
- 「Escoba」を作る際にはLLMを活用し、バックエンドコードの変換と実装速度を大幅に短縮。1回のプロンプトで大半が動作することに成功
- 記事後半ではTic-Tac-Toeの例とともに、Goバックエンド、WASM変換、React連携を通じて、誰でもゲームを作れる段階別ガイドを提供
- ただし、ReactフロントエンドおよびWASMベースのゲーム状態管理は、依然として自分でデバッグと実装が必要
紹介
- 15年のキャリアを持つソフトウェアエンジニアが、自分は実際にゲームを作って配布したことがないと気づく
- 子どもの頃にアルゼンチンで友人たちと楽しんだカードゲームのひとつを、Go言語で開発することを決意
Truco: LLMなしで3か月
- 2024年6月18日から、TrucoというカードゲームをGoバックエンドで開発開始。Reactは最小限の知識だけでフロントエンドを作成
- UI実装が最大の課題で、サーバーを提供しないためにTinyGoを活用してWASM（WebAssembly）へトランスパイルし、静的ファイルをGitHub Pagesに配備
- LLMがなかったため、あらゆる詳細を自力で調べ、試行錯誤を重ねながら約3か月かけて完成
- 広告や収益化が目的ではなく、純粋にゲームを完成させることが目的で、公開から1年後も継続的に遊ばれている
- Trucoを遊ぶ: https://marianogappa.github.io/truco-argentino
- バックエンド（Golang）: https://github.com/marianogappa/truco
- フロントエンド（React）: https://github.com/marianogappa/truco-argentino
Escoba: LLMと一緒に3日
- 1年後、家族に会うためアルゼンチンを訪れた際、甥に2番目に人気のあるカードゲームEscobaを教える
- 今回は**LLM（Claude）**を活用し、Trucoのバックエンドを複製したあと、Escobaのルールをプロンプトで説明してコードのリファクタリングを依頼
- 最初のプロンプトだけでほぼ完璧に実装され、わずかなバグと追加機能だけを手動で補完
- フロントエンドは数日間、自分で実装・デバッグする必要があった。LLMの限界、Reactのスキル、そしてゲーム状態をWASMで管理する特殊な環境のすべてが課題だった
- Escobaを遊ぶ: https://marianogappa.github.io/escoba-de-15
- バックエンド（Golang）: https://github.com/marianogappa/escoba
- フロントエンド（React）: https://github.com/marianogappa/escoba-de-15
ステップ別: 自分のゲームを作る方法
- 誰かが実際にゲーム開発に挑戦できるよう、最小限の実践ガイドとサンプルコードを紹介
- Tic-Tac-Toeのサンプルリポジトリを提供しており、これをforkして始められる
バックエンド開発
- ターン制ゲームのバックエンドは、機能を明確に設計しやすい
- サーバーレス構成を維持し、商用サーバーがないなら人間同士が対戦する構造は避けるのが現実的な選択
フロントエンド開発
- フロントエンドでは次のような作業が必要
- バックエンドに新しい
GameStateの作成を要求 - UIで状態を表示
- 有効な行動を選択するインターフェースを提供
- 行動を適用する際にバックエンドへコマンドを送信
- ボットの手番ならバックエンドに要求
- バックエンドに新しい
バックエンドのWASM化
- GoコードをWASMとしてビルドするには
GOARCH=wasm GOOS=js go buildを使用 - バイナリサイズが大きくなる問題があるため、TinyGoを使ってサイズを削減
- フロントエンドと接続する関数をエクスポートするため、Goで別のエントリーポイント（例:
main_wasm.go）を書き、ビルド時に分岐処理 - メイン関数で
select {}によりブロックし、プログラムが即座に終了しないようにする必要がある
バックエンド-フロントエンドのデータ連携
- Goの自由形式structである
GameStateなどは、WASMでは直接serialize/deserializeできない - すべてのデータはJSON形式で交換する方式が必要
- TinyGoのドキュメントを参照し、入力・出力の両方をJSONシリアライズでやり取り
フロントエンド-バックエンドのインターフェース
- フロントエンドではbackend関数を直接呼び出す
GameStateはWASM内でのみ管理され、フロントエンドからはミューテーションできず、常にbackendが唯一の正しい情報源- WASMを再コンパイルした後はファイルの差し替えが必要で、Makefileによる自動化例も提供
WASM実行環境
- 実行には
wasm_exec.jsをheadに含める必要があり、そのスクリプトを使ってインスタンスを生成して実行する
結論
- ゲーム制作は楽しい体験であり、GoとWASM、Reactの組み合わせは誰でも試せるアプローチ
- LLMの助けで生産性は大きく向上したが、フロントエンドの力量とデバッグ経験は依然として重要
- 誰でもこの構成で自分自身のゲーム開発に挑戦できるので、ぜひ試してみてほしい
4件のコメント
Reactで
document.getElementByIdを使ったコードが生成されたのだとしたら、どのLLMを使ったんでしょうか……ほとんどタイトル釣りの煽りみたいに感じる…。
「最初から作れば3か月、似たものをまた作るなら3日」
元の著者は、自分が普段何をしているのか人に知られていない人なんでしょうね。
Hacker Newsの意見
この投稿で良いと思った点は、多くの開発者が見落としがちな事実を指摘していること。ゲーム開発でコーディングそのものがボトルネックだったことはあまりない。一人開発でもAIなしでメカニクスは素早く作れる。本当に難しいのは、その上にある目に見えない複数のレイヤー、たとえばゲームループのバランス調整、難易度チューニング、違和感のないアセット制作、ユーザーの関心を5分以上保てるだけの磨き込みなど。だからLLM以降もSteamに傑出したゲームが溢れていない理由もここにある。技術は一つの障壁を下げたが、もっと大きな障壁はそのまま残っている。2010年代にUnityが登場した時も同じだった。エンジンはゲーム開発を民主化したが、優れたゲームが爆発的に増えたのではなく、試みの数が増えただけだった。LLMはコードに、画像モデルはアートに同じ現象を起こしているが、どのゲームが本当に面白いかはそれらのツールではわからない。自分にとって興味深い問いは、AIが実装だけでなくプレイテストまで行うようになったら何が起きるのか、ということ。つまり何千回もループを回し、どのメカニクスがシミュレーションされたプレイヤーを引き留め続けるのかを教えてくれる段階まで進めば、生産性ハックを超えてデザインパートナーにまで役割が広がるはず。まだその段階ではないが、この文章はその方向へ向かう初期のデータポイントのように感じる
AIが単なる実装だけでなくプレイテストまで行い、何千回ものループを回してプレイヤーをどれだけ没入させるか把握できるようになったらどんな未来が来るのか、という意見について、AIがどうやってプレイヤーをシミュレートできるのか、そしてなぜ現実の人間が何に没入するかを適切に判断できるのかが気になる
Unityが2010年代に台頭した例で、本当に良いゲームの数はそれほど多くなかったという点には反論したい。実際、XBLA時代と比べれば、いま私たちが持っている膨大なゲームの量は、Unity、Godot、Gamemaker、Renpy、RPG Makerのようなツールなしでは不可能だったはず。つまり質だけでなく量の面でも、明らかに飛躍的な成長はあった
自分にとって生成AIのリトマス試験紙は、2Dピクセルアートのアクションゲーム向けスプライトシート一式を作れるかどうか。たとえば戦車や主人公の動きだけでも完璧に出せることを目標にしていたが、いまだに成功例を見たことがない
「AIはあなたのゲームが実際に面白いかどうかを教えてくれない」という指摘こそが核心的な洞察だと思う。AIは人間が実際にゲームを体験するのと同じレベルでも、あるいは他のどんな体験でも、人間のように経験することはできない。似たゲームに対する人間の評価データを見て、ある程度予測できるだけだ。つまりAIはあなたのゲームを楽しめない。この本質が、これからのAI時代における人材の役割を定義していくことになるはず。AIは書類やコードのようなものを過去データにもとづいてある程度人間らしく書けるが、本当に人間だけが成しうる意味のある統合や経験があることを示している。人間ならではの価値には代替できない地点があり、ただその価値をどう捉えるかを違う形で考える必要がある
このパターンはゲーム開発以外の分野にも当てはまる。誰もが期待するように、エージェントベースのコーディングには大きな可能性があるが、一部のタスク（高速なWebアプリのデモ、小規模ライブラリの接続など）だけが圧倒的に速く解決され、実際の大規模ソフトウェアにはまだ十分適用できていない。モデルの学習のされ方も、私たちの活用ノウハウも、まだ不足している。こうした状況は驚くことではない。gitも登場から5年間はエリート企業だけがきちんと導入し、一般化するまでさらに5年かかった。いまではかなり馴染んでいるが、LLMはgitよりむしろ正しく使うのが難しいと思う。もし各製品やOSS、ブログ記事ごとに「もう終わった、すべてが革新された」といった誇張が少しでも少なければ、もっと早く発展していたのではないかと思う。私たちはまだ試行錯誤と実験の最中にいて、時間がかかる。あまりに早く判断すべきではない。もし本当にすべてが解決済みの段階なら、少なくともはるかに優れたソフトウェアに埋もれているはずだが、まだかろうじて均衡を取っている程度だ。これでも新技術の登場から1〜2年で見るならかなり印象的な成果だ
LLMが3か月分の先行を持っていたのは、コード、以前のゲームをテンプレートとして使ったこと、そして何より手でコーディングしていたときに積み上げたあらゆる経験と失敗が土台にあったからだ
最初は刺激的なタイトルかと思ったが、実際には「Trucoのバックエンドを複製して、ClaudeにEscobaのルールを長く説明したうえでコードをリファクタリングさせた」という部分に驚きがあった。人が直接リファクタリングしたらどれくらいかかるのか気になる。3日以上かかりそうでもあり、そうでもない気もする
もう一つ、このゲームが参加者にとって最初のゲームだった点は重要だ。つまり初挑戦では大量の未知の変数を相手にしなければならないが、すでに一度経験して得たインサイトやノウハウを持ってやり直すなら、LLMなしでも3か月よりずっと短い時間で作れるはず
実際、同じプロジェクトを2回、3回と繰り返すと、最初は数か月かかったことでも次は3分の1くらいに縮むのを自分でも経験している
<i>ごほん</i> 24時間以内に開発したこともある。nordicgamejam.com に例がある。LLMもGenAIもなく、Unityすらなかった時代にはMicrosoft XNAとC#が最善だったことを言っておきたい。アートもほとんどはペイントで描いた手描きレベルだった。それでも毎年十分に楽しいゲームが生まれていたし、Baba is YouやBraidのように広く知られるものもあった。コーディングはボトルネックではなく、個人的にはメンバー間のコミュニケーションこそが本当の bottleneck だと確信している
このコメントの流れを見ると、ゲーム開発経験のない書き込みが多いように見える。実際、LLMが使われているプロジェクトは、すでにトレーニングデータに大量に存在するタイプだ。たとえばプログラミング入門の授業で扱うプロジェクトでもあるし、南ヨーロッパ諸国にはこのブログで言うカードゲームに似たゲームが本当にたくさんある。自分も大学1年のとき、何の経験もなくMoon PatrolをPythonでゼロから実装したが、2〜3か月、週3日徹夜でコーディングした。カードゲームを作るのはそれよりむしろ簡単だ。LLMに明確に有用な部分はあるが、こうした簡単な例はLLMのコーディング生産性や有用性をベンチマークするには適していない
LLMで数日おきに少しずつ見ながら、こんな作業をしていた: stacky 。実働としてはだいたい2日ほど。最初はグラウンドアップ開発で、その後はブラウンフィールド的に書き進めたが、そこまで本気で完成させるつもりはなかった。ところが細部や機能をどんどん追加するうちに、アイデアが増えていった（スーパー・ローテーション、DASなど）。まだゲーム全体の10〜20%程度で未完成。WebGL版も動く。でもあまりに究極のテトリスを目指すと訴えられそうだし、そのライセンス料も払えないので止めた。結局得られたのは自信と経験だ。最近HNでパラメトリック関数に関するリンクを見て、1〜2時間でプレイグラウンドの graphy も作ってみた。やはり細部に時間を注ぎ込み続けてしまう。自分が何を望んでいるか明確なら、LLMと一緒にこういう作業をするのはかなり楽しい
ある程度以上の趣味ゲーム開発を継続していて、いくつものゲームも完成させてきた。だが、このコメントの流れ全体として、実際のゲーム開発経験があまりないように感じる。ゲーム開発でコーディングが簡単だという主張には同意できない。新しいアイデアやジャンル変化のあるメカニクスを考えるほうがむしろ簡単で、実際にコードとして実装する部分のほうがずっと難しいと感じる。たとえばマルチプレイヤーのVampire Survivorsにバトルメックのカスタマイズを追加するのを想像するのは簡単だが、LLMだけでそれを実装するのは不可能に近い。今回の事例は、すでに完全に知られているカードゲームのルールなので、ヘビゲーム並みに単純だ。筆者を非難したいわけではなく、ただ多くの人が実際のゲーム開発経験なしに開発を判断している点を指摘したい
コーディングがゲーム開発で難しい部分だという主張には同意しない。もちろん難しいことはあるが、本当に難しいのは新しくて面白いアイデアを思いつくことだ。良いアイデアさえあれば、小さな断片に分解して反復すれば、最終的には実装できる。本当の難所は、白紙の状態から何を作るかを決める瞬間だ。散歩してみるとか、あれこれ試してみるとか、何千年も芸術で繰り返されてきた問題だ。一方でコーディングは結局のところ工学的な作業だ。自分も最近ゲーム開発を学びながら数学も勉強しているが、ベクトル数学やクォータニオンを学ぶことのほうが、「自分はどんなゲームを作りたいのか？」を決めることよりずっと簡単だった
基本的には同意するが、自分にとってはむしろ新しいアイデアを考えたり創造的な試みをする部分のほうがいつも難しかった。たいていのゲームメカニクスは何でもコーディングできるが、文章作成や創造性の部分は本当に大変だ。それが簡単な人は本当に恵まれている。誰にとっても自然にできることではない
完全なクライアントサイドゲームを作ろうとしているのなら、なぜ「バックエンド」が必要だという書き方をしているのか、そしてなぜアプリ全体ではなくバックエンドだけ別の技術を使うのかが気になる
ソフトウェア業界では、アイデアが簡単かつ素早く実現する領域はほとんど消えたように感じる。すでに競争が激しすぎて、どれほど小さな市場を狙っても、グローバルVCやグローバルAIと直接競争する時代だ。昔は少なくとも大企業が興味を持たないニッチを見つけられた。今は大手VC向けであれニッチであれ、とにかく世界中と競争しなければならないので、結局は極度に複雑な技術が必要な小さな市場か、収益性が低く失敗確率が高くライフサイクルが短い分野（たいていのゲームがまさにこれ）しか残らない。前者なら一社ずつ回って商品説明をするようなマーケティングが必要だ。ゲーム業界の経験から言えば、開発段階に入る前ですら大成功例というのは「100万ビューを獲得して6か月後には完全に失速する程度」だ。継続的な収益がほとんどないので、始めること自体がとてもやる気を失わせる。Minecraftのようなゲームを作るのはほとんど宝くじに近い。とはいえゲーム業界は、他のソフトウェア業種と比べればまだ実力主義だ。品質と面白さが採用に関係している。他業界は規制、ネットワーク効果による独占、あるいは政府統制など、迷路のようだ。むしろ最初から政府が「この分野はもうこの会社が支配するから、スタートアップはやめて別をやれ」と教えてくれれば、1年無駄にせずに済むのにと思う
いつになったら、グリーンフィールド（完全新規）プロジェクトがエージェントコーディング能力のベンチマークとして最悪のケースだと気づくのだろうか
LLMが好きな理由は、自分が頭の中でプログラムを抽象化するやり方に、より近い形でコードを扱えるよう助けてくれるからだ。コードを読むと、まるでASTのように関数と呼び出しを入力と結果の抽象ノードに変換して理解している。LLMのおかげで、これを逆にコードへ落とし込む作業がものすごく簡単になる。いちいちアイデアに合うコード例を探し回ったり、記憶をたどったりする必要はなく、LLMにWiFi初期化のような定型コードを書いてくれと命じればいい。結果として、レゴブロックを積むようにプログラムを組み立てられるようになる。LLM以前でもこのやり方は可能だったが、はるかに多くの努力が必要だった。そのおかげで今はいろいろな言語をまたいで気軽に開発している。言語の内部構造や文法をあまり学ばないままだが、まさにそこがポイントだ。言語や文法は、プログラムの論理的な流れとは関係のない二次的なディテールにすぎない。結局、機械語からアセンブリ、C、そしてより高水準の言語へ進化してきたように、これからはコーディングではなく「プログラミング」そのものへとますます近づいていくはずだ。最終形がどうなるかは誰にもわからないが、今後は「書く」ことに費やす時間よりも「プログラミング」に集中する時間のほうが確実に増えていくと思う