Contact
AIゲーム開発研究室
セグメンテーションとリトポロジーの実験
AIゲーム開発研究室
3Dモデル制作ドキュメント
第2回 生成した3Dモデルをゲーム用モデルへ近づける
― Smart Meshとリトポロジーの実験 ―
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回は、2Dキャラクター「パンタ」の正面画像1枚から、Tripo Studioを使用して高精細な3Dモデルを生成しました。
生成されたモデルは、正面から見ると非常に完成度が高く、顔、目、耳、体形、スカーフ、リュックなど、パンタの特徴がかなり忠実に立体化されていました。
さらにモデルをセグメンテーションし、一体として生成された3Dモデルを、頭部、胴体、腕、脚、スカーフ、リュックなどの複数の領域としてAIが認識できることも確認しました。
ここまでが前回の実験です。
今回の実験は、この高精細なパンタの3Dモデルを、
「実際にゲームで使用できるモデルへ近づけることはできるのか」
というところから始めました。
そこで最初に注目したのが、モデルのポリゴン数です。
1．生成されたモデルのポリゴン数
前回生成したパンタは、見た目としては非常に良好でした。
しかしモデルの情報を確認すると、
面数 1,901,487
頂点数 1,064,178
という非常に高密度な3Dモデルになっていました。
細かな毛並みまで立体形状として表現されているため、高密度になること自体は理解できます。
しかし、これをリアルタイムで動かすゲームキャラクターとして考えれば、そのまま使用するには非常に重いモデルです。
そこで、
高精細な外見をできるだけ維持しながら、モデルを軽量化できないか
を調べることにしました。
2．Smart Meshを試す
最初に試したのが、Tripo Studioの「Smart Mesh」です。
Smart Meshの画面では、
クアッド／トライアングル
を選択でき、さらにポリカウントを設定できます。
今回は、
クアッド
ポリカウント 5000
を設定しました。
画面だけを見ると、現在開いている高精細なパンタを、低ポリゴンモデルへ変換できるようにも見えます。
そこで「生成」を実行してみました。
ところが、
「進む前にアップロードしてください」
というメッセージが表示されました。
ここで、Smart Meshは現在開いているパンタの3Dモデルを直接軽量化する機能ではなく、新しく画像を入力して3Dモデルを生成するための機能であることが分かりました。
つまり今回の目的である、
「すでに生成した高精細パンタをゲーム用モデルへ軽量化する」
ためには、別の方法が必要です。
そこで次に「リトポロジー」を試すことにしました。
3．リトポロジーを試す
Tripo Studioには、生成済みの3Dモデルに対して「リトポロジー」を行う機能があります。
リトポロジー画面では、
クアッド
トライアングル
を選択でき、目標とするポリゴン数を設定できます。
今回は、
クアッド
ポリゴンカウント 10,000
を設定しました。
最初の処理では、
「タスク中にエラーが発生しました」
というメッセージが表示され、処理を完了することができませんでした。
そこで、約190万面という非常に高密度なモデル全体を一度に処理するのではなく、前回行ったセグメンテーションを利用して、一部分だけを処理できないかと考えました。
4．前回のセグメンテーションを利用する
前回の実験では、パンタの3Dモデルをセグメンテーションしています。
そこで今回は、その結果をリトポロジーに利用できるか試しました。
まず鼻の部分を選択しました。
鼻だけが選択状態になり、画面には、
選択部分 21,921面 / 全体1,901,487面
選択部分 12,188頂点 / 全体1,064,178頂点
と表示されました。
この状態でリトポロジー画面へ移動しても、選択状態は維持されました。
つまり、前回行ったセグメンテーションは単なる色分けではなく、
選択したセグメントを、その後の処理対象として利用できる
ことが確認できました。
5．胴体部分だけをリトポロジーする
次に、鼻よりも大きな領域で実験するため、胴体部分を選択しました。
選択された部分は、
408,638面
212,663頂点
でした。
この状態でリトポロジーへ移動し、
クアッド
ポリゴンカウント 10,000
を指定して処理を実行しました。
今回は処理が完了しました。
処理後に表示されたモデル全体の数値は、
面数 1,502,084
頂点数 763,144
となりました。
ここで重要なのは、モデル全体が10,000ポリゴンになったわけではないということです。
今回リトポロジーされたのは、選択していた部分だけです。
それ以外の部分には、元の高密度な形状が残っています。
この実験によって、
Tripo Studioでは、セグメンテーションで選択した部分だけをリトポロジーすることができる
ことが確認できました。
6．部分リトポロジーによって隙間が発生した
処理自体は成功しました。
しかし、モデルを拡大して確認すると、新しい問題が見つかりました。
特に目立ったのが、リュックと胴体の境界部分です。
そこに、細い隙間のようなものが発生していました。
さらに脚と胴体の境界付近にも、不自然な接続部分が確認できました。
今回の処理では、選択した部分だけが新しいメッシュへ再構成されています。
一方、その周囲には元の高密度なメッシュが残っています。
そのため、異なる状態のメッシュが接する境界部分に、ずれが生じた可能性があります。
少なくとも今回のモデルでは、
部分リトポロジーには成功したが、そのままゲーム用モデルとして使用できる状態にはならなかった
という結果になりました。
7．リトポロジーを元に戻せるか
隙間が発生したため、元の状態へ戻すことを考えました。
そこでUndoを試しました。
しかしUndoボタンにカーソルを合わせると操作できないことを示すマークが表示され、今回の処理をUndoすることはできませんでした。
そこで、
まだ明示的に保存していないのだから、一度Tripo Studioを終了して開き直せば、元へ戻るのではないか
と考えました。
Tripo Studioを閉じ、再び「資産」からパンタを開きました。
ところが、表示された数値は、
面数 1,502,084
頂点数 763,144
のままでした。
つまり今回の実験では、明示的に保存操作を行っていなくても、完了したリトポロジーの結果はモデル資産に反映されていました。
また、通常のUndoによって元へ戻すこともできませんでした。
少なくとも今回の操作環境では、
「とりあえず処理して、問題があればUndoすればよい」
という方法では扱えないことが分かりました。
8．そもそも元の3Dモデルは正しいのか
ここまでゲーム用モデルへの軽量化を試してきました。
しかし、ここで一度、もっと根本的な問題へ戻ることにしました。
今回使用しているパンタの3Dモデルは、もともと正面画像1枚だけから生成したものです。
正面から見たパンタは非常によくできています。
口の中まで実際の立体形状として作られており、顔や体形についても、元画像の特徴をかなりよく再現しています。
しかしモデルを横や後ろから見ると、別の問題があります。
正面画像には写っていない部分を、AIが推測して作っているからです。
特に背面のリュックは公式デザインとは異なり、さらに正面画像には存在しない尻尾まで生成されていました。
これは単純にAIが間違えたというよりも、正面画像しか与えていない以上、見えない部分はAIが推測するしかないという問題です。
そこで、
軽量化の方法をさらに追究する前に、まず公式デザインに近い3Dモデルそのものを作るべきではないか
と考えました。
9．公式4面図から3Dモデルを作る
パンタには、すでに公式キャラクター資料として4面図があります。
正面
右側面
背面
左側面
です。
この4面図には、正面画像だけでは分からなかったリュックの形状や、側面・背面から見た体形なども描かれています。
そこで次の実験では、この4面図から、
正面・右側面・背面・左側面をそれぞれ独立した4枚の画像として準備し、複数画像からパンタの3Dモデルを生成する
ことにしました。
すでに今回、正面画像1枚から生成したモデルがあります。
したがって次に4方向の画像からモデルを生成すれば、
正面画像1枚からAIが推測して作ったモデル
と、
人間が確定した4方向のデザインを与えてAIが作ったモデル
を直接比較できます。
これは、AIによる2Dキャラクターの3D化を考える上でも重要な比較実験になります。
10．有料プランへ移行する
Tripo Studioで複数画像からの3D生成を確認したところ、この機能を利用するには有料プランへの移行が必要でした。
今回の研究目的は、
「無料でどこまでできるか」
を調べることではありません。
目的は、
AIを利用して、実際にゲームで使用できる3Dキャラクターを制作する方法を構築すること
です。
そのため、必要な機能であれば実際に使用して検証することにしました。
今回は、まず1か月間の有料プランを契約しました。
契約後、利用可能なクレジットは、
3,135クレジット
となりました。
これによって、公式4面図を使用した複数画像からの3Dモデル生成を実験できる環境が整いました。
11．今回の実験で分かったこと
今回の実験は、最初から決められた工程を順番に実行したものではありません。
高精細な3Dモデルをゲームで使えるようにしたい。
そのためにSmart Meshを試してみる。
しかし、現在のモデルを直接処理する機能ではなかった。
そこでリトポロジーを試す。
モデル全体では処理に失敗する。
前回のセグメンテーションを利用して、一部分だけを処理してみる。
部分リトポロジーには成功する。
しかし今度は境界部分に隙間が発生する。
元へ戻そうとする。
ところが通常のUndoでは戻せず、再起動しても処理結果が残っている。
そして最終的に、
「そもそも正面画像1枚から作った3Dモデルを、このまま加工していくことが最善なのか」
というところまで戻ることになりました。
これは失敗の連続ではありません。
むしろ、実際にAIと3Dモデルを制作してみなければ分からなかったことが、次々と明らかになった過程です。
AIによる3Dモデル制作では、
生成 → 確認 → 加工 → 問題発見 → 方法変更 → 再生成
という工程を繰り返しながら、完成形へ近づいていく必要があります。
おわりに
今回の実験によって、AIで3Dモデルを生成することと、ゲームで実際に使用できる3Dキャラクターを作ることは別の問題であることが、少しずつ見えてきました。
正面画像1枚からでも、AIは驚くほど完成度の高い3Dモデルを生成できます。
しかし、見えない部分はAIが推測します。
高精細なモデルを軽量化すれば、今度はメッシュ構造の問題が発生する可能性があります。
さらに、加工した結果を簡単に元へ戻せない場合もあります。
そこで次は、これまでのモデルを無理に修正し続けるのではなく、生成の出発点そのものを改善します。
パンタには、人間が制作し、公式デザインとして確定した4面図があります。
次回は、その4方向の情報をAIへ与えます。
正面画像1枚を見たAIが、見えないパンタを想像する。
そこから、
人間が正面・側面・背面まで設計したパンタを、AIが3Dへ変換する。
制作方法を、ここで一段階進めます。
そして、この比較によって、
人間が設計した2Dキャラクターを、AIによってどこまで忠実に3Dゲームキャラクターへ変換できるのか。
次の実験では、そこを検証します。
第1回 2Dキャラクター1枚から3Dモデルを生成する
AIゲーム開発研究室
3Dモデル制作ドキュメント
第1回 2Dキャラクター1枚から3Dモデルを生成する
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
これまで「おむすび山のなかまたち」のゲーム制作では、主として2Dゲーム素材の制作を進めてきた。
今回から、新たにAIを利用した3Dモデル制作の検証を開始する。
使用するのは、AIによって画像から3Dモデルを生成できる Tripo Studio である。
最初の実験では、「おむすび山のなかまたち」のキャラクターであるパンタを使用した。
パンタについては、すでに正面・右側面・背面・左側面からなる公式4面図を制作している。
しかし今回は、あえて4面図すべてをAIには与えない。
正面画像1枚だけをTripoへ入力し、見えていない側面や背面をAIがどのように3D化するのかを検証する。
これを、今後のAIによる3Dゲーム素材制作研究の最初の基準実験とする。
1 公式4面図を基準資料とする
今回使用するパンタには、すでに公式4面図が存在する。
正面だけでなく、左右側面、背面のデザインまで人間側では確定している。
この4面図は今回、すべてをTripoへの入力画像として使用するためのものではない。
AIが生成した3Dモデルが、本来のパンタの形状やデザインとどの程度一致するのかを検証するための基準資料として使用する。
特に重要なのが、背面の青いリュックである。
公式デザインでは、リュックの形状、ポケット、フラップ、金具などが明確に設定されている。
これらは正面からはほとんど見ることができない。
AIが正面画像だけから、この背面をどのように推測するのかを見ることにした。
2 正面画像1枚だけを入力する
Tripo Studioへ入力したのは、公式4面図から用意したパンタの正面画像1枚である。
画像にはパンタの全身が写っている。
顔、胴体、腕、脚、緑色のスカーフ、そして青いリュックの肩ベルトは確認できる。
しかし、リュック本体や尻尾など、背面の情報は見えない。
つまりTripoは、正面から見えない部分については自ら3D形状を推定しなければならない。
今回は、この条件を意図的に維持した。
3 HDモデルとして生成する
Tripo Studioの「HDモデル」を使用した。
生成時の主な設定は次のとおりである。
- ウルトラメッシュ品質 ON
- AIコンプリート OFF
- テクスチャ ON
- テクスチャ品質 4K
- 照明を除去する ON
- PBR ON
- 位相 トライアングル
- ポリカウント上限 2,000,000
生成には55クレジットを使用した。
生成後のモデルは、
面 1,901,487
頂点 977,591
という非常に高密度な3Dモデルとなった。
正面から見ると、パンタの特徴はかなりよく再現されている。
大きな頭、丸い身体、耳、目の周囲の黒い模様、鼻、口、腕、脚、緑色のスカーフ、青い肩ベルトなどが3D形状として成立した。
さらに拡大して確認すると、口は単なる平面的なテクスチャではなかった。
鼻が前方へ突出し、口には奥行きがあり、口腔や舌まで立体的に生成されている。
正面画像から確認できる部分については、かなり高度な3D化が行われていることが分かった。
4 モデルを回転させて側面を確認する
生成したモデルはTripo Studio上で自由に回転させることができる。
そこで、正面から側面へモデルを回転させた。
横から見ると、正面画像だけでは分かりにくかった頭部の厚み、鼻先の突出、腹部の丸みなどが立体として作られている。
青い肩ベルトも身体の側面を通り、背中方向へ続いている。
AIは単純に正面画像を厚く押し出したのではなく、キャラクターとして成立する立体形状を推定していることが分かる。
5 背面ではAI独自の補完が行われた
次に、モデルを180度回転させて背面を確認した。
ここで大きな違いが現れた。
公式4面図では、背中には青いリュックが存在する。
ところが生成されたモデルでは、正面から確認できた青い肩ベルトは背面方向まで作られているものの、公式デザインと同じリュックは再現されなかった。
代わりに、背中中央に単純化された大きな形状が生成されている。
これは当然ともいえる。
今回Tripoに与えた正面画像には、リュック本体の形状が写っていないからである。
AIは、
「肩ベルトがあるため、背中には何かが存在する」
というところまでは補完したと考えられる。
しかし、その具体的な形状を公式デザインどおりに知ることはできない。
6 毛並みは360度均一には生成されなかった
もう一つ、以前Tripoを試した際にも確認していた現象が、今回再び発生した。
正面から見える頭部の輪郭には、細かな毛束による凹凸が立体形状として作られている。
しかし、その毛並みは頭部全体へ均等に続いていない。
側面から後頭部へ回り込むにつれて毛束の凹凸が減少し、背面側は比較的滑らかな形状となった。
つまり、
正面画像で観測できる毛並みの形状を、AIが自動的に360度全体へ展開するわけではない
ことが分かった。
これは単なるテクスチャの問題ではなく、メッシュそのものの形状に現れている。
7 AIによるセグメンテーションを試す
次に、Tripo Studioのセグメンテーション機能を試した。
今回は「バランス」を選択した。
セグメンテーションを実行すると、パンタの3Dモデルが多数の色で表示された。
頭部、耳、目、目の周囲、鼻や口、左右の腕、脚、胴体、スカーフ、肩ベルトなどが、それぞれ異なるパーツとして認識されている。
一体の高密度モデルとして生成されたパンタを、AIが再び構造として解析し、複数の編集可能な部分へ分けていることが分かる。
8 背面をセグメント表示して分かったこと
セグメンテーション状態のまま、モデルを背面へ回転させた。
ここで、通常表示では分かりにくかったAIの推定結果が明瞭になった。
背中中央に生成されていた大きな形状は、胴体とは別のパーツとして認識されていた。
左右の肩ベルトも別パーツとして存在する。
つまりAIは、少なくとも背中側に身体とは異なる何らかの装備物を生成していたことになる。
さらに興味深いことに、腰の下には丸い尻尾状の3D形状が生成されていた。
これは入力した正面画像にはまったく写っていない。
したがって今回確認できた事実は、
Tripoが入力画像に存在しない背面形状まで補完して3Dモデルを成立させている
ということである。
ただし、AIが「パンダには尻尾がある」と意味的に判断して生成したのか、それとも学習された3D形状の傾向から補完したのかは、この実験だけでは判断できない。
9 今回の実験から分かったこと
今回の実験では、2Dキャラクターの正面画像1枚だけから、かなり完成度の高い3Dモデルを生成することができた。
特に、正面画像から確認できる顔、身体、腕、脚、スカーフなどは立体としてよく成立している。
一方、見えていない背面では状況が異なった。
AIは単に背面を空白にするのではなく、3Dキャラクターとして成立するように形状を補完した。
しかし、それは制作者が決定している公式デザインと一致するとは限らない。
今回の結果を整理すると、
画像から直接確認できる情報
→ 比較的忠実に3D化される。
画像から存在を推測できる情報
→ AIによって補完される場合がある。
画像から具体的な形状を判断できない情報
→ AI独自の形状として生成される可能性がある。
毛並みなどの細かな立体情報
→ 可視領域では再現されても、不可視領域まで同じ状態で連続するとは限らない。
という特徴が確認できた。
10 「失敗」ではなく、AIの役割を知る
今回、背面のリュックは公式デザインどおりにはならなかった。
頭部の毛並みも360度均一には生成されなかった。
しかし、これを単純に「AIでは正しく作れなかった」と評価するべきではない。
AIに与えられていない情報を、AIが正確に再現することはできない。
むしろ今回重要なのは、情報が存在しないにもかかわらず、AIが3Dモデルとして破綻しないよう背面まで補完したことである。
正面画像には存在しなかった尻尾状の形状まで生成されたことも、その特徴を示している。
AIによる3Dモデル制作では、
「AIが何を作れるか」だけではなく、「AIへどの情報を与える必要があるのか」
を設計することが重要になる。
次の実験へ
今回は、あえて正面画像1枚だけから3Dモデルを生成した。
しかし、人間側にはパンタの公式4面図が存在する。
今後、正面・左右側面・背面という複数方向の情報をAIへ与えることができれば、今回AIが独自に補完した背面形状を、公式デザインへ近づけられる可能性がある。
また、今回生成された約190万面の高密度モデルを、そのままゲームへ使用するわけではない。
今後はTripo StudioのSmart Meshやリトポロジー、テクスチャ、リギング、アニメーションなども順次検証し、
2D公式キャラクター
→ AIによる3D原型生成
→ ゲーム用3Dモデルへの最適化
→ アニメーション
→ Blenderでの検証・必要な修正
→ Unityへの実装
というAI時代の3Dゲーム素材制作ワークフローを、実制作を通して検証していく。
基本ゲームループ完成 ― Unity AI Agent、残り25クレジットでゲームを閉じる
AIゲーム開発研究室
「森のどんぐり大作戦」開発ドキュメント
基本ゲームループ完成 ― Unity AI Agent、残り25クレジットでゲームを閉じる
前回までの実装によって、
パンタ開始 → どんぐりをキャッチ → 大喜び → 退場 → ポン登場 → どんぐりをキャッチ → 大喜び
までが完成しました。
ゲームとして残されていたのは、その先です。
ポンが大喜びしたあと、どうなるのか。
ここまでどれだけ正常に動作しても、最後がなければゲームは終わりません。
そこで今回は、
「ポン大喜び → 退場 → ゲーム終了」
を実装し、「森のどんぐり大作戦」の基本ゲーム構造を最後までつなげることにしました。
ただし、一つ問題があります。
Unity AI Agentの残りクレジットは、
114 / 1,000
です。
かなり心細い数字になってきました。
今回は余計な実験をせず、既存システムをできるだけ利用して、ゲームを最後まで完成させることを優先します。
1．今回の目的
今回実装するゲーム終了までの流れは単純です。
ポンがどんぐりを3個キャッチする。
↓
ポンが大喜びする。
↓
しばらく大喜びを続ける。
↓
大喜びアニメーションを続けたまま、真下へ下降する。
↓
ポンが完全に画面外へ退場する。
↓
どんぐりの新規生成を停止する。
↓
「ゲームクリア！」
を表示する。
今回はゲーム終了後のメニュー画面、リスタート、結果画面などは作りません。
目的は、
ゲーム開始からゲーム終了までの基本構造を成立させること
です。
2．新しい仕組みを作らせない
Unity AI Agentへの指示では、今回も実装範囲を明確にしました。
特に重要視したのが、
既存のパンタ退場処理を調査し、その設計を参考にする
ことです。
パンタではすでに、
大喜び → 一定時間待機 → 大喜びしながら下降 → 完全に画面外へ退場
という処理が正常に動いています。
したがって、ポンのために別の複雑なシステムを新しく作る必要はありません。
また、前回修正したポンのアニメーション素材についても、
共通キャンバス
共通Sprite Rect
共通Pivot
を変更しないよう明示しました。
ポンの大喜びには、人間が生成画像を選別し、同一サイズの透明キャンバス内でキャラクター位置を調整することによって制作した上下動が、すでに含まれています。
したがって、Unity側で新たな上下ジャンプを加える必要はありません。
退場時に必要なのは、
GameObject全体をTransform Yで真下へ移動させること
だけです。
ここでも、
Sprite画像内で制作された動き
と、
Unityが担当するゲーム空間上の移動
を分離します。
3．ゲーム終了時の仕様
ポンが大喜びを開始すると、すでにBasketCatchAreaのColliderは無効になるよう実装されています。
そのため、退場中にどんぐりをキャッチすることはありません。
スコアは、
どんぐり：3 / 3
合計：6
の状態で止まります。
ポンが完全に画面外へ出たら、AcornSpawnerによる新しいどんぐりの生成を停止します。
その時点をゲーム終了としました。
そして既存のUIを利用して、画面中央付近へ、
「ゲームクリア！」
を表示します。
これだけです。
豪華なResult画面はありません。
しかし、今回必要なのは完成したゲーム画面ではなく、
ゲームというシステムが最後まで動作すること
です。
4．Unity AI Agentへ実装を依頼する
以上の条件をまとめ、Unity AI Agentへ実装を依頼しました。
今回の指示では、
- 既存実装を最初に確認する
- PantaMovementの退場処理を参考にする
- PonMovementへ必要最小限の処理を追加する
- ポンの既存アニメーションを変更しない
- Sprite Import設定を変更しない
- BasketCatchAreaの既存処理を維持する
- ポン退場後にAcornSpawnerを停止する
- 既存Canvasを利用して「ゲームクリア！」を表示する
- Scene遷移やリスタートなどは実装しない
- 不要なリファクタリングを行わない
ことを指定しました。
残りクレジットが少ないため、今回は特に、
必要のない仕事をAIにさせない
ことを重視しました。
5．突然のクレジット切れ
Unity AI Agentが作業を開始しました。
既存SceneやGameObject、Scriptを調査しながら、次々と処理を進めていきます。
そして画面には、
Completed actions (46)
と表示されました。
かなり多くの処理が行われています。
ところが、その直後です。
Unity Assistantの画面に赤い警告が表示されました。
Not enough credits remaining.
クレジットが足りません。
作業開始前には114あったクレジットが、実装途中でほぼ尽きてしまったのです。
しかもUnity AI Agentから、
「実装が完了しました」
という最終報告を受け取る前です。
これは困りました。
実装途中で止まったのであれば、ゲーム終了処理のどこまで完成しているのか分かりません。
しかし、画面を見るとUnity AI Agentは46個もの処理をすでに完了しています。
さらに作業内容には、
gameClearVisible
gameClearText
ponCurrentScore
totalScore
など、ゲーム終了状態を確認していたと思われる項目も見えます。
もしかすると、
実装そのものは終わっていて、最後の報告を行う前にクレジットが尽きただけなのではないか。
そこで追加の質問は行いませんでした。
残り少ないクレジットを使ってUnity AI Agentに状況確認をさせるのではなく、
人間がPlayして確認します。
6．Playボタンを押す
ゲームを最初から実行します。
パンタが登場します。
どんぐりを3個キャッチ。
どんぐり：3 / 3
パンタが大喜びします。
そのまま画面下へ退場。
同時にポンが画面下から登場します。
ポンが通常位置へ到着するとCurrent Scoreがリセットされます。
どんぐり：0 / 3
合計：3
ここまでは前回までに完成していた部分です。
続いてポンを操作します。
1個。
2個。
3個。
どんぐり：3 / 3
合計：6
ポンが大喜びを始めます。
そして――
そのまま大喜びしながら、画面下へ下降を始めました。
ポンは完全に画面外へ退場します。
新しいどんぐりも出現しなくなりました。
そして画面中央に、
ゲームクリア！
と表示されました。
全部できています。
7．Unity AI Agentは仕事を終えていた
結果として、
ポン大喜び
↓
下降開始
↓
完全退場
↓
どんぐり生成停止
↓
ゲームクリア表示
のすべてが正常に動作しました。
Unity AI Agentは、
「クレジット不足」
というエラーを表示して停止しました。
しかし、Unityプロジェクト側では要求した機能がすでに完成していました。
つまり今回、
AIとの対話上ではタスク完了報告まで到達していない
一方で、
実際のゲーム実装は完成している
という状態が発生しました。
ここにも一つ興味深い点があります。
AIの画面上に、
「完了しました」
と表示されたかどうかと、
実際の制作物が完成しているかどうか
は同じではありません。
最終的な判断対象は、AIの返答ではなく、
実際に動いているゲームそのもの
です。
8．残り25クレジット
実装後、Unity Cloudのクレジット管理画面を確認しました。
残っていたのは、
25 / 1,000クレジット
でした。
今回の実装開始時には114クレジットでした。
したがって今回使用したのは、
89クレジット
です。
Unity AI Agentは残りわずかなクレジットを使いながら、ゲーム終了までの処理を完成させてくれました。
最後の報告をする余力は残っていませんでしたが、ゲームそのものは完成していました。
そこでプロジェクトをしっかり保存し、
Unity AI Agentにはしばらく休暇を出すことにしました。
9．ゲームの基本構造が閉じた
今回の実装によって、「森のどんぐり大作戦」は次のようになりました。
ゲーム開始
↓
パンタ登場
↓
パンタを操作
↓
どんぐりを3個キャッチ
↓
パンタ大喜び
↓
パンタ退場
↓
ポン登場
↓
Current Scoreリセット
↓
ポンを操作
↓
どんぐりを3個キャッチ
↓
ポン大喜び
↓
ポン退場
↓
どんぐり生成停止
↓
ゲームクリア
これで、
開始から終了までゲームが一本につながりました。
もちろん、まだ完成版のゲームではありません。
キャラクターはパンタとポンしか実装されていません。
本来はコンタ、リン、ミミも登場します。
パンタのアクション素材も、今後5カット構成へ作り直す予定です。
UI、ゲームバランス、演出、Result画面なども、これから改良していくことになります。
しかし、それらは今後、
すでに成立したゲーム構造へ追加していく要素
になります。
これは大きな違いです。
10．人間とAIは何をしてゲームを作ったのか
ここまでの実制作を振り返ると、ゲームは一つのAIが自動的に作ったものではありません。
人間がゲームの方向を決めました。
ChatGPTとの対話によって仕様や実装方法を検討しました。
画像生成AIがキャラクターやアクション候補を生成しました。
人間が画像を選別し、必要に応じて同一キャンバス内で配置を調整し、ゲーム用アニメーション素材を制作しました。
Unity AI AgentがUnityプロジェクトを調査し、Script、Animator、Collider、UIなどを実装しました。
そして人間がPlayボタンを押しました。
動かなければ原因を探します。
違和感があれば、その理由を考えます。
AIへ調査を依頼します。
修正後、再びPlayします。
その繰り返しによって、ゲームが少しずつ成立していきました。
ここで起きていることは、
人間 → AI → 完成
という単純な工程ではありません。
設計 → 制作 → 実装 → 検証 → 発見 → 修正 → 再検証
という循環です。
そして、その各段階で人間と複数のAIが異なる役割を担っています。
11．「ゲームを作る」から「ゲームを育てる」へ
今回、最も重要なのは「ゲームクリア！」という文字が表示されたことではありません。
ゲームの基本構造が、
閉じた
ことです。
これまでは、常にゲームの先に未実装部分がありました。
パンタを動かせても、その先がない。
どんぐりをキャッチできても、交代できない。
交代できても、ポンが遊べない。
ポンが遊べても、ゲームが終わらない。
その一つ一つを実制作によって解決してきました。
そして今回、初めて最後まで到達しました。
ここから先は、
ゲームを成立させるための開発
から、
成立したゲームを育てていく開発
へ移ることができます。
キャラクターを増やす。
キャラクターごとの動きを作る。
難易度を調整する。
演出を加える。
UIを整える。
ゲーム世界を広げる。
さらに次のゲームへつなげる。
基本構造が存在することで、これらの作業はすべて同じ土台の上で行えるようになります。
今回の到達点
「森のどんぐり大作戦」の実制作を始めてから、画像生成AIによる素材制作、Unityへの配置、キャラクター移動、どんぐり落下、キャッチ判定、スコア、キャラクター交代、大喜び、退場など、一つずつ実装を積み重ねてきました。
そして今回、
ゲーム開始からゲーム終了までの基本ゲームループが完成しました。
Unity AI Agentの画面には、
Not enough credits remaining.
そしてUnity Cloudには、
残り25クレジット。
一方、UnityのGameビューには、
「ゲームクリア！」
と表示されています。
AIは最後の報告をする前に力尽きました。
しかし、ゲームは最後まで動いていました。
今回はここでUnityプロジェクトを保存します。
Unity AI Agentには休暇を取ってもらいます。
そして私たちは、ここまでの実制作によって何が分かったのかを整理し、再び研究へ戻ります。
論文からゲームを作るだけではありません。
ゲームを作ることで、論文もまた作られていきます。
「森のどんぐり大作戦」の基本構造は、これで完成です。
ポン実装編 ― AIが生成した「動き」はどこに記録されていたのか
AIゲーム開発研究室
「森のどんぐり大作戦」開発ドキュメント
ポン実装編 ― AIが生成した「動き」はどこに記録されていたのか
前回までの実装によって、パンタがどんぐりを3個キャッチすると大喜びし、そのまま画面下へ退場し、次のキャラクターであるポンが登場するところまで完成しました。
今回は、その続きとしてポンのゲームシステムを実装していきます。
目標は、
ポンがどんぐりをキャッチする
↓
キャラクターごとの取得数とゲーム全体の取得数を表示する
↓
3個キャッチすると操作を停止する
↓
ポンが大喜びする
というところまでです。
ところが今回、実装を進める中で予想していなかった重要な問題が見つかりました。
それは、画像生成AIによって制作されたアニメーション素材の「動き」の一部が、Unityへ読み込む過程で失われていたという問題です。
1．キャラクターごとの取得数と合計取得数
まず、スコア表示を整理しました。
これまでは単純に取得したどんぐりの数を表示していましたが、キャラクター交代を実装したことで、二種類の数字が必要になりました。
Current Score
現在操作しているキャラクターが取得したどんぐり数。
Total Score
ゲーム開始から全キャラクターが取得したどんぐりの累計数。
パンタが3個取得した場合、
どんぐり：3 / 3
合計：3
となります。
その後パンタが退場し、ポンの登場が完了した時点でCurrent Scoreだけをリセットします。
どんぐり：0 / 3
合計：3
そしてポンが1個取得すると、
どんぐり：1 / 3
合計：4
となります。
Unity AI Agentは既存のScoreManagerを拡張し、Current ScoreとTotal Scoreを同時に管理する構造を実装しました。
重要なのは、キャラクター交代の途中ではCurrent Scoreをリセットせず、ポンが通常プレイ位置へ到着した時点でリセットするようにしたことです。
これによって、パンタの退場中やポンの登場途中でスコア表示が不自然に切り替わることを防いでいます。
2．ポンにもどんぐりキャッチを実装する
次に、ポンがどんぐりをキャッチできるようにします。
パンタにはすでに、
BasketCatchArea
というどんぐりを受け取るための当たり判定が実装されています。
Unity AI Agentに既存システムを調査させたところ、この仕組みはパンタ専用に作り直す必要がなく、そのままポンにも利用できることが分かりました。
そこで新しいキャッチ用スクリプトを作るのではなく、既存のBasketCatchAreaをポンにも使用しました。
ただし、パンタとポンでは体形も籠の位置も異なります。
そのため、ポン用にColliderの位置だけを調整しました。
これによって、
共通のキャッチシステム
と
キャラクター固有の位置設定
を分離することができました。
実際にPlayモードで確認すると、ポンも正常にどんぐりをキャッチし、
1個目では、
どんぐり：1 / 3
合計：4
2個目では、
どんぐり：2 / 3
合計：5
3個目では、
どんぐり：3 / 3
合計：6
と正しく表示されました。
3．ポンの大喜びは、人間が構成する
パンタの大喜びアニメーションでは、少し変わった実験を行いました。
画像生成AIによって制作された7枚の独立した大喜びポーズをUnity AI Agentに見せ、
どの画像を使うか
どの順番にするか
どのタイミングで表示するか
をUnity AI Agent自身に判断させました。
その結果、Unity AI Agentは、
05 → 02 → 04 → 01 → 06 → 03 → 07
という、人間が事前に指定していない順序を構成しました。
Playモードで確認すると、これが予想以上に自然な大喜びアニメーションになりました。
今回は比較のため、ポンでは別の方法を試します。
画像生成AIが制作した8枚の大喜び候補から、人間が5枚を選択しました。
さらに、
01 → 02 → 03 → 04 → 05
という使用順序も人間が決定しました。
一方、各画像をどれくらいの時間表示するかについてはUnity AI Agentに任せました。
つまりパンタでは、
AIがポーズ選択・順序・時間を決定
したのに対して、ポンでは、
人間がポーズ選択・順序を決定し、AIが時間と実装を担当
します。
同じ大喜びアニメーションでも、人間とAIの役割分担を変えてみたわけです。
4．Unity AI Agentが決めたポンの時間
Unity AI Agentは、5枚を確認したうえで、
6fps
を採用しました。
各画像の表示時間は約0.167秒。
全体では約0.833秒です。
順序は指定通り、
01 → 02 → 03 → 04 → 05
です。
Unity AI Agentが6fpsを選択した理由は、既存のポンの待機・移動アニメーション、さらにパンタの大喜びアニメーションも6fpsで構成されており、ゲーム全体のテンポと統一できるためでした。
ここでは、人間がポーズの構成を決め、AIが既存ゲームの実装を参照しながら時間軸へ変換しています。
5．Playボタンを押して分かった二つの問題
Unity AI Agentからは、
「正常に実装完了」
という報告が返ってきました。
しかし、ここでいつものように人間がPlayボタンを押します。
すると二つの問題が見つかりました。
一つ目は、
大喜びになっても、どんぐりをキャッチし続ける
という問題です。
見た目は大喜び状態へ変わっていますが、BasketCatchAreaのColliderは動作したままでした。
そのため大喜びしているポンの近くをどんぐりが通ると、Current ScoreもTotal Scoreも増えてしまいます。
そこでCelebration開始と同時に、ポンのBasketCatchAreaのColliderだけを無効化するよう修正しました。
共通で使用しているBasketCatchArea.csそのものは変更していません。
これによってパンタには影響を与えず、ポンだけが大喜び開始後にキャッチできなくなりました。
ここでも、
見た目の状態が変わったことと、ゲーム内部の状態が変わったことは同じではない
ということが分かります。
6．もう一つの違和感
しかし、もう一つ気になることがありました。
ポンの大喜び素材は、制作した段階ではかなり大きく上下するアクションになっていました。
ところがUnity上では、
思ったほど上下していない。
最初はUnity側でTransformのY座標を動かす必要があるのではないかとも考えました。
しかし、そうではありません。
元画像を思い出すと、すでに画像そのものの中でポンの位置を上下させていました。
つまり5枚を同じ位置で切り替えるだけで、本来ならポンは上下して見えるはずなのです。
では、なぜ動かなかったのでしょうか。
7．消えていた「透明な運動情報」
Unity AI Agentに画像のImport状態を調査させました。
そこで原因が判明しました。
ポンの大喜び素材はすべて、
320×400
という同じサイズの透明キャンバス上に制作されていました。
そして、そのキャンバスの中でポンの位置そのものを上下させています。
ところがUnityへImportした際、キャラクターが描かれている部分だけが画像ごとに自動的にトリミングされていました。
さらに、切り取られたそれぞれのSpriteの中央がPivotになっていました。
つまり、
元画像ではポンが上にいる
↓
ポンの周囲だけ切り取る
↓
切り取った画像の中央をPivotにする
↓
Unity上では再び中央に表示される
ということが起きていました。
画像生成AIが作った上下位置の差が、UnityへのImportによって相殺されていたのです。
8．透明キャンバス全体をSpriteとして扱う
そこで大喜び素材5枚を、
Rect：320×400のキャンバス全体
Pivot：すべてCenter（0.5, 0.5）
に統一しました。
Transformによる上下移動は一切追加していません。
GameObjectそのものは同じ位置に置いたままです。
変えたのはSpriteのImport方法だけです。
Playボタンを押してみます。
すると――
ポンがめちゃくちゃ大喜びしました。
素材画像の中に最初から存在していた上下動が、そのままゲーム画面に現れたのです。
9．「いまいち飛んでいない」の正体
ここで、以前から感じていた別の違和感にも気づきました。
ポンの通常キャッチアクションです。
ポンのキャッチ素材も画像生成時には上下に跳ねるようなポーズとして制作していました。
しかしゲーム上では、
「いまいち飛んでいないな」
という印象がありました。
そこで、
Pon_Catch_Up
と
Pon_Catch_Right
についても同じ問題が起きていないか調査しました。
結果は同じでした。
10．Pon_Catch_Upでも運動情報が消えていた
Pon_Catch_Upの5枚は、すべて、
340×400
のキャンバスです。
しかし修正前には、それぞれ異なるSprite Rectでトリミングされていました。
特に上下位置を見ると、
01は y=0、
02は y=74、
03は y=82、
04は y=40、
05は y=0
からキャラクター部分が切り出されていました。
これは非常に分かりやすい結果です。
元画像では02、03でポンが明らかに上へ移動しています。
ところが、その位置からキャラクターだけを切り出して中央をPivotにしたため、Unity上ではその高さの違いが消えていました。
そこで5枚すべてを、
Rect：340×400
Pivot：Center（0.5, 0.5）
へ統一しました。
Transformによる上下移動は追加していません。
11．右移動でも同じことが起きていた
Pon_Catch_Rightでも同様でした。
こちらの5枚は、
400×400
です。
やはり各画像が個別にトリミングされており、03ではy=38、04ではy=31から切り取られていました。
これも、
Rect：400×400
Pivot：Center（0.5, 0.5）
へ統一しました。
右移動の場合は少し構造が違います。
上下方向のアクションはSprite画像そのものが担当します。
一方、画面右方向への移動はUnityのTransformが担当します。
つまり、
Sprite画像内の上下運動
＋
UnityによるX方向移動
によって、一つの右移動アクションが成立しています。
左移動では、このアニメーションをflipXによって反転しています。
12．動きにリズムが生まれた
修正後、再びPlayボタンを押しました。
今度は明らかに違いました。
停止中のキャッチでも、左右移動中のキャッチでも、ポンが上下に跳ねます。
これまで少し平坦に見えていた動きに、はっきりとしたリズムが生まれました。
しかもUnity側で新しいジャンプ処理を追加したわけではありません。
今回の修正では、
Scriptの変更はありませんでした。
画像生成AIが制作した素材には、最初からその動きが存在していたのです。
Unityへ受け渡す過程で、それが見えなくなっていただけでした。
13．透明部分は「何もない」のか
今回の実験から、非常に興味深いことが分かりました。
一般に透明PNGの透明部分は、
「何も描かれていない部分」
と考えがちです。
しかし、今回のアニメーション素材では違いました。
透明キャンバスの中で、
キャラクターがどこに存在しているか
その位置自体が、フレーム間の運動を表現していました。
つまり透明部分は、単なる余白ではありません。
キャラクターの空間的位置を記録するための座標空間
として機能していたのです。
したがって今回の素材では、
透明キャンバスそのものがアニメーション情報の一部
だったことになります。
14．AIからAIへ渡す途中で情報が失われる
今回の問題は、画像生成AIが正しく素材を作れなかったことが原因ではありません。
Unity AI Agentがアニメーションを作れなかったことが原因でもありません。
画像生成AIが作った素材には、すでに必要な上下動が存在していました。
問題が発生したのは、
画像生成AIによる素材制作
↓
PNG
↓
Unity Import
↓
Animation Clip
という工程の途中です。
生成物そのものでも、実装コードでもなく、
制作工程間の情報変換によって情報が失われていた
のです。
AI時代のゲーム開発では、複数のAIやソフトウェアを連携させることになります。
そのとき重要なのは、
それぞれのAIが正しく仕事をしたか
だけではありません。
一つの工程で作られた情報が、次の工程へ正しく受け渡されたか
を確認する必要があります。
15．人間が見つけたもの
Unity AI Agentは、それぞれの作業について実装完了を報告しました。
しかし、
「ポンがいまいち飛んでいない」
という違和感を感じたのは、人間でした。
大喜びアニメーションをPlayして、その違いがさらに明確になりました。
そこから原因を疑い、Unity AI Agentに調査させたことで、Import設定の問題が発見されました。
今回も、
AIが実装する
↓
人間がPlayする
↓
人間が違和感を発見する
↓
AIが原因を調査する
↓
AIが修正する
↓
人間が再びPlayして評価する
という循環が発生しています。
これはこれまで繰り返し現れてきた、
設計 → 制作 → 実装 → 検証 → 発見 → 再設計
というAIゲーム開発の循環そのものです。
16．今回得られた制作ルール
今回の実験から、今後の2Dアニメーション素材制作に使える重要なルールが得られました。
連続アクション用Spriteでは、透明キャンバス内におけるキャラクターの位置も運動情報の一部として扱う。
画像生成AIによって同一キャンバス内でキャラクターの上下位置を変化させている場合、Unity Import時に各フレームをキャラクター輪郭で個別にトリミングしてはなりません。
同一アクションを構成するSpriteは、
共通キャンバス
共通Sprite Rect
共通Pivot
を維持します。
そして、画像内ですでに上下動が設計されている場合には、Unity側でさらにTransform Yを動かす必要はありません。
一方、画面内を左右へ移動するようなゲーム上の移動についてはUnity側で制御します。
つまり、
素材が担当する動き
と
ゲームエンジンが担当する動き
を分離します。
17．ポンらしい動きが生まれた
今回の修正によって、ポンの動きはパンタとはかなり違うものになりました。
これは当初から数値で細かく設計した結果ではありません。
画像生成AIによって制作された複数のアクション素材を実際にゲームへ組み込み、Playし、その動きを見たことで、
「ポンはこう動くキャラクターなんだ」
という個性が見えてきました。
キャラクター設定から動きを作るだけではありません。
生成された動きを見ることで、キャラクターのゲーム上の個性が決まっていく。
ここでも、
設計 → 生成
だけではなく、
生成 → 発見 → 設計
という逆方向の流れが生まれています。
パンタについては、現在使用している3カット素材を今後5カット素材へ全面的に入れ替える予定です。
その際には、今回得られた共通キャンバスと共通Pivotのルールを最初から適用します。
今回の到達点
今回の実装によって、
パンタが3個キャッチ
↓
パンタ大喜び
↓
パンタ退場
↓
ポン登場
↓
Current Scoreを0へリセット
↓
ポンがどんぐりをキャッチ
↓
Current ScoreとTotal Scoreを同時管理
↓
ポンが3個キャッチ
↓
操作停止
↓
キャッチ判定停止
↓
ポン大喜び
までが完成しました。
ポンの大喜び、待機キャッチ、左右移動キャッチについても、画像生成時に素材へ組み込まれていた本来の上下運動が復元されました。
残る基本ゲームループは、
ポン大喜び → ポン退場 → ゲーム終了
です。
ただし、今回はここで実装を止めることにしました。
Unity AI Agentの残りクレジットは、
114 / 1,000
となりました。
次回はクレジットに余裕がある状態で、ポンの退場とゲーム終了を実装します。
大喜びからキャラクター交代までをAIに任せてみた
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時代のゲーム開発方法論そのものが、また一段進んだ一日になりました。
