見出し画像

【現場編 #05】外注量産は「考える余地」を減らすところから始まる

ゲームの背景屋さん

前回、外注仕様書はチームを守るためにも必要だった、という話を書いた。

仕様書は、単なる作業手順書ではない。

誰が何を決めるのか。
何を受け取ったら背景が作業に入れるのか。
どこまでが背景側の責任範囲なのか。

それを明確にするための、現場の防波堤でもあった。

では、実際に外注量産を成立させるために、何を用意したのか。

今回は、その話を書こうと思う。

外注さんに大量の背景を作ってもらう時、
一番避けたいのは、

「どう作ればいいのか分からない」

という状態である。

これは外注さんが悪いという話ではない。

むしろ、発注側が悪い。

必要な情報が整理されていなければ、
作る側は当然迷う。

迷えば、作業が止まる。
判断がバラける。
データの作り方もバラける。

そして、チェック時に大量の修正が発生する。

155マップという物量で、それをやったら終わりである。

だから私は、外注さんが作業中に迷わないように、
できるだけ「考える余地」を減らすことにした。

ここでいう「考える余地を減らす」とは、
創意工夫を否定するという意味ではない。

判断しなくていい部分を、先にこちらで固定しておくという意味である。

命名規則。
フォルダ構造。
Mayaでの作業手順。
Unityでの設定。
テクスチャ構成。
ライトマップの焼き方。
どのパーツを使うか。
どのルートを作るか。

こうした部分をすべて外注先の判断に任せると、
同じロケーションでもデータの作り方がバラバラになる。

それでは量産にならない。

この時に用意した資料は、大きく分けると三つある。

一つ目は、作るための基準。

Mayaでどう作るのか。
Unityでどう設定するのか。
データ名をどう付けるのか。

つまり、作業ルールである。

二つ目は、作るための材料。

マップパーツ。
共通テクスチャ。
Unityシェーダー。
参考用のMayaデータ。
参考用のUnityデータ。

つまり、手元にあるものを組み合わせれば作れる状態にした。

三つ目は、何を作るかの設計図。

企画側が作成したコリジョンマップ。
それをもとにしたルートの資料。
どのパーツをどの順番で使うかを書いた資料。

つまり、外注さんが「何を作ればいいか」を確認できる資料である。

この三つを揃えることで、ようやく外注量産の準備が整う。

まず重要だったのは、Mayaでの作成手順だった。

今回のマップは、一から全部作るわけではない。

あらかじめこちらで用意したマップパーツを、
ブロックのように組み合わせて作ってもらう。

人工物なら人工物用。
自然物なら自然物用。

ロケーションに合わせて、使うパーツを分ける。

ゲームデザイナーが作成したコリジョンデータをMayaに読み込み、
そのコリジョンに沿って地面や壁を作成していく。

ここで大事なのは、
コリジョンはゲーム内でキャラクターが歩く場所そのものだということだ。

だから、見た目の都合で勝手に削ったり、
歩ける面に穴を開けたり、
コリジョンから大きくずらしたりしてはいけない。

自然物として多少ゆがませる場合でも、
キャラクターが歩く部分が欠けないようにする必要がある。

ここを外すと、見た目以前にゲームとして成立しない。

次に、地面のUVや頂点カラーのルールも必要だった。

地面は、ただテクスチャを貼れば終わりではない。

Unity上でマスクやブレンドを使う関係で、
UVの持ち方が少し特殊だった。

場合によっては、通常のテクスチャ用UV、
ブレンド用UV、ライトマップ用UVなど、
複数のUVが必要になる。

さらに、地面の頂点カラーも、
シェーダー側で色調整に使うための情報として入れていた。

陰影表現そのものはライトマップで行う。
だから、頂点カラーで影を描き込むわけではない。

こういう部分は、口頭で説明してもまず伝わらない。

資料にして、
「ここはこういう目的で使う」
「このデータを参考にする」
と書いておく必要があった。

Maya側の作業が終わったら、Unity側の設定がある。

FBXのインポート設定。
シェーダー設定。
テクスチャ設定。
ライト配置。
ライトプローブ配置。
ライトマップ設定。
スタティック設定。
フォルダ構造。

これらもすべて、量産では重要になる。

たとえば、ライトマップを焼く必要があるものと、
焼く必要がないものがある。

それぞれを正しく分けて設定しなければ、
見た目が崩れたり、無駄に重くなったりする。

