このリポジトリREADMEの'Zero-Touch Generation Examples'にあるゲーム群が、LLMにプロンプト・ツールと'Create a game'という指示を与えて一発で出てきたものだ。バランスなどに多少難ありだが、一応遊べるワンボタンゲームになっている。この程度のゲームが作られる確率がだいたい3割くらい。10個のうちの3つは遊べる。
今までは一発で遊べるゲームが出てくることはほぼ無かったので、3割といえども大したものだ。3割程度まで打率が上がった理由は、Claude Opus 4.5の能力の高さによるところが大きいが、今回作成したワークフローによるところもある。
LLM向けミニゲーム制作ワークフロー
LLMに、タグ選択 → 設計 → 実装 → 評価 → 改善という5段階のワークフローでゲームを生成させた。使用したプロンプトやツールは上記リポジトリにある。特徴的な点としては以下が挙げられる。
タグ駆動の発想
107種類のゲームメカニクスタグ （player-rotate, on_pressed-jump, field-auto_scrollなど）からランダムに数個を選び、それをインスピレーションの種としてLLMに渡す。重要なのは、タグを仕様として扱わないことである。矛盾するタグが選ばれた場合でも、それを創造的なチャレンジとして活用する。
強い制約による品質確保
- ワンボタン操作: 押す・離す・長押しの3パターンのみ
- 約150行のコード: スコープの肥大化を防ぐ
- 単一フレームワーク: crisp-game-lib のAPIのみ使用
LLMは自由度が高すぎると一貫性を失いやすい。強い制約を課すことで、出力の品質を安定させている。
自動評価による客観的判定
生成されたゲームを攻略可能な入力パターンを遺伝的アルゴリズム（GA）で生成、プレイさせ、「上手いプレイ」のスコアと「単調入力」（連打、放置、押しっぱなし）のスコアを比較する。
GA比率 = GAのベストスコア / 単調入力の最高スコア
この比率が1.5を超えれば「スキルが報われるゲーム」として合格とする。比率が低ければ、詳細ログを分析して改善を行う。
でもまだ人手でのバランス調整が必要
GA評価を通過したゲームでも、人間がプレイしてバランスを調整することはまだ必要である。自動評価で「スキルが報われる」ことは確認できても、「適切な難易度か」「スコアの伸びがプレイヤースキルを反映しているか」は人間が判断せねばならぬ。スコアリングシステムや難易度曲線の調整はこの段階で行う。
バランス調整後、再度LLMに今度はそのゲームを「ジューシー」に、遊んでいて楽しい視覚的フィードバックを加えることを依頼する。このように「ルール・メカニクス」と「手触り・演出（ジューシーさ）」を分けて生成させることで、まずは純粋な「ゲームシステム」の生成にLLMを集中させることができる。LLMに「ゲームフィール」を加えさせるのはその後だ。
上記リポジトリの'Enhanced Game Feel Versions'にこれら調整を行った版がある。元のバージョンよりはだいぶ遊びやすく、また見た目に楽しくなっている、はず。
LLMにうまくゲームを作らせるコツ
このようなワークフローがそこそこうまくいったことを考えると、LLMに一発でゲームを作らせるには以下のような内容がカギになるだろう。
制約は味方：LLMに「何でも作れる」状況を与えると、出力は発散しがちである。出力形式、使用技術、コード量を厳しく制限することで、品質が安定する。これはゲームに限らず、コード生成全般に適用できる話。
評価の自動化が重要：「良いゲーム」の定義は曖昧だが、「スキルが報われるか」という一側面に絞れば数値化できる。何らかの測定可能な指標を設計できれば、LLMの出力を自動で評価・改善できる。
ドメイン知識は外部化：crisp-game-libのAPIや衝突検出の仕様、ワンボタンゲームの設計パターンなどは、すべてマークダウン文書として外部化されている。LLMの事前学習に頼らず、必要な知識をプロンプトとして明示的に与えることで、再現性と制御性が高まる。
反復ループを設計：一発で完璧な出力を期待しない。評価 → 分析 → 修正のループを何回かまわすことを前提としてワークフローを設計した方が良い。
関心の分離：メカニクスとジューシーさを別々のフェーズで扱うことで、各フェーズのタスクが明確になる。LLMは曖昧な指示より具体的な指示で良い結果を出す。「面白いゲームを作れ」より「このゲームにジャンプエフェクトを加えよ」のほうが成功率が高い。
ワンボタンミニゲーム以外のゲームも作れる？
たぶんまだ難しい。現状のワークフローにはいろいろ制約がある。
評価できるのは一側面のみ
GA比率は「スキルが報われるか」を測定するが、驚きや新規性、ゲームバランスの適切さは測定できない。評価数値が良くても、人間がプレイして面白くないゲームは存在する。
ドメイン固有の準備コストが高い
今回のワークフローが機能するのは、ワンボタンゲームという十分に制約されたジャンル、ヘッドレス実行可能なテスト環境、crisp-game-libという適切な抽象度のフレームワークを揃えたからである。これらを揃えるのはそこそこ大変であり、別のジャンルに適用するには同等の準備が必要になる。
シミュレーションの限界
GAは「最適なプレイ」を近似するが、人間のプレイとは異なる。人間が発見しにくい抜け道を見つけたり、逆に人間には自明な操作を見逃したりする。またワンボタンゲーム以外は「最適なプレイ」をさせることがそもそも難しい。
新規性の保証がない
LLMは学習データに含まれる既存ゲームの影響を受ける。タグを「インスピレーションの種」として扱い、類似ゲームとの差異を明示させる工程を設けているが、真に斬新なメカニクスが生まれる保証はない。
LLM自動ゲーム生成の時は近くて遠い
LLMによるゲーム自動生成は、強い制約と自動評価の組み合わせによって「遊べるゲーム」を生成できる段階には達している。現状のワークフローでは人間によるバランス調整を含むが、ゲーム評価指標の多様化、既存ゲームとの比較による新規性担保、プレイ動画などのマルチモーダル評価などを組み合わせれば、完全自動化に近づける可能性はある。
ただし、「面白さ」の完全な数値化は本質的に困難である。人間が面白いと感じる要素には、驚き、達成感、フロー状態への誘導など、単純な指標では捉えきれないものが含まれる。LLMがこれらを捉えるのがすぐそこか、あるいは本質的に難しいままなのか、その辺はまだまだ未知数である。
