Contact
AIゲーム開発研究室
AIはゲーム画面を組み立て、見た目を判断できるのか
AIゲーム開発研究室
ゲーム開発ドキュメント
Unity AI Agentによる実制作開始
AIはゲーム画面を組み立て、見た目を判断できるのか
前回の実験では、Unity AI Agentに自然言語で指示を与えることによって、GameObjectの作成、コンポーネントの追加、C#スクリプトの作成とアタッチ、さらにオブジェクトの移動まで実行できることを確認した。
これによって、
自然言語による指示だけで、AIはUnityを実装できるのか。
という最初の問いに対して、一つの大きな成果を得ることができた。
しかし、実際のゲーム開発はここからである。
今回は実験用のGameObjectではなく、これまで制作してきた実際のゲーム素材をUnityへ読み込み、
Unity AI Agentにゲーム画面そのものを組み立ててもらう。
いよいよ「森のどんぐり大作戦」の実制作へ入ることにした。
ゲーム素材をUnityへ読み込む
まず、これまで制作してきた素材ファイルを整理した。
素材のファイル名をUnityで扱いやすい英数字表記へ変更し、用途ごとにフォルダを分けた。
背景素材は、
Assets/Art/Backgrounds
キャラクター素材は、
Assets/Art/Characters/Panta
アイテム素材は、
Assets/Art/Items
へ配置した。
これによって、背景、キャラクター、どんぐりなど、ゲーム制作に必要な素材をUnity上で整理して管理できる状態になった。
今回は、この素材を人間が一つずつシーンへ配置するのではない。
ここからUnity AI Agentへ指示を与える。
AIに背景を配置させる
最初に、ゲームの基本背景を配置するようUnity AI Agentへ指示した。
使用する素材は、
Forest_Background.png
である。
Unity AI Agentは素材を認識し、SpriteRendererを持つGameObjectを作成してシーンへ配置した。
背景そのものの配置には成功した。
しかし、最初の状態ではゲーム画面全体を完全には覆っていなかった。
そこで、
Main Cameraの表示領域全体を背景で覆い、画像の縦横比は維持する
ように指示した。
Unity AI AgentはMain Cameraと背景画像の大きさを調べ、背景のScaleを計算して変更した。
その結果、1920×1080のゲーム画面全体を背景画像で覆うことができた。
ここで重要なのは、人間がScaleの数値を計算して入力したのではないことである。
人間が伝えたのは、
「ゲーム画面全体を背景で覆う」
という目的だけだった。
その目的を実現するために必要なUnity上の処理を、AIが判断して実行した。
上部前景を配置する
続いて、画面上部の枝葉素材、
Forest_Foreground_Top.png
を配置した。
これは背景画像の上へ重ねる前景素材である。
Unity AI Agentへ、画面上部へ配置し、背景より手前に表示するよう指示した。
AIはGameObjectを作成し、位置とScaleを調整し、SpriteRendererの描画順も設定した。
ゲーム画面を確認すると、背景の森の手前に枝葉が重なり、画面上部に自然な奥行きが生まれた。
下部前景を配置する
次に、
Forest_Foreground_Bottom.png
を使用して、ゲーム画面下部の草地を配置した。
こちらもUnity AI AgentがGameObjectを作成し、位置、大きさ、描画順を設定した。
これによって、
背景の森
上部の枝葉
下部の草地
という三つのレイヤーがUnity上で組み合わされた。
素材制作段階では別々の画像だったものが、初めてゲーム画面として一つになった。
ここまでの画面構成は、すべてUnity AI Agentへの自然言語による指示を中心として行っている。
そして、パンタ登場
背景と前景が完成したところで、いよいよパンタを登場させることにした。
使用したのは正面向きの、
Panta_Front.png
である。
Unity AI Agentへ、パンタをゲーム画面中央付近へ配置するよう指示した。
AIはパンタのGameObjectを作成し、SpriteRendererへ画像を設定してシーンへ配置した。
森の中に、初めてパンタが立った。
これまで別々に制作してきた背景、前景、キャラクターがUnity上で一つのゲーム画面として組み合わされた瞬間である。
AIに「自然な位置」を判断させる
ここで新しい問題が生まれた。
パンタを単純に画面下部へ置いただけでは、背景画像の上にキャラクター画像を貼り付けたように見える。
パンタは森の中に立っている。
したがって、着地しているときには、
足の一部が手前の草に隠れている方が自然である。
そこで今回は、具体的なY座標を指定しなかった。
Unity AI Agentには、
パンタを少し下へ移動し、足の一部だけが前景の草に自然に隠れる位置へ調整する
よう指示した。
すると、これまでとは少し違う動きが始まった。
AIが画面を見始めた
Unity AI AgentはパンタのY座標を変更した。
そして、
Capture 2D Scene
を実行しようとした。
画面キャプチャの許可を与えると、AIはシーンを確認した。
さらにパンタのY座標を変更した。
そして再び画面キャプチャを要求した。
つまり、
位置を変更する
↓
画面を確認する
↓
さらに位置を変更する
↓
もう一度画面を確認する
という処理を始めたのである。
最終的にパンタは、
Y = -2.85
付近へ配置された。
重要なのは、この数値を人間が指定したのではないということである。
人間が伝えたのは、
「足が下草に少し隠れる自然な位置」
という視覚的な目的だった。
AIはその目的を実現するため、自ら位置を変更し、画面を確認しながら調整した。
「数値を指定する」から「目的を伝える」へ
今回の実験で見えてきたものは、単なるUnity操作の自動化だけではない。
従来のUnity制作であれば、人間が画面を見ながら、
TransformのY座標を変更する。
画面を見る。
もう少し下げる。
再び画面を見る。
という調整を行う。
今回、この試行錯誤の一部をUnity AI Agentが行った。
人間は具体的な数値ではなく、
「どう見えてほしいのか」
を伝えた。
AIは、その目的をUnity上の具体的な操作へ変換した。
これは、前回確認した
自然言語 → Unity操作
から、さらに一歩進んだ結果である。
今回確認できたのは、
自然言語による目的の提示
↓
Unity上での操作
↓
結果の視覚的確認
↓
再調整
という流れである。
人間の役割はなくならない
ただし、AIが最終的な美的判断まで完全に行えることが確認されたわけではない。
今回のパンタの位置についても、人間から見ると少し低く感じる可能性がある。
一方で、使用している正面向きパンタはもともと足が短く、実際のゲームではジャンプアクションも使用する。
さらに、着地時には足が前景の草に少し隠れる必要がある。
そのため今回は、この位置を現時点での着地基準位置として採用することにした。
ここには、
AIが候補を作る。
人間がゲーム全体の目的から採否を判断する。
という役割分担が現れている。
AIが人間に代わってすべてを決定するのではない。
しかし、人間がUnityのすべての数値を直接操作する必要もない。
両者の間に、新しいゲーム制作の形が見え始めている。
今回の到達点
今回、Unity AI Agentによって、
実際のゲーム素材を読み込み、背景を配置し、前景を重ね、キャラクターを配置するところまで進んだ。
さらに最後には、
画面を確認しながらキャラクターの位置を調整する
という処理まで確認することができた。
前回は、
AIはUnityを操作できるのか。
という実験だった。
今回はそこから一歩進み、
AIは実際のゲーム画面を組み立てられるのか。
そして、
AIは結果を見ながら調整できるのか。
という実験になった。
少なくとも今回の範囲では、その両方について具体的な成果を得ることができた。
そして画面には今、
森があり、
草木があり、
その中にパンタが立っている。
まだゲームとしては動いていない。
しかしこれはもう、単なるUnity AI Agentの動作実験ではない。
「森のどんぐり大作戦」の実制作が始まったのである。
自然言語による指示だけで、AIはUnityを実装できるのか
ゲーム開発ドキュメント
Unity AI Agentによるゲーム実装実験
自然言語による指示だけで、AIはUnityを実装できるのか
これまで「森のどんぐり大作戦」では、キャラクター、背景、前景、どんぐりなど、ゲームに必要となる素材の制作を進めてきた。
そして今回、いよいよUnityによるゲーム実装へ入る。
ただし、本研究では、人間がUnityを操作し、AIにはC#スクリプトだけを書いてもらう、という方法を目指しているわけではない。
AIにスクリプトを書いてもらい、
人間がGameObjectを作り、
人間がスクリプトをアタッチし、
人間がComponentを追加し、
人間がInspectorを設定する。
それでは、ゲーム実装の主体は依然として人間である。
そこで今回は、さらに一歩踏み込むことにした。
自然言語による指示だけで、AIがUnity Editor内部の実装作業そのものをどこまで行えるのか。
Unity AI Agentを使用して、実際に検証する。
Unity AIを前提としたプロジェクトの作成
今回の実装環境には、
Unity 6.5（6000.5.8f1）
を使用した。
テンプレートには、
Universal 2D
を選択。
プロジェクト名は、
Omusubiyama
とした。
そして今回、特に重要なのが、
「AI Assistantを使用」
をONにした状態でプロジェクトを作成したことである。
今回Unityを使用する目的は、単にゲームを実装することではない。
AIがUnity内部のゲーム構築に、どこまで直接参加できるのか。
それ自体を検証する。
Unity AI Agentの導入
Unity Editorを起動し、
Window → AI → Assistant
からUnity AI Assistantを開いた。
Unity AIを使用するため、今回は14日間の無料トライアルを開始した。
しかし、これですぐ実験開始とはならなかった。
Assistantには、
Checkpoints setup failed
という警告が表示された。
AIにUnityを任せるための「戻り」
Checkpointは、AIがUnityプロジェクトへ変更を加える際、その変更前の状態を保存しておくための仕組みである。
AIによる実装では、
AIに変更させる
だけでは不十分である。
問題が発生した場合、
変更前へ戻れる
ことも重要になる。
画像生成AIによる素材制作でも、生成結果を比較し、必要なら前の状態へ戻ることは重要だった。
Unity実装では、それ以上に「戻り」が重要になる。
そこでCheckpointを使用できる状態にしてから実験を開始することにした。
エラーを確認したところ、Gitが見つからないことが原因だった。
そこでGit for Windowsを導入した。
導入直後にはUnity側で認識されなかったが、PCを再起動したところ、
System（git 2.55.0）
として正常に認識され、
Checkpoints setup successful
となった。
これで、AIにUnityを変更させるための実験環境が整った。
実験1 AIにGameObjectを作らせる
最初からゲーム本体を実装させることはしない。
まず確認したいことは、非常に単純である。
自然言語による指示だけで、AIはUnity Editorを実際に操作できるのか。
Unity AI Agentへ、次のプロンプトを入力した。
使用プロンプト
Create one empty GameObject in the current scene and name it AI_Test_Object.
Do not make any other changes.
指示したのは、
現在のSceneに空のGameObjectを一つ作成し、AI_Test_Objectという名前を付ける。
ただそれだけである。
Agentは処理に必要なコードを生成した。
内容を確認すると、
AI_Test_Object
というGameObjectを作成する処理が記述されていた。
実行を許可すると――
Hierarchyに、
AI_Test_Object
が出現した。
人間はUnityのメニューからGameObjectを作成していない。
自然言語でAIへ指示しただけである。
Unity AI AgentがUnity Editorを実際に変更できることが確認された。
実験2 Componentを追加し、Inspectorを設定する
GameObjectを作れることは確認できた。
しかし、それだけではゲーム実装とは言えない。
次に確認したのは、
既存のGameObjectをAIが認識し、Componentを追加し、そのパラメータまで設定できるのか。
ということである。
使用プロンプト
Add a Rigidbody2D component to AI_Test_Object.
Set its Gravity Scale to 0.
Do not make any other changes.
Agentは既存の AI_Test_Object を検索し、Rigidbody2Dがすでに存在するか確認したうえで、存在しない場合には追加する処理を生成した。
さらに、
Gravity Scale = 0
を設定する処理も生成した。
実行すると、
AI_Test_Object
のInspectorに、
Rigidbody 2D
が追加され、
Gravity Scale = 0
に設定された。
これによって、
GameObjectの生成だけでなく、Componentの追加とInspector相当のパラメータ設定までAIが実行できる
ことが確認された。
AIが止まった？
ところが、この実験中に一つ問題が発生した。
Agentへ指示を出しても、いつまでたっても処理が終わらない。
画面では処理中のように表示されている。
最初は、
PCの性能が足りないのではないか。
とも考えた。
しかし、よく画面を見ると、
Awaiting input...
と表示されていた。
さらに、
Assistant wants to Execute code
と表示され、
人間に、
Deny / View / Allow
の選択を求めていた。
つまり――
AIは止まっていたのではなかった。
人間からの許可を待っていたのである。
しかも、人間がそれに気づかなかったため、AIは長時間、何もせず待ち続けていた。
ここで今回の実験による副次的な発見があった。
AIは非常に辛抱強い。
AIへ与える権限を変更する
Unity AI Assistantの設定を確認すると、
Execute Generated C# Code
が、
Ask Permission
になっていた。
つまり、AIが生成したC#コードを実行するたびに、人間の許可を必要とする設定である。
そこで、
Ask Permission → Allow
へ変更した。
すべての権限を無条件にAIへ渡したわけではない。
今回必要となる、
生成したC#コードを実行する権限
だけを変更した。
そして再び実験を行った。
実験3 Colliderを追加し、数値を設定する
次に、既存の AI_Test_Object へBoxCollider2Dを追加させる。
使用プロンプト
Add a BoxCollider2D component to AI_Test_Object.
Set the BoxCollider2D Size to X = 2 and Y = 3.
Do not make any other changes.
すると――
驚くほど速く処理が完了した。
AI_Test_Object のInspectorには、
Box Collider 2D
が追加され、
Size X = 2
Size Y = 3
に設定された。
人間はComponentを追加していない。
Inspectorの数値も入力していない。
自然言語による指示だけで、
対象GameObjectの認識
→ Componentの追加
→ パラメータ設定
→ Unityへの反映
までが実行された。
同時に今回の実験では、もう一つ重要なことが分かった。
AI Agentの能力だけではなく、人間がAIへどのような権限を与えるかによって、開発フローそのものが大きく変化する。
これは今後、AIによるゲーム実装を考えるうえで重要な検討事項になる。
実験4 C#スクリプトを作り、GameObjectへアタッチする
最後に、さらに一段階進める。
今度は単なるComponent設定ではない。
AI自身にC#スクリプトを新規作成させ、それをGameObjectへアタッチさせる。
そして実際に動作させる。
Unity AI Agentへ、次の指示を行った。
使用プロンプト
Create a new C# script named AI_Test_Movement.
The script should make AI_Test_Object move slowly left and right automatically while the game is running.
Attach the AI_Test_Movement script to AI_Test_Object.
Do not modify or remove the existing Rigidbody2D or BoxCollider2D.
Do not make any other changes.
今回は、新しいファイルを作成するため、
Create file
の許可を求められた。
これはC#コードの実行とは別の権限である。
ファイル作成を許可すると、Agentは、
AI_Test_Movement.cs
を新規作成した。
さらに、
AI_Test_Objectへ自動的にアタッチ
した。
既存の、
Rigidbody2D
BoxCollider2D
も維持されている。
Inspectorにはスクリプトの公開パラメータも表示された。
ここまで、人間はC#コードを書いていない。
スクリプトファイルも作っていない。
GameObjectへのアタッチもしていない。
すべてAIが行った。
AIが作ったゲーム処理を実行する
最後にUnityのPlayボタンを押した。
すると、
AI_Test_ObjectのTransformのX座標が左右へ往復し始めた。
AIが作成したC#スクリプトが、Unity上で実際に動作したのである。
今回作ったもの自体は、左右へ動くだけの単純なGameObjectである。
しかし、この実験の目的はゲームを完成させることではない。
確認したかったのは、
AIがUnityの実装作業そのものを担当できるのか
ということである。
その問いに対して、今回の基礎実験では明確な結果が得られた。
今回の実験で確認できたこと
今回、人間は、
C#を書いていない。
Rigidbody2Dを手動で追加していない。
BoxCollider2Dを手動で追加していない。
Inspectorのパラメータを手動で設定していない。
生成されたスクリプトをGameObjectへ手動でアタッチしていない。
人間が行ったのは、
何を実装するのかを決めること。
AIへ自然言語で指示すること。
必要な権限を判断して与えること。
AIが行った結果を確認すること。
次に何を行うのかを判断すること。
である。
一方、AIは、
GameObjectの生成
既存GameObjectの認識
Componentの追加
パラメータの設定
C#スクリプトの生成
GameObjectへのアタッチ
実行可能な状態の構築
を担当した。
人間 → AI → Unity
これまでゲーム実装では、
人間 → Unity
という関係が基本だった。
人間がUnityを操作し、GameObjectを作り、Componentを追加し、Inspectorを設定し、スクリプトをアタッチする。
しかし今回の実験では、その間にAIが入った。
人間
↓
自然言語による実装指示
↓
AI Agent
↓
Unity
という新しい実装経路が、実際に成立した。
これは単に、
「AIにC#を書いてもらう」
ということではない。
人間が実装方針を決め、
AIへ指示し、
AIがUnity内部で実装し、
人間がその結果を確認して次の判断をする。
ゲーム実装における人間とAIの役割そのものが変化する可能性がある。
今回の実験は、まだ非常に小さな基礎実験にすぎない。
複数のGameObject。
ゲーム素材。
Prefab。
Collider同士の関係。
ゲーム進行。
キャラクター制御。
シーン管理。
エラーの発見と修正。
実際のゲーム制作では、これから検証しなければならないことが数多く残されている。
しかし少なくとも今回、
自然言語による指示から、AIによるUnity実装、そして実際の動作までを一本につなぐことができた。
ゲーム素材の制作を終え、
いよいよ「森のどんぐり大作戦」のUnity実装へ入ろうとしていたその入口で、
想定していた以上に大きな扉が開いた。
AIはゲーム開発を支援するだけなのか。
それとも、
人間と役割を分担し、ゲームそのものを実装する存在になり得るのか。
ここから、その答えを実際のゲーム制作によって確かめていく。
実装前に不足したキャラクター素材を追加制作する
AIゲーム開発ドキュメント
第28回 実装前に不足したキャラクター素材を追加制作する
ゲームの実装設計を進めたことで、パンタに新たなキャラクター素材が必要であることが分かった。
必要になったのは、ゲーム中のキャラクター交代時や終了時などに使用する「大喜び」のアクションである。
当初の素材設計では想定していなかったが、実際のゲームの動きを具体的に考えていく中で必要性が明らかになった。
そこで、実装へ進む前にいったん素材制作へ戻り、パンタの追加画像を制作することにした。
連続アニメーションを作らせない
これまでの実験では、生成AIに歩行などの連続した動作を一度に制作させた場合、足の運びやポーズの連続性を正確に制御することが難しかった。
そこで今回は、完成したアニメーションそのものを生成AIに作らせる方法を採用しなかった。
生成AIには、
「大喜びしているパンタの異なるポーズを複数制作する」
ことを求めた。
実際のジャンプや上下移動などは、画像として描かせるのではなく、Unity側で制御する。
つまり、
画像生成AIには「ポーズ」を作らせ、ゲーム上の「動き」はUnityで作る。
という役割分担である。
「違うポーズ」を言葉で定義する
しかし、単に、
「違う喜びのポーズを複数作ってください」
と指示しただけでは、腕の位置だけが少し違う、ほとんど同じ画像が生成される可能性がある。
そこで今回のプロンプトでは、ポーズの違いを具体的に言語化した。
- 腕の位置を変える
- 脚の位置を変える
- 身体の傾きを変える
- 左右への重心移動を変える
- 表情を変える
重要なのは、
「差分を作るために、身体のどこを変化させるのか」まで言語化したこと
である。
その結果、顔の向きも含め、身体全体の動きが異なる7種類の大喜びポーズが生成された。
単なる腕の差分ではなく、身体全体の重心やシルエットが異なる素材を得ることができた。
生成された画像の中から必要なポーズを選択し、Unity側の動きと組み合わせてゲーム内のアクションとして使用する。
「イラスト」から「ゲーム素材」へ変換する制作工程
今回も、人間による加工を経て、大喜びしているパンタの素材を完成させた。
実装設計から素材制作へ戻る
今回、もう一つ重要だったのは、ゲーム開発の工程が一方向には進まなかったことである。
素材制作が終わったから実装する。
それだけではなかった。
実装方法を具体的に考えたことで不足している素材が判明し、再び素材制作へ戻った。
設計
→ 素材制作
→ 実装設計
→ 不足素材の発見
→ 素材制作へ戻る
→ 実装
という流れが実際に発生したのである。
これは失敗による後戻りではない。
実装を具体化したからこそ発見できた、新たな制作条件である。
AIを利用したゲーム開発においても、最初にすべてを決めて一本道を進むのではなく、制作と実装を往復しながら必要なものを発見していく。
今回のパンタの追加素材制作は、その「戻り」が実際の制作工程の一部であることを示す実例となった。
今回使用したプロンプト
以下が、今回パンタの「大喜び」素材を制作するために画像生成AIへ入力したプロンプトである。
森のどんぐり大作戦
パンタ 大喜びアクション素材 制作プロンプト Ver.1.1
制作目的
2Dゲーム「森のどんぐり大作戦」に使用する、
パンタの「大喜び」アクション素材
を制作してください。
ゲームクリア時、キャラクター交代時、登場シーンなどで使用できる、パンタらしい元気でかわいい喜びのポーズを複数制作します。
生成されたポーズの中から、最終的に3カット程度を選び、ゲーム内の喜びアクションとして使用します。
使用する基準画像
添付する
「パンタ キャラクターマスター（公式基準画像）」
を必ず基準画像として使用してください。
以下のデザインを忠実に維持してください。
- 顔
- 耳
- 目の周囲の黒い模様
- 丸く大きな体形
- 白黒の毛並み
- 手足の太さ
- キャラクター全体の柔らかな水彩表現
- 青いリュック
特に、
青いリュックは必ず背負わせてください。
喜びのポーズによってリュックが消えたり、別の形になったりしないようにしてください。
アクション
パンタが、
「やったー！」と大喜びしている瞬間
を表現してください。
ただし、今回はジャンプアニメーションそのものを制作するのではありません。
パンタの足は地面についている状態にしてください。
ジャンプや上下移動はゲーム実装時にUnity側で行います。
そのため、画像内ではパンタ自身を空中に浮かせないでください。
喜びポーズのバリエーション
同じポーズを繰り返すのではなく、
身体の動きがはっきり異なる複数の喜びポーズ
を制作してください。
例えば、
- 両手を高く上げて大喜びする
- 両手を左右に大きく広げる
- 片手を高く上げ、もう片方の手を横に広げる
- 両手を胸の近くまで引き寄せ、うれしそうに力を込める
- 身体を少し左右どちらかへ傾けながら喜ぶ
- 胸を張って誇らしそうに喜ぶ
など、
シルエットを見ただけでも違いが分かるポーズ
にしてください。
重心の変化
単純に腕の形だけを変えないでください。
各ポーズで、
パンタの身体全体の重心を変化させてください。
例えば、
- 重心が中央
- 少し左脚側へ重心を移す
- 少し右脚側へ重心を移す
- 身体を少し左へ傾ける
- 身体を少し右へ傾ける
- 胸を張って上半身を少し伸ばす
など、
身体全体を使って喜びを表現してください。
ただし、
転びそうな極端な傾きにはしないでください。
ゲームキャラクターとして自然に成立する範囲にしてください。
足のポーズ
足の形もすべて同じにしないでください。
- 両足を自然に開く
- 片足を少し前へ出す
- 片足を少し横へ出す
- 膝を少し曲げる
- 左右どちらかの脚に重心を乗せる
など、上半身の動きに合わせて自然に変化させてください。
ただし、
両足の少なくとも一部は地面に接している状態
にしてください。
ジャンプしているポーズにはしないでください。
表情
パンタらしい、
非常にうれしそうな表情
にしてください。
表情にも少し変化をつけてください。
- 大きな笑顔
- 口を開けた満面の笑顔
- 口を閉じたうれしそうな笑顔
- 目を少し細めた笑顔
などを混ぜてください。
すべて同じ顔にしないでください。
ただし、パンタの顔そのもののデザインは変更しないでください。
籠について
籠は持たせないでください。
今回は喜びアクション専用素材です。
リュックについて
青いリュックは必須です。
パンタが腕を上げたり身体を傾けたりしても、リュックは背中に自然に装着された状態を維持してください。
背景
背景は完全な透明にしてください。
白背景、単色背景、森、地面、影、装飾などは描かないでください。
パンタだけの独立したゲーム素材にしてください。
重要事項
今回の目的は、
完成した連続アニメーションを一度に作ることではありません。
まず、
パンタの喜びを表現する、異なる複数のポーズ候補を制作すること
が目的です。
生成された候補を人間が確認し、その中からゲームアクションとして自然につながる3カット程度を選択します。
したがって、
無理に連続動作として整合させるより、それぞれのポーズの違いと表情の豊かさを優先してください。
禁止事項
- パンタのキャラクターデザインを変更しない
- 青いリュックを消さない
- 籠を持たせない
- どんぐりを持たせない
- 空中に浮かせない
- ジャンプさせない
- 全カットを同じポーズにしない
- 腕だけを変えて身体を同じ姿勢にしない
- 全カットを同じ表情にしない
- 背景を描かない
- 地面や影を描かない
- 文字を入れない
パンタらしい、見ているだけで「やったー！」という声が聞こえてきそうな、元気でかわいい大喜びのポーズを複数制作してください。
こうして、実装に必要なパンタの追加素材が揃った。
そして今回の制作によって、
「異なるポーズを作れ」と指示するだけではなく、何を変化させれば異なるポーズになるのかを言語化する。
という、画像生成AIによるゲーム素材制作の新たな方法も確認することができた。
次はいよいよ、これまで制作してきた素材をUnityへ持ち込み、実際のゲームとして動かしていく。
森のどんぐり大作戦 ゲーム実装設計書 Ver.1.0
森のどんぐり大作戦
ゲーム実装設計書 Ver.1.0
AIゲーム開発研究室
1．制作目的
本設計書は、「おむすび山のなかまたち」に収録するミニゲーム、
「森のどんぐり大作戦」
をUnityで実装するための基本設計を定めるものである。
最初からゲーム全体の構造を設計したうえで、実装作業そのものは小さな工程に分割し、
実装 → 実行 → 確認 → 修正 → 次工程
を繰り返しながら完成させる。
2．「おむすび山のなかまたち」全体構造
「おむすび山のなかまたち」は、一つのゲームだけで構成される作品ではない。
絵本と複数のミニゲームから構成される、一つの世界全体を楽しむ作品
として設計する。
「森のどんぐり大作戦」は、その中に収録される最初のミニゲームである。
3．基本メニュー構成
ゲーム起動後、まず「おむすび山のなかまたち」の表紙を表示する。
表紙からメニュー画面へ進み、基本的には次の遊び方を選択できる構造とする。
絵本コース
初めてプレイする人を基本対象とする、本編となるコース。
絵本を順番に読み進め、その物語の中でミニゲームが発生する。
絵本
↓
ミニゲーム
↓
絵本の続き
↓
次のミニゲーム
という流れで「おむすび山」の世界を体験する。
絵本は物語の区切りごとに最初から表示する。
既に読んだ部分については、プレイヤー自身がページを進めることで読み飛ばすことができる。
ゲーム自由選択コース
基本的には、絵本コースを最後まで体験した後に利用する。
収録されているミニゲームの中から、好きなゲームを自由に選択して遊ぶ。
各ミニゲームは独立したUnity Sceneとして制作し、後から新しいゲームを追加できる構造とする。
絵本だけを読む
ミニゲームを行わず、制作した絵本だけを連続して読むことができる。
森を見に行く
累計どんぐりポイントによって変化していく森を鑑賞する。
ゲーム性は持たせず、豊かになっていく森そのものを楽しむ、ご褒美となる場所とする。
4．進行状態とどんぐりポイント
絵本コースでは、ゲームの進行状態を保存する。
次回起動時には、
「つづきから」
を基本とする。
「つづきから」を選択した場合、それまでに獲得したどんぐりポイントも継続する。
一方、
「最初から」
を選択した場合は、絵本コースを最初から開始し、どんぐりポイントも0から開始する。
絵本コース終了後、自由選択コースへ移行する際には、絵本コースで獲得したどんぐりポイントを、
継続する／継続しない
からプレイヤー自身が選択できる構造とする。
5．どんぐりポイントと森の変化
各ミニゲームで獲得したどんぐりは、累計どんぐりポイントとして蓄積する。
ポイントが増えることで、ご褒美画面となる森が少しずつ豊かになっていく。
植物が増える。
木々が豊かになる。
生き物が増える。
森が明るく、生き生きとしていく。
ここには勝敗を設けない。
どんぐりを集める
↓
森が豊かになる
↓
変化した森を見ることが楽しい
↓
またどんぐりを集めたくなる
という循環を作る。
6．今回の実制作範囲
今回実制作するのは、
「森のどんぐり大作戦」
である。
対象プラットフォームは、まずPCとする。
スマートフォン、タブレット等への対応は、PC版完成後に必要に応じて検討する。
7．森のどんぐり大作戦・基本ルール
森の中で、上から次々と落ちてくるどんぐりを、キャラクターが籠でキャッチする。
どんぐりはゲーム開始から終了まで、継続して落下する。
キャラクターは、
パンタ
リン
ミミ
コンタ
ポン
の5人。
最初に登場するキャラクターは、必ずパンタとする。
その後の、
リン・ミミ・コンタ・ポン
の登場順はランダムとする。
同一プレイ内では、それぞれ1回ずつ登場する。
8．ゲーム開始
今回の実制作では、ゲーム開始確認用として仮の表紙を用意する。
表紙から「森のどんぐり大作戦」の通常ゲームSceneへ移動する。
Scene開始とともに、森ではどんぐりの落下が始まる。
その後、
パンタが画面中央の地面下から、垂直ジャンプして登場する。
この登場ジャンプは、Unity側のプログラムによって行う。
9．キャラクターの基本動作
パンタが着地するとプレイヤー操作を開始する。
入力なし
その場で、
垂直小ジャンプ待機
を続ける。
右移動
右矢印キー または Dキー
で右方向へ移動する。
移動中は、制作済みの右方向ジャンプアクション素材を使用する。
左移動
左矢印キー または Aキー
で左方向へ移動する。
移動中は、左方向用のジャンプアクションを使用する。
必要に応じて既存素材の左右反転を利用する。
10．ジャンプの扱い
通常プレイ中のジャンプ動作は、Unityの物理演算によってキャラクターそのものをジャンプさせるものではない。
ジャンプの上下動は、制作済みのキャラクター素材の中に含まれている。
したがって通常の待機・左右移動について、プログラム側でジャンプ量を設定する必要はない。
プログラムによる上下移動を使用するのは、基本的に、
キャラクター登場時の垂直ジャンプ
である。
11．どんぐりの発生
どんぐりは、通常ゲームScene開始から終了まで継続して発生する。
画面上端の左から右まで、横幅全域のさまざまな位置からランダムに出現する。
森ではどんぐりが豊かに実っているため、キャラクター交代中も落下を停止させない。
どんぐりの、
発生間隔
同時出現数
発生量
などの具体的数値は、この段階では固定しない。
Unity上で実際にプレイしながら決定する。
12．どんぐりの落下
どんぐりには基本的に、
Rigidbody2D
＋
Collider2D
を使用する。
UnityのPhysics 2Dによる重力を利用して落下させる。
どんぐりは落下しながら回転する。
具体的な、
Gravity Scale
回転速度
などは、Unity上で実際のゲーム画面を確認しながら調整する。
物理的に正しい落下を再現することを目的とはしない。
プレイヤーが見つけやすく、追いかけやすく、キャッチして楽しい落下
を基準として調整する。
13．どんぐりのキャッチ判定
キャラクターが持つ籠にCollider2Dを設定する。
落下してきたどんぐりが籠のCollider2Dへ接触した瞬間、
キャッチ成功
と判定する。
キャッチされたどんぐりは、その瞬間に消去する。
同時に、
獲得どんぐり数 ＋1
とする。
籠の中へ物理的にどんぐりを残す処理は行わない。
画面下部まで落下してキャッチされなかったどんぐりも消去する。
落としたことによる減点や失敗判定は設けない。
14．ゲームは時間制とする
キャラクター1人あたりのプレイは時間制とする。
取得個数による終了条件は設けない。
制限時間内であれば、何個でもどんぐりを取得できる。
1キャラクターあたりの具体的な制限時間は、この段階では決定しない。
どんぐりの発生量、落下速度、キャラクターの移動速度などをUnity上で確認し、
実際に遊んで楽しい時間
を基準として決定する。
15．キャラクター交代
各キャラクターの制限時間が終了すると、プレイヤー操作を停止する。
その後、
籠を持っていない喜びアクション
へ切り替える。
獲得数が何個であっても同じである。
0個でも大喜びする。
喜びアクションを行った状態のまま、そのキャラクターがいる位置から画面下へ沈み、退場する。
退場後、次のキャラクターが、
画面中央の地面下から垂直ジャンプして登場する。
着地後、次のキャラクターのプレイを開始する。
この間も、どんぐりは継続して落下する。
16．喜びアクション
喜びアクションは、
3カット程度
を基本として制作する。
厳密な連続アニメーションではなく、異なる喜びポーズを切り替えることで、大喜びしている状態を表現する。
喜びアクション中、キャラクターは籠を持たない。
これによって、
籠あり＝プレイ中
籠なし＝プレイ終了
という状態の違いを視覚的に示す。
まずパンタの3カット程度を制作し、Unity上で実装・検証する。
問題がなければ、後からリン、ミミ、コンタ、ポンへ展開する。
17．5人目終了後
5人目も他のキャラクターと同じように、
制限時間終了
↓
籠なしで大喜び
↓
喜びながら画面下へ退場
する。
ここで通常ゲームSceneを終了する。
その後、
エンディング・結果Scene
へ切り替える。
18．エンディングScene
エンディングSceneへ切り替わった後、少し間を置いて、
パンタ・リン・ミミ・コンタ・ポンの5人全員が、地面下から一斉に垂直ジャンプして登場する。
5人とも籠は持たない。
登場後、全員が喜びアクションを行う。
その状態を維持したまま、背景がじわっとエンディング用背景へ変化していく。
19．エンディング背景
エンディング背景は、通常ゲームで使用した森の中とは異なる、開放感のある風景とする。
基本要素は、
青空
おむすび山
小川
森
とする。
深い森の中で遊んでいたゲーム画面から、視界の開けた明るい風景へ移ることで、
森の中から外へ出たような解放感
を表現する。
20．結果表示
5人が大喜びしている状態で、今回獲得したどんぐりの合計数を表示する。
基本表示は、
「みんなで ○○こ あつめたよ！」
とする。
獲得数によるランク付けは行わない。
成功・失敗の評価も行わない。
0個であっても、5人は同じように大喜びする。
今回獲得したどんぐりは、累計どんぐりポイントへ加算する。
21．エンディング画面の終了
エンディングは一定時間が経過すると自動的に終了する方式にはしない。
プレイヤーが次の操作を行うまで、5人が喜んでいる結果画面を維持する。
将来的には、
もういちど遊ぶ
森を見に行く
もどる
おはなしのつづきへ
など、ゲームへ入った経路に応じた選択肢を表示する。
具体的なボタン構成は後の設計で決定する。
22．通常ゲームSceneの基本レイヤー
通常ゲーム画面は、おおむね次の前後関係で構成する。
上部前景・枝葉
ゲームUI
落下どんぐり
キャラクター
下部前景・草地
背景
実際のSorting LayerおよびOrder in Layerについては、Unity上で画面を確認しながら決定する。
特にどんぐり、上部枝葉、キャラクターの前後関係については、実際の見え方を確認して調整する。
23．UI
通常ゲーム中には最低限、
現在の獲得どんぐり数
残り時間
を表示する。
必要に応じて、
現在のキャラクター
などの情報を追加する。
UIの具体的なデザイン、位置、大きさについては、背景・前景・キャラクターをUnity上へ配置した後に設計する。
24．現在不足している素材
現時点で新たに制作が必要であることが確認された素材は、次のとおり。
パンタ喜びアクション
3カット程度
籠なし。
背景透明。
通常ゲームでの退場およびエンディングで使用する。
エンディング背景
青空、おむすび山、小川、森を基本とした、明るく開放感のある絵本世界の背景。
その他の不足素材については、Unity実装を進めながら確認する。
25．Unity実装の基本方針
完成した設計を一度にすべて実装しない。
小さな工程に分割し、一工程ごとに実行・確認する。
基本的には、
第1段階 Unityプロジェクト・Scene作成
↓
第2段階 背景・上下前景の配置
↓
第3段階 パンタの配置
↓
第4段階 パンタの垂直小ジャンプ待機
↓
第5段階 左右キー／A・Dによる左右移動
↓
第6段階 パンタ登場時の垂直ジャンプ
↓
第7段階 どんぐりの生成
↓
第8段階 Rigidbody2Dによる落下・回転
↓
第9段階 籠とのキャッチ判定
↓
第10段階 どんぐり獲得数のカウント
↓
第11段階 制限時間・タイマー
↓
第12段階 パンタ喜びアクション
↓
第13段階 喜びながら沈む退場処理
↓
第14段階 キャラクター交代システム
↓
第15段階 5キャラクターへの展開
↓
第16段階 エンディングScene
↓
第17段階 5人同時登場・喜びアクション
↓
第18段階 エンディング背景への変化
↓
第19段階 結果表示
↓
第20段階 累計どんぐりポイント・保存
↓
第21段階 ゲーム全体の通しプレイ
↓
第22段階 ゲームバランス調整
と進める。
26．Unity上で決定する調整項目
以下については、設計段階で数値を固定しない。
キャラクターの左右移動速度
キャラクター1人あたりの制限時間
どんぐりの発生間隔
どんぐりの発生量
同時に存在するどんぐり数
どんぐりのGravity Scale
どんぐりの回転速度
Colliderの大きさ
各キャラクターの表示サイズと位置
背景・前景の表示サイズと位置
UIの位置と大きさ
これらは、Unity上で実際にゲームを動かし、
視認性
操作性
楽しさ
絵としての美しさ
を確認しながら決定する。
通常プレイ時のキャラクターのジャンプ量については、制作済み素材の中で決まっているため、調整項目とはしない。
27．実装上の基本思想
本ゲームでは、必要以上に複雑なシステムを作らない。
Unity標準機能で実現できるものについては、まず標準機能を使用する。
どんぐりの落下についても、
Rigidbody2D ＋ Collider2D
による単純なPhysics 2Dから実装する。
実際に問題が発生した場合にのみ、追加制御を検討する。
同様に、キャラクターアニメーションについても、複雑な自動生成や高度な制御を前提とせず、制作済みの画像素材を活用して構成する。
28．実装設計 Ver.1.0 の基本方針
「森のどんぐり大作戦」は、
豊かな森から次々と落ちてくるどんぐりを、5人の仲間たちが楽しみながら集めるゲーム
である。
勝敗を競うことを中心には置かない。
たくさん取れても楽しい。
少ししか取れなくても楽しい。
0個でもみんなで大喜びする。
そして集めたどんぐりは無駄にならず、累計され、
森そのものを少しずつ豊かにしていく。
ゲームを繰り返し遊ぶ理由は、より高い評価を得るためだけではない。
自分たちが遊ぶことで、「おむすび山」の世界が少しずつ楽しく、豊かになっていく。
その体験を、「森のどんぐり大作戦」の基本的なゲーム設計とする。
森のどんぐり大作戦
ゲーム実装設計書 Ver.1.0
以上
第27回 ゲーム背景の実制作 ― AI生成素材を一つのゲーム世界へ統合する
AIゲーム開発ドキュメント
第27回 ゲーム背景の実制作
― AI生成素材を一つのゲーム世界へ統合する ―
前回までの検討によって、ゲーム「森のどんぐり大作戦」に必要となるキャラクター素材の制作方法について、一定の方針を定めることができました。
今回は、実際にゲームで使用する背景の制作を行います。
今回の目的は、単に生成AIに「ゲーム背景を一枚描いてもらう」ことではありません。
まず背景となる一枚の画像を制作し、さらにその手前に配置する枝葉や草地を独立した素材として制作します。
そして、それらを人間が加工・配置・色調補正し、一つのゲーム画面として統合していきます。
1．まず背景画像を制作する
最初に、ゲームの舞台となる「どんぐりの森」の背景画像を画像生成AIで制作しました。
完成した背景画像は、
1536×1024px
でした。
この画像は3:2の比率であり、一般的な16:9のゲーム画面とは比率が異なります。
しかし今回は、この背景画像を16:9へ変形したり、トリミングして新しい画像を作ったりすることはしません。
生成された1536×1024pxの背景原画を、そのままゲーム素材として使用することにしました。
必要があれば色調補正は行いますが、画像そのもののサイズは変更しません。
2．背景だけではなく、前景を別素材として制作する
背景画像をゲーム画面として検討していくと、一枚の背景画像だけで画面を完成させるのではなく、その手前に別の植物を配置した方が、森の奥行きを表現できると考えました。
そこで、
画面上部の枝葉
と、
画面下部の草地
を、背景とは別の透明PNG素材として画像生成AIに制作させました。
上部の枝葉は、画面の手前に木々が存在していることを感じさせます。
下部の草地は、キャラクターのさらに手前に植物を配置することで、キャラクターが森の中に存在している感覚を作ります。
さらに下部には、短い草が密集した「草の地面ベース」も制作しました。
これによって、
背景
＋ 上部の枝葉
＋ 下部の草地
＋ 草の地面ベース
という複数レイヤーによって、ゲーム背景を構成することにしました。
3．生成された素材のサイズは揃っていなかった
画像生成AIによって制作された素材は、すべて同じ画像サイズではありませんでした。
背景画像は、
1536×1024px
です。
一方、前景として制作した枝葉や草地には、
幅2048px
のものと、
幅2172px
のものがありました。
そこで前景素材については、人間が加工を行い、
幅2048px
に統一しました。
ただし、背景画像については1536×1024pxの原画を維持しています。
つまり今回の制作では、
すべてのゲーム素材を同じピクセルサイズに統一したわけではありません。
4．16:9のゲーム画面を想定した作業ファイルを作る
次に、実際のゲーム画面を想定して、16:9で確認できる作業環境を作りました。
ここで重要なのは、
背景画像を16:9の画像へ作り直したわけではない
ということです。
作業画面は、幅2048pxに統一した上下の前景素材を基準として構成しました。
そこへ1536×1024pxの背景原画を配置します。
そのため16:9のシミュレーション画面では、背景画像全体が表示されるのではなく、背景原画の中央付近がゲーム画面として見えている状態になります。
これはゲーム用背景の最終サイズを決定するための作業ではありません。
あくまで、
「実際に16:9のゲーム画面として見た場合、どのように見えるのか」
を確認するためのシミュレーションです。
5．すべての素材をレイヤーとして一つのファイルにまとめる
背景、上部の枝葉、下部の草地などを、それぞれ独立したレイヤーとして一つの制作ファイルへまとめました。
ここでは画像を一枚に結合してしまうのではありません。
それぞれを独立したレイヤーとして保持します。
そして実際のゲーム画面を見ながら、
枝葉の位置、
草地の位置、
素材の重なり、
左右反転、
不要部分の処理、
植物の密度
などを調整していきます。
この段階で重要なのは、個々の素材だけを見て完成させないことです。
最終的にプレイヤーが見るのは、一つ一つの素材ではありません。
すべてが重なったゲーム画面です。
そのため、
ゲーム画面全体を一枚の絵として見ながら、各素材を調整しました。
6．人間が色調補正を行う
今回、背景、枝葉、草地は、それぞれ別々に画像生成AIによって制作されています。
同じ水彩絵本風の画風を指定していても、それだけですべての素材の色彩が完全に統一されるわけではありません。
そこで人間が、
明度、
彩度、
色相、
コントラスト
などを調整しました。
しかも、それぞれの素材を単独で見ながら補正するのではありません。
背景、枝葉、草地を重ねた状態を見ながら、
一つの絵として自然に見えるように色調を合わせていきます。
今回、別々に生成された背景、枝葉、草地が一つの森として見えるようになったのは、画像生成AIが最初から完全に同じ色彩で素材を生成したからではありません。
人間による画像加工と色調補正によって、一つの世界として統合した結果です。
この工程は、AIによるゲーム素材制作において重要な人間側の作業になると考えられます。
7．まず「一枚の絵」として完成させる
加工と色調補正を繰り返しながら、16:9のゲーム画面として全体を確認します。
ここでは、Unityへ持ち込むための個別素材を完成させることを先に考えるのではなく、
まずゲーム画面そのものを一枚の絵として完成させる
ことを優先しました。
上部には手前の枝葉があります。
中央には明るい森が広がっています。
下部には豊かな草地があります。
この前景と背景の重なりによって、単なる森の背景ではなく、
「森の中でゲームをしている」
と感じられる画面を作っていきました。
8．パンタを原寸のまま配置して確認する
背景画面が完成したところで、実際のキャラクターであるパンタを配置してみました。
ここでも、パンタの画像サイズは変更していません。
制作済みのパンタを原寸のまま仮配置しています。
そのため、現在のシミュレーション画面では、パンタが少し小さく見える可能性があります。
しかし、この段階では問題ありません。
今回確認したいのは、
背景の中でパンタを認識できるか、
草地との重なりが自然に見えるか、
キャラクターが森の中に存在しているように見えるか、
といった視覚的な問題です。
実際のゲームにおけるパンタの表示サイズや位置は、Unityへ実装した後に調整します。
したがって、このシミュレーション画像だけを基準としてパンタの原画を拡大・縮小することはしません。
9．落下するどんぐりも配置する
次に、ゲーム中に上から落下するどんぐりの素材を画像生成AIで制作しました。
どんぐりは単なる背景の装飾ではありません。
プレイヤーがパンタを操作し、
追いかけ、
籠でキャッチする、
ゲーム上の重要な対象物です。
そのため、どんぐりには背景の中でも十分に認識できる視認性が必要になります。
実際にパンタと一緒に配置し、両者の見え方を確認しました。
ここでいうパンタとどんぐりの比率は、現実世界における物理的な縮尺を意味するものではありません。
パンタの籠の中に描かれているどんぐりと、落下するどんぐりの大きさを一致させる必要もありません。
重要なのは、
プレイヤーがパンタを操作しながら、落下するどんぐりを瞬時に認識し、追いかけることができること
です。
そこで、ゲームオブジェクトとして十分な存在感と視認性を持つことを基準として、パンタとの相対的な大きさを検討しました。
実際のゲームでは、どんぐりは回転しながら落下する予定です。
最終的な表示サイズや回転速度については、Unity上で実際に動かしながら調整します。
10．完成後、再びパーツへ分離する
16:9のゲーム画面として背景が完成しても、この一枚の画像をそのままゲーム背景として使用するわけではありません。
制作時には一つのファイルへ集めた、
背景、
上部枝葉、
下部草地、
その他の前景素材
を、完成後に再びそれぞれのゲーム素材としてエクスポートします。
つまり今回の制作では、
AIによる個別素材の生成
↓
人間による一つの制作ファイルへの統合
↓
加工・配置・色調補正
↓
ゲーム画面として完成
↓
再びパーツごとに分離してエクスポート
という工程を行いました。
そして、それぞれの素材をUnityへ持ち込みます。
Unity上では、実際のゲーム画面を確認しながら、
表示サイズ、
位置、
キャラクターとの関係、
UIとの関係
などを最終的に調整します。
今回の実制作から分かったこと
今回の背景制作では、画像生成AIに一枚の完成背景を制作させ、それをそのままゲームへ使用する方法は採用しませんでした。
背景、枝葉、草地などを独立した素材として生成し、それらを人間が一つの制作ファイルへ集めました。
そしてゲーム画面全体を見ながら加工し、色調を補正することで、一つの世界として統合しました。
完成後には、再びゲーム実装用の独立した素材へ分離します。
ここから分かるのは、
AIが生成した個々の画像素材と、実際にゲームで使用できる完成素材は、必ずしも同じものではない
ということです。
今回の制作では、
AIが素材を生成する。
人間が素材を加工する。
人間が色調を統一する。
人間がゲーム画面として構成する。
Unity上で最終的な表示サイズと位置を調整する。
という役割分担になりました。
また、背景1536×1024px、前景幅2048px、キャラクターなど、元となる画像素材のピクセルサイズがすべて統一されている必要もありませんでした。
重要なのは、素材の数値を機械的に揃えることではなく、
最終的なゲーム画面の中で、それぞれが適切な大きさ、位置、色彩、役割を持つように調整すること
です。
そして今回、もう一つ重要だったのが、
ゲーム背景を「素材の集合」としてだけではなく、最終的には一枚の絵として判断すること
でした。
「森のどんぐり大作戦」は、絵本「おむすび山」の世界の中で遊ぶゲームです。
ゲームとして機能することだけではなく、
絵本の世界そのものの中でキャラクターを動かしているように感じられること。
そのためには、AIによる素材生成だけでなく、人間による加工、色調補正、構図の判断が必要でした。
今回の実制作によって、
AIによる個別素材の生成と、人間による視覚世界の統合。
その両方を組み合わせることで、AI生成画像を実際のゲーム背景へと変えていく、一つの制作方法が見えてきました。
