見出し画像

【現場編 #08】一日最大20ルート分をチェックしていた話

ゲームの背景屋さん

前回、背景2人だけのチームで、
片方が倒れても詰まないようにした話を書いた。

担当は分ける。
だが、情報は分けない。

インゲーム背景とアウトゲーム背景で担当作業は違っていても、
同じ背景チームとして、お互いの状況を把握しておく。

それが、少人数チームを止めないために必要なことだった。

今回は、その続きである。

外注さんから上がってきたデータを、
実際にどのように確認していたのか。

Mayaデータで何を見ていたのか。
Unity上で何を確認していたのか。
修正が必要な時、どのように返していたのか。

そのあたりを書いていこうと思う。

外注さんに背景を作ってもらう時、
勘違いされやすいことがある。

それは、

「外注さんからデータが上がってきたら終わり」

ではない、ということだ。

もちろん、外注さんが作ってくれること自体はとても大きい。

155マップ分の背景を社内2人で全部作ることはできない。
だから外注さんの力が必要だった。

だが、上がってきたデータをそのままゲームに入れられるわけではない。

社内で確認する必要がある。

ゲーム内で成立しているか。
仕様書通りに作られているか。
データとして問題がないか。
量産ルールから外れていないか。
プレイヤーが実際に遊んだ時に不自然ではないか。

そこまで見て、初めて使えるデータになる。

つまり、外注量産には、
チェック担当が必要である。

そして今回、そのチェック担当はほぼ私だった。

インゲーム背景担当は私一人である。

外注さんから上がってきたデータを確認し、
必要があれば修正指示を出し、
場合によってはこちらで正解データを作って返す。

これをひたすら繰り返す。

一日最大で20マップくらい確認していた、
と以前は書いたかもしれない。

ただ、正確に言うと、
一日最大20ルート分である。

今回の背景データは、
基本的に5ルート分を1つのMayaデータにまとめる形で作っていた。

だから、Unityパッケージとしては4マップ分程度でも、
ゲーム内で確認する時は1ルートずつ歩く必要がある。

つまり、

4マップ分のUnityパッケージを確認する。
だが、ゲーム内では20ルート分を歩く。

そういう感覚だった。

まず最初は、Mayaデータの確認から始めた。

前回は、Unityまで仕上がった初回データを見た時の話を書いたが、
実際にはその前に、Mayaデータの段階でも一度確認を入れていた。

外注さんにいきなりUnity作業まで進めてもらうのではなく、
最初の段階では、Mayaデータが仕上がった時点で一度送ってもらった。

なぜか。

Mayaデータの作り方が根本からズレていると、
その後のUnity作業も全部ズレるからである。

Unity上で見た目を整えてから、

「そもそもMayaデータの構成が違います」

となると、戻り作業が大きすぎる。

だから最初は、Maya段階で確認した。

Mayaで見ていたのは、
単に形が合っているかどうかだけではない。

モデル構成。
命名規則。
マテリアル。
カラーセット。
UV。
余計なゴミデータが入っていないか。
ゲーム用データとして綺麗な状態になっているか。

そういった部分を確認していた。

特に重要だったのは、
こちらから渡したコリジョンデータの設計通りに作られているかどうかである。

コリジョンは、ゲーム内でキャラクターが歩く場所そのものだ。

だから、見た目として綺麗でも、
コリジョンと大きくズレていれば使えない。

また、UV展開、ライトマップUV、頂点カラーなど、
外注さん側で必ず触ることになる部分が、仕様書通りになっているかも確認した。

ここで問題なければ、
「このままUnity作業に進んで大丈夫です」
と返す。

ただし、このMayaチェックは、
ずっと同じ密度で続けたわけではない。

最初のデータを見た時点で、
外注さんの作りはかなり良かった。

こちらの仕様書を読み、
サンプルデータを見て、
かなり正確に作ってくれていた。

そのため、2つ目以降は、
Mayaデータだけ先に確認する工程は省略し、
MayaデータとUnityデータを同時に提出してもらう形にした。

これは、外注さんを信頼できたからである。

もちろん、何でもかんでも信用して確認を省いたわけではない。

最初のデータで、
作り方の根本が合っていることを確認できた。

だから、チェック工程を少し軽くできたのである。

量産では、こういう判断も必要になる。

全部を最初と同じ密度で見続けると、
チェック側が詰む。

問題が出にくい部分は軽くし、
問題が出やすい部分に時間を使う。

そうしないと、量産は回らない。

Mayaデータに問題がなければ、
次はUnity上での確認である。

外注さんからUnityパッケージが上がってくる。

それをインポートする。

ここでいきなりゲームを再生するわけではない。

まずは、追加されたデータそのものを確認する。

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

こういった項目を一通り見る。

地味である。

とても地味である。

だが、この地味な確認を飛ばすと、
後でどこかで事故る。

