Tesuji面白いアイデアと、面白いゲームは別物
「ピンを抜いてキャラクターを助ける」「AIキャラと会話して事件を解く」「物を合成して強くする」。
ゲームのアイデアは一文で言えます。しかし、Unityで実際に遊べる形へするときには、一文では足りません。
必要になるのは、
- プレイヤーは何を入力するのか
- 入力した直後に何が変わるのか
- 成功と失敗はどう決まるのか
- 何秒ごとに判断が発生するのか
- 何が面白いと仮定しているのか
- その仮説が外れたと、どう判定するのか
という設計です。
ChatGPTをUnity開発に使うなら、コードを大量に書かせる前に、「何を最短で検証すべきか」を言語化する役に置くと失敗しにくくなります。
最初に作るべきものは、ゲーム全体ではなく「核心の5〜20秒」
たとえば「ピンを抜いてキャラクターを助けるゲーム」を考えます。
完成版なら、ステージ選択、広告、ショップ、演出、スキン、セーブなどが必要になるかもしれません。
しかし最初のプロトタイプで必要なのは、たったこれだけです。
- ピンを選ぶ
- ピンが抜ける
- 重力や衝突で状況が変わる
- キャラクターが助かる、または失敗する
- すぐリトライできる
つまり最初に検証したいのは、
「ピンを選ぶ前に考え、抜いた直後に結果が動く」こと自体が気持ちいいか
です。
この仮説が弱いのに、タイトル画面や課金導線を作っても意味がありません。
ChatGPTに渡すべき情報
良いプロトタイプ仕様を作るには、最初に次の情報を与えます。
| 項目 | 例 |
|---|---|
| プレイヤー入力 | ピンをタップ |
| 直後の反応 | ピンが抜ける |
| 世界のルール | Rigidbodyと重力 |
| 成功条件 | キャラクターがゴールに到達 |
| 失敗条件 | 危険物に接触 |
| 1プレイ時間 | 10〜30秒 |
| リトライ | 1タップですぐ再開 |
| 今回検証しないもの | UI装飾、課金、ステージ選択 |
ここからChatGPTに、GameObject、状態、イベント、成功判定、失敗判定を分解させます。
コードより先に状態遷移を決める
小さなゲームでも、状態が曖昧だとバグが増えます。
最低限、
Ready → Playing → Success / Failed → Retry
くらいは先に決めます。
これを決めずに、各GameObjectが勝手に「ゲーム終了」「リトライ」「入力禁止」を判断し始めると、あとから状態が衝突します。
ChatGPTには、コードそのものより先に、
- 状態一覧
- 状態が変わるイベント
- その状態で許可される入力
- リトライ時に戻すデータ
を出させる方が役に立ちます。
Unityでは、まずグレーボックスでよい
面白さの検証段階では、完成素材は不要です。
- Cube
- Sphere
- Capsule
- 単色マテリアル
- 仮UI
だけで十分です。
なぜなら検証したいのは「絵が綺麗か」ではなく、「入力と結果の関係が面白いか」だからです。
ここで完成アートを先に入れると、面白くない企画を捨てにくくなるという別の問題も出ます。制作コストをかけた分だけ、判断が鈍ります。
プロトタイプにも受け入れ条件を付ける
「とりあえず動いた」ではなく、最低限の完了条件を決めます。
たとえば以下です。
- ピンを10回連続で操作しても入力不能にならない
- Success後に追加入力できない
- Failed後に1タップでリトライできる
- リトライ後に前回のRigidbody状態が残らない
- 想定外の順序でピンを抜いてもゲームが停止しない
- 30秒以内にゲームのルールを説明なしで理解できる
最後の項目はコードテストではありませんが、ゲームとしては重要です。
ChatGPTをテスト設計にも使う
正常系だけを自分で確認すると、想定外操作を見落とします。
たとえばAIに、
このゲームでプレイヤーが壊しそうな操作を20個挙げて
と頼むと、
- ピンを高速連打
- Success直前に別のピンを押す
- 物体が画面外へ落ちる
- 2つの危険物が同時接触
- リトライ直後に入力
- 低FPS時の物理挙動
といった観点を増やせます。
ここで重要なのは、AIに「バグがないか見て」と頼むのではなく、破壊パターンを列挙させることです。
良いKPIは「生成コード行数」ではない
AI導入効果を測るなら、コード量ではなく検証速度を見るべきです。
たとえば、
- アイデア → 最初のプレイまでの時間
- 仕様変更 → 再プレイ可能になるまでの時間
- 1日に捨てられる企画数
- 1週間に検証できるコアループ数
の方が重要です。
仮にAIでコード量が2倍になっても、プロジェクトが複雑になり、変更に時間がかかるなら逆効果です。
AI生成コードの最大の罠
ChatGPTは、局所的には正しそうなコードを高速に増やせます。
そのため、
GameManagerに全部入る- Singletonが増える
- 状態の正本が複数できる
- Inspector参照が増えすぎる
- 似た処理が別スクリプトへ複製される
といった負債が、短時間で増えることがあります。
プロトタイプ段階でも、少なくとも
- ゲーム状態
- 入力
- 物理オブジェクト
- UI
の責務は分けておくと、次の検証へ進みやすくなります。
「完成させるAI」ではなく「捨てる速度を上げるAI」
ゲーム開発では、10個の案を考えて10個全部完成させる必要はありません。
むしろ、10個試して8個を早く捨て、残った2個へ集中できる方が強い。
ChatGPTとUnityの組み合わせで狙うべきなのは、完成速度だけではなく、仮説を安く潰す速度です。
次の一手
新しいゲーム案が出たら、ChatGPTにコードを書かせる前に次の4つを決めます。
- このゲームの「面白さの仮説」は何か
- それを体験する最小の5〜20秒は何か
- 成功・失敗・リトライの状態は何か
- 何が起きたら「この案は弱い」と捨てるか
そこまで決まったら、Unityでグレーボックスを作る。
AIを使って完成品を早く作るより、弱い企画を早く殺せる方が、ゲーム開発では価値が大きいことがあります。