LLMなしでゲームを作ると3か月、LLMと一緒なら3日

• 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して始められる
  • バックエンド: https://github.com/marianogappa/tictactoe-backend
  • フロントエンド: https://github.com/marianogappa/tictactoe-frontend
  • デモ: https://marianogappa.github.io/tictactoe-frontend/

バックエンド開発

• ターン制ゲームのバックエンドは、機能を明確に設計しやすい
• サーバーレス構成を維持し、商用サーバーがないなら人間同士が対戦する構造は避けるのが現実的な選択

フロントエンド開発

• フロントエンドでは次のような作業が必要
  • バックエンドに新しい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の助けで生産性は大きく向上したが、フロントエンドの力量とデバッグ経験は依然として重要
• 誰でもこの構成で自分自身のゲーム開発に挑戦できるので、ぜひ試してみてほしい