大量の背景データでは、
命名やフォルダ構成の乱れが、そのまま事故につながる。

どのモデルがどのマップのものなのか。
どのテクスチャがどのマテリアルに使われているのか。
どのデータが差分なのか。
どのフォルダに入っているのか。

それが分からなくなると、確認にも修正にも時間がかかる。

また、テクスチャの圧縮設定やライトマップのサイズは、
見た目だけでなく容量にも関わる。

スマホゲームでは、背景が重くなりすぎると困る。

だから、見た目が良ければOK、ではない。

データとして軽く、
ルール通りで、
量産しても破綻しないこと。

そこまで含めて確認する必要があった。

一通りデータを確認したら、
次は実際にゲームを再生する。

ここがとても重要である。

背景は、Mayaで見ても、UnityのScene上で見ても、
実際にゲームとして動かしてみないと分からないことがある。

キャラクターを実際に歩かせる。

スタート地点から進む。
ルートに沿って歩く。
分岐があれば分岐を見る。
戦闘エリアがあれば、その周辺を見る。
行き止まりが不自然ではないかを見る。
行けそうに見えるのに行けない場所がないかを見る。
コリジョンと見た目がズレていないかを見る。

ゲーム内には、まだ敵が配置されていないことも多かった。

だから、基本的にはコリジョンに沿って歩き、
ルートとして成立しているかを見る。

ここで見ていたのは、
単なる見た目の綺麗さではない。

プレイヤーが自然に進めるかどうかである。

たとえば、見た目上は道があるように見えるのに、
実際には通れない。

逆に、行けなさそうに見える場所に入れてしまう。

壁や岩の配置が、
コリジョンと微妙にズレている。

こういう状態は、プレイヤーにとって違和感になる。

背景側から見ると小さなズレでも、
ゲームとして遊ぶと気持ち悪いことがある。

だから、実際に歩く。

これが大事だった。

さらに、演出カメラでの見え方も確認する必要があった。

ゲームでは、プレイヤーが操作しているカメラだけでなく、
開始演出やルートクリア演出でカメラが回ることがある。

その時に、背景が見切れていないか。
カメラの前に余計なオブジェクトが被っていないか。
見えてはいけない裏側が見えていないか。
画面として破綻していないか。

こういう部分も確認する。

つまり、背景チェックは、
ただSceneビューで眺める作業ではない。

ゲームを再生し、
実際に歩き、
演出カメラで見て、
ゲーム内で成立しているかを確認する作業である。

この作業を、
一日最大20ルート分くらいやっていた。

もちろん、全部が毎回重い修正になるわけではない。

OKな場合は、1マップ30分くらいで確認できたと思う。

だが、それは本当に問題が少ない場合である。

修正点が出れば、その分時間は増える。

しかも、Windows上でUnityを再生するのは重い。

パッケージをインポートする。
データを見る。
ゲームを再生する。
歩いて確認する。
必要があればスクショを撮る。
修正内容を書く。

それを何度も繰り返す。

かなり地味で、かなり消耗する作業だった。

では、どんな修正が多かったのか。

一番多かったのは、UV関係だったと思う。

今回のマップは、
こちらで用意したパーツを組み合わせて作る形である。

だから、使うパーツ自体は決まっている。
ルートも決まっている。
作るべきものも決まっている。

だが、パーツを組み合わせて全体を作った後、
UVだけは改めて展開し直す必要があった。

ここで、どうしても継ぎ目が出ることがある。

あまり見えない場所なら問題ない。

だが、意外と側面の壁はゲーム中でもよく見える。

カメラの角度によっては、
地面よりも壁面のほうが目立つことすらある。

だから、テクスチャの繋がりが不自然な場所や、
どうしてもUVを切る必要がある場所は、
なるべく目立たない場所に切れ目を入れてもらうようにした。

たとえば、凹みのあるパーツ部分や、
影になりやすい場所などである。

こういう部分は、仕様書だけでは伝わりにくい。

実際に上がってきたデータを見て、
「ここで切ると目立つので、こちら側に逃がしてください」
と具体的に返す必要がある。

次に、頂点カラー関係である。

頂点カラーは、Maya上だけ見ていると気づきにくいことがある。

今回のデータでは、
Unity側のシェーダーで頂点カラーを使っていた。

だから、うっかり頂点カラーが消えていると、
Unity上で見た時に意図した見え方にならないことがある。

外注さんは、Unity上でマテリアル設定を行い、
StaticやLayerの設定をし、
ライトマップを焼き、
ライトプローブも配置してくれていた。

それだけでも本当にありがたい。

だが、実際のゲーム再生環境で、
こちらと同じようにすべてのルートを歩いて確認しているわけではない。

だから、ゲームを再生して初めて分かる不具合は、
どうしてもこちらで拾う必要がある。

