AIゲーム開発研究室

ゲーム開発ドキュメント

Unity AI Agentは「演出」まで設計できるのか

― 大喜びからキャラクター交代までをAIに任せてみた ―

今回は、2Dゲーム「森のどんぐり大作戦」の制作を進めました。

前回までに、

どんぐりが落下する
→ パンタが籠でキャッチする
→ どんぐりが消える
→ スコアが加算される
→ UIに表示される

ところまで実装されています。

今回の目的は、その先です。

規定数のどんぐりをキャッチする
→ パンタが大喜びする
→ パンタが退場する
→ 次のキャラクター、ポンが登場する

ここまでをUnity AI Agentとともに実装しました。

しかし実際に作業を進めてみると、今回の実験は単なるゲーム進行処理の実装では終わりませんでした。

---

1．7枚の静止画から「大喜び」を作る

パンタには、あらかじめ画像生成AIによって制作した7枚の「大喜び」候補画像がありました。

これらは連続アニメーションとして制作したものではありません。

それぞれ独立した、

「パンタなら、こんなふうに喜ぶかもしれない」

というポーズ候補です。

これまでの制作方法なら、人間がその中から使用する画像を選び、順番を決めてからUnityへ実装することになります。

実際、対話AIであるArcも、

03 → 04 → 05 → 07 → 02

という5枚の構成案を考えました。

しかし今回は、あえてそれをUnity AI Agentへ伝えませんでした。

さらに、人間も使用する画像、順番、タイミングを決めませんでした。

Unity AI Agent自身に7枚の画像を確認させ、

「どのポーズを使うか」
「どの順番に並べるか」
「どのくらいの時間で再生するか」

を判断させることにしました。

---

2．Unity AI Agentが静止画を読み取った

Unity AI Agentが選んだ順番は、

05 → 02 → 04 → 01 → 06 → 03 → 07

でした。

しかも7枚すべてを使用しました。

Unity AI Agentは、それぞれのポーズを単なるファイル番号として扱ったのではありません。

05を「最大の喜び」、

02と06を左右に対応する動的なポーズ、

04と03を左右のリズミカルなステップ、

01と07を正面方向のポーズ、

というように解釈しました。

そして、それらを時間軸上に再構成し、一つの「大喜びアニメーション」を作りました。

再生速度は6fps。

約1.17秒で1周するループアニメーションです。

人間がPlayモードで確認した結果、

非常に滑らかな大喜びアニメーションになっていました。

ここで興味深い結果が得られました。

これまで私たちは、

画像生成AIが動作候補を作る
→ 人間がポーズを選択する
→ 人間が運動として構成する
→ Unity AI Agentが実装する

という役割分担を考えていました。

しかし今回、

画像生成AI
→ 静止ポーズ候補
→ Unity AI Agentによるポーズの意味解釈
→ Unity AI Agentによる時間的再構成
→ 人間によるPlay評価

という別の経路が成立しました。

---

3．3個キャッチするとパンタが大喜び

次に、

どんぐりを3個キャッチするとパンタが大喜びする

処理を実装しました。

3個にしたのは、現在がゲーム進行システムを検証する段階だからです。

3個目をキャッチすると、

パンタの左右操作を停止
→ 通常アニメーションを停止
→ Celebrationへ移行

します。

人間によるPlay確認では、

キャッチ
→ スコア加算
→ 「どんぐり：3」
→ 大喜び

まで正常に動作しました。

---

4．大喜びしながら退場する

次はパンタの退場です。

ここでも、細かな演出数値を人間側から指定しませんでした。

Unity AI Agentに、

大喜びを少し見せる
→ 大喜びを続けたまま真下へ移動する
→ 完全に画面外へ出たら非表示にする

という目的を伝えました。

Unity AI Agentが設定したのは、

大喜び待機時間：1.5秒

退場速度：3.5

でした。

1.5秒という時間は、大喜びアニメーションを約1.3周見せることができる時間として選ばれました。

その後、Spriteアニメーションを継続したまま、Transformを使ってパンタを真下へ移動させます。

ここでは、

Sprite Animation＝大喜び

Transform＝退場移動

と役割を分離しています。

Playしてみると、

大喜びしながら地面へ沈んでいくパンタ

という、予想以上に楽しい演出になりました。

---

5．次のキャラクター、ポンを登場させる

パンタが退場したら、次はポンです。

最初の実装では、

パンタ完全退場
→ 0.6秒待機
→ ポンが画面下から上昇

という構成になりました。

Unity AI Agentはポンの既存アニメーションを確認し、登場中のアニメーションとして、

Pon_Catch_Up

を選択しました。

「上を見上げるポーズなので、画面下から上へ登場する動きに自然に合う」

という判断です。

登場速度には、パンタの退場速度と同じ、

3.5

が選ばれました。

これも正常に動作しました。

しかしPlayしてみると、一つ違和感がありました。

---

6．「0.6秒」が0.6秒には感じられない

数値上では、パンタ退場後の待機時間は0.6秒です。

しかし実際には少し長く感じました。

原因は画面を見れば分かりました。

ポンは画面外から移動を開始します。

さらにゲーム画面下部には前景として草が配置されています。

つまり、

0.6秒待機
＋ 画面外を移動する時間
＋ 下草の裏を移動する時間

を経て、ようやくプレイヤーからポンが見えるのです。

ここで、

プログラム上の待機時間と、プレイヤーが知覚する待ち時間は同じではない

ということが分かりました。

ゲームの演出は数値だけでは判断できません。

