游戏开发中 3D 背景数据如何从 Maya 到 Unity 逐层检查

はじめに

ゲーム用の3D背景は、Mayaでモデルが完成した時点では、まだ「ゲームで使えるデータ」になったとは限らない。

モデルの形や見た目に問題がなくても、Unityでの設定やコリジョン、実際のプレイ時の見え方に問題があれば、修正が必要になる。

私は以前、スマートフォン向けゲームで、大量の背景データを外注先に制作していただく案件を担当した。背景データは155マップ分。チェック担当は主に私一人で、忙しい日は最大20ルート分をゲーム内で確認していた。

この記事では、そのとき実際に行っていたチェックを、Maya → Unity → ゲーム再生 → 修正依頼の順に整理する。MayaやUnityの操作手順を網羅する記事ではなく、何を、どの段階で、なぜ確認していたのかという実務上の考え方をまとめたものだ。

※ここで紹介するのは、あるプロジェクトでの一例である。必要な項目や設定値は、ゲームの仕様や開発環境によって変わる。

チェックは大きく4段階

私が行っていた確認は、おおむね次の流れだった。

Mayaデータの確認：モデル構成や制作ルールが正しいか
Unityデータの確認：インポートされたアセットや各種設定に問題がないか
ゲーム内での確認：実際に操作したとき、遊べる背景になっているか
修正依頼と再確認：問題の場所と直し方を具体的に伝える

大切なのは、最後にまとめて見るのではなく、問題を見つけやすい段階で確認することである。

最初に見るのは、見た目の良し悪しだけではない。

モデル構成は制作ルールに沿っているか
モデル名・マテリアル名などの命名規則は守られているか
不要なデータが残っていないか
UVとライトマップ用UVは想定どおりか
カラーセット・頂点カラーは正しく入っているか
コリジョンデータの設計に沿った形状になっているか

特に重要だったのが、コリジョンと見た目の整合性である。

プレイヤーが歩く部分は、ゲーム側のコリジョンに基づいている。どれだけ綺麗な地形でも、歩ける範囲と見た目が大きく違えば、ゲーム内では使えない。

また、Maya側のデータ構成が根本から違っていると、Unity上で設定を終えた後に大きな手戻りが発生する。そのため、量産を始めた当初は、外注先にまずMayaデータを提出してもらい、問題がないことを確認してからUnityの作業へ進んでもらった。

最初の確認結果に応じて、チェック工程を変える

この案件では、最初に提出されたデータの精度が高く、仕様書やサンプルデータに沿って作られていた。

そこで2つ目以降は、Mayaだけを先に確認する工程を省き、MayaデータとUnityデータをまとめて提出してもらう形へ変更した。

もちろん、Mayaの確認自体をやめたわけではない。最初のデータで作り方の根本が合っていると確認できたため、工程を調整したのである。

大量のデータを扱うとき、すべてを同じ密度でチェックし続ければ、確認する側の作業が詰まってしまう。問題が出やすい部分へ時間を使うためにも、チェック工程の見直しは必要だった。

2. Unityで確認していたこと

Unityパッケージが届いたら、すぐにゲームを再生するわけではない。まず、追加されたデータと設定を確認する。

フォルダ構造は正しいか
モデル・テクスチャ・マテリアルの命名は規則に沿っているか
テクスチャの圧縮設定は適切か
マテリアルの設定は仕様書と合っているか
オブジェクトのStatic設定・Layer設定は正しいか
ライトプローブの配置間隔に問題はないか
ライトマップのサイズと見た目に問題はないか

スマートフォン向けゲームでは、データ容量や描画負荷も重要な条件になる。

テクスチャの圧縮設定やライトマップのサイズが不適切であれば、見た目だけでなく容量にも影響する。フォルダや命名が乱れていると、データが増えたときに修正対象を特定しづらくなる。

一つひとつは地味な項目だが、量産するほど確認しておく意味が大きくなる。