頂点カラーもその一つだった。

もちろん、外注さんの出来が悪かったわけではない。

むしろ逆である。

この時の外注さんは、本当によく作ってくれていた。

コリジョンとの大きなズレは少なかった。
不要データも、Maya段階で大きな問題になるものは少なかった。
仕様書も参考データもよく見てくれていた。

だからこそ、量産が回った。

だが、それでも、
ゲーム内で再生して初めて分かることはある。

そこを確認するのが、社内チェック担当の仕事だった。

修正が必要な時は、
できるだけ具体的に返すようにしていた。

文章だけで、

「ここをいい感じにしてください」

とは書かない。

それでは伝わらない。

スクショを撮る。
該当箇所に丸を付ける。
何が問題なのかを書く。
どう直してほしいのかを書く。

必要であれば、
こちらで修正版のデータや画像を用意する。

たとえば、明るさを調整してほしい時も、
「少し明るくしてください」
ではなく、
「明度をこのくらい上げてください」
という形にする。

曖昧な修正指示は、修正ラリーを増やす。

そして、155マップの量産で修正ラリーが増えると、
それだけで現場が詰む。

だから、できるだけ一度で伝わるようにする。

時には、こちらでモデルやテクスチャを作って、
「このデータと差し替えてください」
と返すこともあった。

一見すると、そのほうが手間に見える。

だが、説明だけで何度もやり取りするより、
こちらで正解データを作ったほうが早い場合がある。

特に、後から追加する必要が出たギミック用のパーツなどは、
こちらで作って渡したほうが確実だった。

外注さんに一から意図を説明し、
作ってもらい、
上がってきたものを確認し、
また修正する。

その時間を考えると、
こちらで作ってしまったほうが早いことがある。

これは、外注さんを信用していないという話ではない。

量産を止めないための判断である。

外注チェックは、ダメ出しをする作業ではない。

ここは大事である。

上がってきたデータを見て、
悪いところを探して、
指摘して終わり。

そういう仕事ではない。

目的は、量産を止めないことだ。

外注さんが作ったデータを、
ゲーム内で使える状態にする。

必要な修正を、できるだけ分かりやすく返す。

相手が一度で直せるようにする。

場合によっては、こちらで正解データを作る。

そうやって、量産の流れを止めずに進めていく。

それが外注チェックだった。

155マップという数になると、
一つ一つの確認に時間をかけすぎることはできない。

だが、雑に見ることもできない。

どこをしっかり見るか。
どこは外注さんの精度を信じるか。
どこでこちらが手を入れたほうが早いか。

その判断が必要になる。

全部を完璧に見るのではない。

重要なところを落とさないように見る。

今回で言えば、

Mayaデータとして綺麗か。
命名規則に沿っているか。
Unity上の設定が正しいか。
コリジョンと見た目が合っているか。
プレイヤーが自然に歩けるか。
演出カメラで破綻していないか。
UVや頂点カラーに問題がないか。

こういった部分を重点的に見ていた。

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

特に外注量産では、
確認する人間の判断がかなり重要になる。

何がOKで、何がNGなのか。
どこまで直してもらうのか。
どこからはこちらで直すのか。
その修正は本当に必要なのか。
今その修正を入れることで、量産全体が止まらないか。

そういう判断をしながら進める必要がある。

一日最大20ルート分のチェックは、
派手な作業ではない。

新しい背景を一から作るわけでもない。
美しいコンセプトアートを描くわけでもない。
見栄えのするスクリーンショットを作るわけでもない。

ただ、上がってきたデータを開き、
確認し、
歩き、
見て、
直してもらう。

それを繰り返す。

だが、この作業がなければ、
外注量産はゲーム内で成立しない。

外注さんが作ってくれたデータを、
実際にゲームに入れられる状態まで持っていく。

それが、社内背景担当の仕事だった。

外注さんからデータが上がってきた時点では、
まだ終わりではない。

そこから、社内で確認する。
ゲームとして成立しているかを見る。
必要があれば直す。
必要があれば直してもらう。
そして、使えるデータにする。

それを155マップ分繰り返す。

地味である。

ものすごく地味である。

だが、現場ではこういう地味な確認作業が、
プロジェクトの後半を支えている。

背景制作は、作るだけでは終わらない。

作ったものが、
ゲームの中でちゃんと機能するところまで見届ける必要がある。

次回は、
量産しやすかった場所と、
逆に量産で苦労した場所について書いていこうと思う。

基本パーツの組み合わせだけで作りやすかったロケーションと、
建物や細かいパーツが多く、後から分割対応が必要になったロケーション。

量産できる背景と、
量産しづらい背景。

その違いについて書いていく。

なお、外注データを確認する時の具体的なチェック項目については、
また別の記事で整理してみたいと思う。

いいなと思ったら応援しよう！