ライトプローブも同じである。

背景にライトマップを焼くだけでなく、
キャラクターにライトの色を反映させるためには、
ライトプローブの配置も必要になる。

つまり、外注さんにお願いしていたのは、
単なるモデリングではなかった。

ゲーム内で成立する背景データをそのまま作ることだった。

もちろん、これは比較的シンプルなスマホゲームだったから成立した部分もある。

複雑なコンシューマーゲームや、演出・ギミックが多いマップであれば、
ここまで「そのまま作る」形に落とし込むのは難しいかもしれない。

だが、今回必要だったのは、
短時間で遊べるクエストマップを大量に用意することだった。

だからこそ、作り方を固定し、
外注さんが迷わず同じ基準で作れる状態にすることが重要だった。

ここで地味に効いてくるのが、命名規則である。

大量のデータを扱う時、
名前がバラバラになると、それだけで事故が起きる。

どれがマップ本体なのか。
どれがFBXなのか。
どれがマテリアルなのか。
どれがテクスチャなのか。
どのロケーションのデータなのか。
昼なのか、夜なのか。
通常なのか、差分なのか。

それが名前から分からないと、
確認するたびに中身を開くことになる。

そんなことを155マップ分やっていたら、時間がいくらあっても足りない。

だから、名前で判別できるようにした。

マップ、FBX、マテリアル、テクスチャ。
それぞれに命名ルールを決め、
テーマID、地形ID、シチュエーションID、時間帯IDなどを入れる。

これは地味だが、かなり重要である。

データが増えれば増えるほど、
命名規則は現場を救う。

もう一つ、外せなかったのが、
コリジョンマップの資料である。

企画側で作成したルートを、
外注さんが実際に作れる形へ落とし込む必要があった。

たとえば、自然系ロケーションのマップであれば、

このルートにはどのパーツを使うのか。
スタート地点はどこか。
バトルエリアはどこか。
横道はどこか。
宝箱やジャンプ台などのギミックはあるのか。

そういった情報を、資料としてまとめる。

外注さんは、その資料を見ながら、
用意されたパーツを組み合わせてマップを作る。

つまり、背景側が用意したのは、
ただの作業手順ではない。

作るための材料と、
作るためのルールと、
何を作るかの設計図である。

ここまで用意しておくと、外注さん側の作業はかなり明確になる。

どのパーツを使うか。
どのコリジョンに沿わせるか。
どのルールで名前を付けるか。
どのUnity設定を行うか。
どの参考データを見ればいいか。

迷う余地が少ない。

そして、迷う余地が少ないということは、
チェックする側の負担も減るということである。

外注さんから上がってきたデータを見た時、
「この作り方はそもそも違う」
という修正が大量に出るのが一番つらい。

そうなると、もはや外注ではなく、
こちらが一から作り直しているのと変わらない。

それを避けるために、
最初に作業ルールを固定しておく必要があった。

もちろん、どれだけ資料を作っても、
すべてが完璧に伝わるとは限らない。

資料を読んでもらえないこともある。
解釈がずれることもある。
外注先の担当者によってクオリティが変わることもある。

それでも、資料があるかないかで結果は大きく変わる。

少なくとも、こちらは

「この資料に沿って作ってください」

と言える。

チェック時にも、

「ここは仕様と違います」

と言える。

この基準があることが大事だった。

155マップを量産するために必要だったのは、
ただ外注先に発注することではなかった。

外注さんが迷わず作れる状態を、
先にこちらで作ることだった。

作る基準を用意する。
作る材料を用意する。
何を作るかの設計図を用意する。
命名規則とフォルダ構造を決める。
MayaとUnityの作業手順を分けて書く。

そこまでやって、ようやく量産が始まる。

背景制作では、
「作る」ことだけが仕事ではない。

人に作ってもらえる状態にすることも、
大事な仕事である。

そして、大量に作る必要がある時ほど、
その準備の差が後半に効いてくる。

外注量産は、
発注した瞬間に始まるのではない。

外注さんが迷わないように、
こちらが考えるべきことを先に考え切った時点で、ようやく始まるのである。

次回は、
実際に外注さんからデータが上がってきた時の話を書こうと思う。

こちらが用意した仕様書とサンプルデータが、
本当に機能したのか。

初回提出を見た時、私はどう思ったのか。

そのあたりを書いていく。

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