3. Unityでゲームを動かして確認する

データを確認したら、実際にゲームを再生し、キャラクターを歩かせる。

確認していたのは、例えば次のような点だ。

スタート地点からルートに沿って進めるか
分岐や戦闘エリアの周辺に不自然な箇所はないか
行けそうに見えるのに通れない場所はないか
逆に、行けなさそうな場所に入り込めないか
コリジョンと背景モデルの位置が大きくズレていないか
開始・クリアなどの演出カメラで背景の裏側や見切れが出ないか

Sceneビューで綺麗に見えることと、ゲーム内で自然に遊べることは別である。

この案件では、基本的に5ルート分を1つのMayaデータにまとめていた。Unityパッケージとしては4マップ分ほどでも、ゲーム内では20ルートを個別に歩いて確認する必要があった。

「一日最大20マップを確認」と書くと誤解されやすいが、正確には一日最大20ルート分を確認したということになる。

4. 実際に見つかった修正例

UVの継ぎ目

今回の背景は、用意したパーツを組み合わせて地形を構成し、その後でUVを展開し直す作り方だった。

このとき、テクスチャの継ぎ目が目立ってしまうことがあった。特に壁面は、カメラの角度によっては地面より目立つ。

そこで、UVの切れ目を、できるだけ凹みや影になりやすい場所などへ移してもらうようにした。

単に「UVを綺麗にしてください」ではなく、どこの継ぎ目が目立ち、どこへ逃がすかまで伝えることが重要だった。

頂点カラーの欠落

この案件では、Unity側のシェーダーが頂点カラーを使用していた。そのため、Maya側で頂点カラーが消えていると、Unity上で意図した見え方にならない場合があった。

Mayaだけで見ていると気づきにくい問題も、最終的な表示環境でチェックする必要がある。

5. 修正指示は「何を直すか」が伝わる形にする

問題を見つけたら、外注先へ修正内容を返す。

ここで避けたいのは、「いい感じにしてください」「もう少し自然に」といった曖昧な指示である。

私が意識していたのは次の点だ。

問題のある箇所をスクリーンショットで示す
該当箇所に丸などの目印を付ける
何が問題なのかを書く
どう直してほしいのかを具体的に書く
必要なら修正版のモデルやテクスチャをこちらで用意する

特に4、5は重要視している。
例えば、「もう少し明るくしてください」という指示では、人によって「もう少し」の程度が異なる。
そのため、可能であれば自分で一度テクスチャを調整し、意図した明るさになることを確認してから、「このテクスチャの明度を10上げてください」と具体的な数値で伝える。
また、数値だけでは伝えにくい修正の場合は、こちらで修正した画像やデータを見本として渡すこともある。

重要なのは、相手が迷わず、こちらの意図した修正を行える状態にすることである。

やり取りが何往復も発生すると、それだけで量産の速度が落ちてしまう。場合によっては、こちらで修正データを作って渡すほうが早いこともあった。

外注チェックの目的は、欠点を指摘することではない。データをゲームで使える状態にし、量産の流れを止めないことである。

まとめ：完成データは「作る」だけでは終わらない

今回の確認で重視していたのは、次のような点だった。

確認する段階	主なチェック項目
Maya	モデル構成、命名、UV、頂点カラー、不要データ、コリジョンとの整合性
Unity	フォルダ構造、圧縮設定、マテリアル、Static・Layer、ライトプローブ・ライトマップ
ゲーム再生	ルートの通行、見た目と判定の一致、演出カメラでの表示
修正依頼	位置・問題・修正方針を具体的に伝えられているか

どれだけ綺麗なモデルでも、ゲーム内で正しく使えなければ完成とはいえない。

Mayaで作り、Unityで設定し、ゲームを動かして確認する。その途中で必要な修正を行い、最終的にゲームで使える状態へ持っていく。

3D背景制作では、作る力だけでなく、確認する力も必要になるのである。