最終的には、人間がPlayして「どう感じるか」を確認する必要があります。

---

7．退場と登場を同時にする

そこで演出を変更しました。

パンタが退場移動を開始する
→ 同時にポンも画面下から登場移動を開始する

という方式です。

これによって、

パンタ ↓

ポン ↑

というキャラクター交代が同時進行します。

ただし、ここで別の問題があります。

二人が同じX座標にいると、上下移動中にキャラクターが重なってしまいます。

そこで、

退場位置と登場位置を重ねない

という方針を決めました。

---

8．Unity AI Agentが登場位置まで判断した

ポンの基本登場位置は、

画面中央 X=0

としました。

しかしパンタは、3個目のどんぐりをどこでキャッチするか分かりません。

パンタが中央付近で大喜びを始めれば、そのまま中央から退場します。

すると中央から登場するポンと重なります。

Unity AI Agentは、この問題に対して動的な処理を実装しました。

パンタが退場を開始した瞬間、

パンタのX座標をポン側へ通知

します。

そしてパンタとポンの距離が近すぎる場合には、

2.2ユニット以上離れるようにポンの登場位置を変更

します。

パンタが中央から十分離れていれば、ポンはX=0から登場します。

パンタが中央付近にいれば、その位置を避けて少し左右へずれた場所から登場します。

その結果、

退場するパンタと登場するポンが重ならない

キャラクター交代が実現しました。

Playモードで確認した結果、この演出も正常に動作しました。

---

9．AIが「実装」から「演出設計」へ入り始めた

今回、Unity AI Agentが行ったのはコード生成だけではありませんでした。

人間がすべてを数値として指定したわけでもありません。

Unity AI Agentは、

静止ポーズの意味を読み取る

アニメーションの順番を決める

再生タイミングを決める

大喜びを見せる時間を決める

退場速度を決める

登場に使用する既存アニメーションを選ぶ

登場速度を決める

キャラクター同士が重ならない登場位置を計算する

ところまで行いました。

これは、Unity AI Agentの役割が、

「人間が決めた仕様をコードへ変換するAI」

だけではない可能性を示しています。

人間が目的と制約を与え、細かな部分を固定しなければ、

AI自身が演出上の選択肢を評価し、初期案を設計する

ことも可能になってきました。

---

10．それでも最後に判断するのはPlayした人間

一方で、今回もっとも重要だった修正は、

「0.6秒では少し長く感じる」

という人間の感覚から始まりました。

処理そのものは正常でした。

バグでもありません。

Unity AI Agentの説明にも合理性がありました。

しかし実際にゲームをPlayすると違和感があった。

その違和感によって、

パンタ完全退場後にポン登場

から、

パンタ退場開始と同時にポン登場

へ設計そのものが変わりました。

つまり、

AIが正しく実装したことと、ゲームとして良いことは同じではありません。

ゲームは実際に動かし、人間が体験することで初めて分かることがあります。

---

11．今回の制作工程

今回の工程を整理すると、

画像生成AIが大喜びポーズ候補を生成

↓

Unity AI Agentが静止ポーズを解釈

↓

Unity AI Agentが大喜びアニメーションを構成

↓

人間がPlayして評価

↓

Unity AI Agentが大喜び後の退場を実装

↓

人間がPlayして評価

↓

Unity AI Agentがポンの登場を実装

↓

人間が「間が長い」と感じる

↓

人間と対話AIが原因を検討

↓

退場と登場を同時にするよう再設計

↓

Unity AI Agentが重なり回避まで含めて再実装

↓

人間がPlayして最終確認

となりました。

今回も、

設計 → 実装 → 検証 → 発見 → 再設計 → 再実装 → 再検証

という循環が実制作の中で確認されました。

---

12．人間の仕事はなくなったのか

今回、人間は大喜びアニメーションのフレーム順すら決めませんでした。

コードも書いていません。

退場速度も登場速度もUnity AI Agentが決めました。

一見すると、人間の仕事が減っているように見えます。

しかし実際には、人間は別のことをしています。

何をAIに決めさせるのかを決める。

何を固定条件として与えるのかを決める。

生成された結果をPlayする。

違和感を発見する。

何を変更すべきか考える。

そして、

最終的に採用するかどうかを決める。

今回、人間が意図的に「決めない」ことで、Unity AI Agentがどこまで演出を構成できるのかを検証することができました。

したがって、

人間が作業しないことを意図的に選択することも、AI時代の設計行為になり得る。

今回の実験は、その可能性を示したものだと考えます。

---

13．今回使用したUnity AIクレジット

前回作業終了時点では、

652 / 1,000クレジット

残っていました。

今回の作業終了時点では、

426 / 1,000クレジット

です。

したがって今回使用したクレジットは、

226クレジット

でした。

今回の226クレジットによって、

パンタの大喜びアニメーション構成
→ 3個キャッチによる大喜び移行
→ 大喜び後の退場
→ ポンの登場
→ キャラクター交代タイミングの修正
→ 登場位置の動的な重なり回避

まで実装しました。

Unity AIくん、今回はかなり働きました。

そのぶん、

226クレジットという、なかなかお高いギャラを持っていきました（笑）。

ただし、今回得られたものはコードだけではありません。

AIが静止画から動きを構成できること。

AIが既存素材の意味を読み取って演出へ利用できること。

人間が細部を決めなくても、AIが初期演出案を設計できること。

そして、AIが作った結果を人間が体験することで、次の設計変更が生まれること。

ゲームそのものと同時に、

 

AI時代のゲーム開発方法論そのものが、また一段進んだ一日になりました。