株式会社Colorful Paletteでクライアントエンジニアをしている山口 (@togucchi) と申します。

現在は主に『プロジェクトセカイ カラフルステージ！ feat.初音ミク』（以降『プロセカ』）の3Dグラフィックスやバーチャルライブ機能周辺の開発を担当しています。

また、SGE（ゲーム・エンターテイメント事業部）内の横軸で3D・グラフィックス技術の推進活動なども行っています。

 

私の経歴などについてはこちらのインタビュー記事で詳しく話しているので、こちらも読んでいただけると嬉しいです。

「自分たちの中で最適解を考えた」新規プロジェクト開発で経験したこととは？

 

『プロセカ』の概要

 

 

『プロジェクトセカイ カラフルステージ！ feat.初音ミク』は株式会社セガとColorful Paletteの協業で開発しているボーカロイドを中心としたリズム&アドベンチャーゲームです。

クライアントアプリの開発環境としては『Unity』を採用しています。

 

『プロセカ』のリズムゲームの楽曲には登場するキャラクター・衣装を自由に変更して観れる「3DMV」が付いているものがあります。

今回の記事では、『プロセカ』における3DMVのための制作環境の構造・設計について解説していきます。

3DMV制作の背景

設計の解説の前に『プロセカ』の3DMV制作におけるそもそもの背景をご紹介します。

 

 

3DMVの制作には主に「開発チーム」、「MV制作チーム」の2つのチームが関わっています。

開発チームは実際のアプリでMVを動かすための実装やMVを制作するための環境・ツールの整備を行っています。

MV制作チームはダンスやカメラなどのモーションの制作、全体の演出の制作などMVそのものの制作を行っています。

 

月に数回とかなりの頻度で追加される3DMVを実際に制作しているのはMV制作チームであり、MV制作チームは開発チームがUnity上に整備した制作環境を直接触ることになるので、制作環境の整備は全体の制作効率やMV自体の品質に大きく関わってくることになります。

全体の設計

早速ですが、『プロセカ』の3Dアセットの制作環境の全体的な構成は以下のようになっています。

 

アセットがビルドされるまでの大まかな流れとしては、

• 3D制作用のUnityプロジェクトのMV制作用シーンでアセットを作成
• 作成したアセットを3Dアセット用の専用リポジトリにプッシュ
• アプリ開発用のUnityプロジェクトに通常アセット（楽曲、サムネイルなど3D以外の全般が含まれる）と3Dアセット両方をインポート
• 専用のアセットビルド用ツールでAssetBundleビルド

このようになっています。

 

この構成の大きな特徴として、アセットを管理するためのリポジトリが通常アセット用・3Dアセット用で分かれていること、Unityプロジェクトがアプリ開発用・3D制作用で分かれていることがあります。

この構成の意図やメリット・デメリットに関しては後述します。

 

アセットの分割について

概要

3Dアセット制作環境の大きな特徴の１つに3Dアセット用のリポジトリを通常アセット用のリポジトリから分離させていることがあります。

各リポジトリに含まれているアセットの内訳は以下のようになっています。

 

通常アセット

• イラスト
• アイコンなどのサムネイル
• SEなどの音源
• シナリオ

etc…

 

3Dアセット

• 3DMV
• キャラクターモデル
• ステージモデル

etc…

 

基本的には、キャラ・ステージなどMV制作に必要なものとそれ以外といった基準で分割されています。

最終的にアセットをビルドする際はCI/CD環境上に構築されたアプリ開発用のUnityプロジェクトで両方のアセットをインポートし、まとめてAssetBundleビルドを行っています。

 

メリット

この構成になっているメリットの中で最も大きいものが「インポート時間の短縮」です。

アプリ用のアセットは運用が長くなるにつれてどんどん肥大化していきますが、3D用のアセットはモデル用のテクスチャが多く含まれていたりなど特にサイズが大きくなりやすいものかと思います。

通常アセットだけを編集したいといった場面でそういった3DアセットのリポジトリのフェッチやUnityへのインポートにかかる時間を削減することができます。

また同じく、3D制作環境で3Dアセットのみを編集する場合は通常アセットをインポートする必要がなくなるので3D制作環境でアセットをインポートするための時間を削減することができます。

 

アセット用のリポジトリでは各リリースバージョンごとにブランチが切られているので、そういったブランチを切り替えたときに発生するインポート時間もそれぞれ削減することができます。

 

デメリット

分割されたそれぞれのアセットに対してのオペレーションが必要なことがデメリットになるかと思います。

編集したいアセットが含まれるリポジトリを個別にフェッチ・インポートする必要がありますし、ビルドのパイプラインにも両方のリポジトリそれぞれに対しての処理を挟む必要があります。

アセット用のリポジトリが単一のシンプルな構成に対して、特殊なオペレーションを追加する必要は出てくるかと思います。

 

MV制作用プロジェクト

概要

『プロセカ』のMV制作用のUnityプロジェクトはアプリ開発用のプロジェクトとは分離されています。

MV制作チームはこのUnityプロジェクトのMV制作用シーンでMVの編集を行います。

 

MV制作シーン

 

MV制作用シーンでは、必要なステージや演出のアセットの情報が含まれているMV定義データをもとに各アセットをロード、構築します。

これにより実機での挙動と近い形のMVをリアルタイムに確認しながらMVの制作を行うことができます。

 

メリット

3D制作用にプロジェクトを分割することで、制作に特化したプロジェクト構成にすることができます。

特化したエディタ拡張・ツール類は各プロジェクトのみに配置する運用が可能になりますし、使用しないスクリプトのコンパイル時間を削減することもできます。

具体的な例でいうと、3D制作プロジェクトではインポートされたテクスチャなどのアセットのフォーマットを自動的に変更するエディタ拡張などが含まれています。

 

デメリット

メリットと若干被りますが、プロジェクトを分けているぶん共通で使用するスクリプト類の管理は煩雑になります。

演出用の制御やキャラの揺れものの制御の実装などは両プロジェクト共通で持つ必要があるため、各プロジェクト間での挙動のズレを無くすために片方のプロジェクトのコードを更新した際にもう片方のプロジェクトへの反映を行う必要があります。

 

こちらのデメリットに関してはgit submoduleやUnityのPackage Managerのような仕組みで一定の解決が図れるのではないかと考えています。

 

まとめ

この記事では3DMV用のアセット制作環境についてざっくり解説をしましたが、自分はこの設計が全ての開発・プロジェクトにおいてマッチするものだとは考えていません。

プロジェクトの規模や体制、制作物など複数の要因によって最適な設計は変化するでしょうし、大事なのはそれらの要因に対してより良い提案ができるよう引き出しを増やしておくことだと思います。

この記事をそういった際の引き出しの１つとしてご活用いただけると幸いです。