AIゲーム制作ラボ

作り方の流れ

AIでUnityゲームを
作る流れ

導入から公開までを7つの段階に分けました。各段階の「終わりの条件」と、実際にやって書いた記事を並べています。上から順に読めば、1本公開するまでの道になります。

WindowsでUnityの小さな2Dゲームを作り、ブラウザへ公開した実践をもとにしています。リンク先には、実行した手順と、公開先などの調査記録があります。 各工程でつまずいた点と改善の実例は開発記事にまとめています。

最初の1本に使うなら

ゲームの全体像を先に見たい人はリフレアの仕様・実装例・検証記録から。環境ができている人は03へ進めます。見た目と操作の反応は実装と同時に作り、各段階でテストを挟みます。

最初に埋める制作メモ

題材だけを渡すと、動いていても判断の少ないゲームになりました。次の項目を具体化し、各段階で実際の画面と結果を受け取ります。これは制作を整理する雛形で、完成ゲームを生成する保証ではありません。

  1. 何を選ぶゲームか：吸収する瞬間、鏡を回す順番、燃料を残す航路など。
  2. 成功・失敗・未達の条件：どこへ着けば、何が済んでいればクリアか。
  3. 段階ごとの新しい判断：前の攻略が通用しない理由を含める。
  4. 確認方法：実入力の通し、安直な攻略との比較、各画面、測定条件。
  5. 作らないものと未確認の範囲：実機、オンライン機能などを分ける。

制作メモと確認表の雛形をダウンロード（Markdown）

反射パズルの計算を手元で試すなら灯路のC#サンプルへ。仕様から改善までを見るならリフレアの制作記録へ進めます。

  1. 01

    環境を作る（Unity と、AI から操作する道）

    Unity のバージョンを選び、エディターを入れ、AI から操作する方法を1つに決めます。ここを決めないと、あとの段階すべてが手作業になります。

    終わりの条件AI がエディターを操作でき、テストとビルドをコマンドで回せる

    残す成果物
    エディターの版と、AIから操作する経路の記録
    確かめ方
    小さなテストを実行し、実行件数と結果を受け取る。導入しただけで止めない。
    つまずいたら
    操作できない場合はWindowsの落とし穴、0件ならテストのasmdef記事へ。
  2. 02

    リポジトリを用意する（AI に触らせる前提で）

    私たちの初回プロジェクトでは、生成物を含めると約2GBありました。容量は環境次第です。まず必要なファイルだけをgitで管理し、複数のAIを同時に走らせる場合は作業フォルダも分けます。

    終わりの条件Assets・Packages・ProjectSettingsと.metaを管理し、生成物を除外できている

    残す成果物
    再取得できるリポジトリと、作業の約束を示す入口文書
    確かめ方
    Assets・Packages・ProjectSettings・.metaを追跡し、Library等の生成物が混ざっていないか確認する。
    つまずいたら
    容量が大きいときはgit管理、複数AIの変更が混ざるときはworktreeの記事へ。
  3. 03

    作らせる（仕様書と、面白さの条件）

    仕様を満たしたゲームは、遊べるゲームとは限りません。AI への指示は感想ではなく合格の条件で書きます。自動生成を使うなら、理不尽な面が出ない作りにします。

    終わりの条件遊べる最小形が動き、「仕様は満たしたのに面白くない」を直せている

    残す成果物
    目的・判断・クリア条件・合格条件を記した仕様と、遊べる最小版
    確かめ方
    正解経路だけでなく放置・連打・順押しなどの安直な攻略も試す。各面で変わる判断を説明する。
    つまずいたら
    動くのに簡単すぎる場合は、灯路と星継ぎの改良記録へ。速度だけを上げない。
  4. 04

    テストで守る（壊れていないことを機械が言う）

    「合格」ではなく「実行件数」で受け取ります。0件でも緑になる落とし穴があります。動くものは、時間を引数で進める形にするとテストできます。

    終わりの条件テストが実際に実行され、件数で結果を受け取れる

    残す成果物
    実行件数付きのテスト結果と、開始から再挑戦までの操作記録
    確かめ方
    クリア・未達・失敗・保存不可を区別する。ロジックのテストとWeb画面の操作を両方確認する。
    つまずいたら
    通り抜けや再生の不一致は、連続衝突と固定tickの記事へ。
  5. 05

    見た目と手応えを作る

    コードで作る絵と音、生成背景をUIと組み合わせる方法の両方を扱います。陰影・輪郭・背景の層・動きへの反応は、最小形から一緒に確かめます。日本語の文字にはフォントを同梱し、Web画面で読みやすさを確認します。

    終わりの条件暗い背景で図形が浮かず、撃破や成功が1コマで分かる

    残す成果物
    開始・プレイ・失敗・成功の画面と、画像・フォントの設定記録
    確かめ方
    PCと375px幅で最長文言、開始操作、結果と再挑戦を見る。航行中の検査を開始画面の代わりにしない。
    つまずいたら
    文字欠けはフォント、無地パネルだけの開始画面は背景とUIの記事へ。
  6. 06

    測って軽くする（本番で通じる速さに）

    fps だけを見ても余裕は分かりません。サイズ・起動時間・1フレームの時間を、同じ場面で比べて決めます。

    終わりの条件サイズ・起動・fps を数字で言えて、重い原因の見当がつく

    残す成果物
    容量・起動・フレーム間隔の比較と、その測定条件
    確かめ方
    同じ端末・場面・キャッシュ条件で複数回測る。部分処理の改善をゲーム全体の高速化と呼ばない。
    つまずいたら
    容量が増えた場合はビルド設定と画像、fpsだけでは判断できない場合は性能計測の記事へ。
  7. 07

    公開する（配信とスコアと保存）

    このサイトで実際に公開したのは自前サーバーです。unityroom・itch.ioは条件を調べた候補として区別しています。保存やランキングは、ゲームに必要な場合に追加します。

    終わりの条件公開URLで起動・操作・終了・再挑戦ができ、配信エラーがない

    残す成果物
    公開URL、配信ファイルの照合結果、紹介と制作記事
    確かめ方
    公開URLで起動・操作・終了・再挑戦・保存を確認する。ローカルでの成功だけで公開完了にしない。
    つまずいたら
    読み込みが止まる場合は自サイト配信、保存はPlayerPrefs、送信はランキングの記事へ。

この順番どおりでなくてもいい

実際には、05（見た目）を後回しにして作り直したことも、06（計測）で測ってから03（作り）に戻ったこともあります。 困っている段階の記事だけを読んでも通じるように書いています。用語は用語集、 実際に出たエラーはエラー集にまとめました。