【CEDEC2017】『MONSTER HUNTER WORLD』における快適な作業環境へのアプローチ

『MONSTER HUNTER: WORLD』におけ る快適な作業環境へのアプローチ 株式会社カプコン 技術開発室 松田義昭

780GB

780GB ピーク時の全データサイズ ※Mayaのシーンファイル等の元データは含まない

長い待ち時間

待ち時間の最小化 快適な作業環境

用語について • 中間データ – ツールで扱う編集データ。 • メタデータ – 中間データには含まれない付加情報。 – 編集者、幅、高さ、ハッシュ値、etc… • リソース – 中間データ（＋メタデータ）をコンバートして生成 – 実機で読み込む最適化されたデータ • アセット – 中間データ + メタデータ

アジェンダ • 内製ツールの導入 • 導入時のアプローチ – 更新時の待ち時間の最小化 • 運用後の問題と改善事例 – 内製ツールの高速化

内製ツールの導入

導入前の環境 • バージョン管理システム(バックエンド) – Subversion • クライアントツール（フロントエンド） – TortoiseSVN + エクスプローラー – インゲームツール

導入後の環境 • バージョン管理システム(バックエンド) – PERFORCE • クライアントツール（フロントエンド） – 内製ツール（リソースブラウザ）

PERFORCE導入の目的 日々の更新の待ち時間の 最小化

MH: WorldのPERFORCE構成 サーバー レプリカ （VM） クライアント マスタ （物理） プロキシ （物理） クライアント

サーバー使用状況 • ディスクの使用量：2.9TB – DB、バージョン化ファイル、ログ、etc… • 総リビジョン：186,617 – 全ブランチ • ファイル数：485,473 – 本流のみ ※2017/08/18現在

リソースブラウザ（内製ツール）

内製ツールでしか 実現出来ない快適な作業環境 構築のため

リソースブラウザ導入の目的 • メタデータの活用 – サムネイル、テクスチャの幅、高さ、etc... – 高速な検索機能

メモリが足りないので、 大きなテクスチャを１段階小さくして！

人海戦術

リソースブラウザ導入の目的 • メタデータの活用 – サムネイル、テクスチャの幅、高さ、etc... – 高速な検索機能 • 例： Width > 1024 ⏎ • プロジェクトの独自性に柔軟に対応 • オペレーションのシンプル化 – 学習コストを抑える

リソースブラウザの特徴（1/2） • コア機能は、RE ENGINEのAssetBrowserと共有 – WPF(C#6.0)＋ P4API.NETで開発 – アセット単位での管理 • 中間データ + メタデータ – エクスプローラーでの編集を検出 – メタデータを利用した、高速なUI表示と検索機能 – コミット時に編集、追加、削除アセットを自動検出

リソースブラウザの特徴（2/2） • MH: World向けに専用のカスタマイズ – プロジェクト全体が管理対象 • • • • • 実行ファイル ソースコード 中間データ リソース（※一部のみ） メタデータ – 普段のオペレーションでよく使う機能に特化 • ワンボタンで安定した実行環境の取得

チーム全員が利用 共通言語で 会話するためのツール

導入時のアプローチ ～更新時の待ち時間の最小化～

更新時の待ち時間が増える原因 • 容量の多いファイルの取得

中間データタイプ別のファイルサイズ割合 その他 13% モーション テクスチャ 5% モデル 15% 67%

更新時の待ち時間が増える原因 • 容量の多いファイルの取得 – テクスチャの中間データ • 不必要なファイルの取得 – ほとんどのプログラマはテクスチャの中間データは必要ない – アーティストはソースコードは必要ない

導入時の方針 作業環境毎に取得するフォルダや ファイルを除外

MH: Worldで用意した作業環境 • デプロイ環境（jenkins） • コードビルド環境（プログラマ） • リソース編集環境（アーティスト、企画など）

デプロイ環境（jenkins） • いわゆる全部入り root code intermediate texture other resource texture ※フォルダ構成はイメージです • 用途 – – – – – – 自動ビルド 変換 テスト パッケージング デプロイ etc…

コードビルド環境（プログラマ） • 全ソースコードを含む root code • テクスチャの中間データは除外 intermediate texture other resource texture ※フォルダ構成はイメージです • 実行ファイルは自席でビルド

リソース編集環境（アーティスト、企画など） • 全中間データを含む root code • ソースコードは除外 intermediate texture other resource texture ※フォルダ構成はイメージです • 実行ファイルは、定期的に 配信されるテスト済みの安 定したものを取得

結果（コードビルド環境） 8702s 更新時間 4700s 46％ 削減 デプロイ コードビルド ※全体で約700GB時の更新時間比較

結果（リソース編集環境） 8702s 7915s 更新時間 ９％ 削減 デプロイ リソース編集 ※全体で約700GB時の更新時間比較

利用したPERFORCE機能 • VirtualStream（バーチャルストリーム）機能を利用 – Stream（ストリーム）とは、PERFORCEにおけるブランチ – 取得するフォルダやファイルを絞り込めるフィルタリング機能を持つ デプロイ コードビルド リソース編集

運用後の問題と改善事例 ～内製ツールの高速化～

合計データサイズ推移 （ＧＢ） 788 800 765 377 153 0 M1 M2 M3 ピーク時 780GB 超 536 400 750 M4 M5 現在 （マイルストーン）

運用後の問題 • 起動に時間がかかる • コミット操作に時間がかかる

運用後の問題 • 起動に時間がかかる • コミット操作に時間がかかる

起動に時間がかかる原因 • 起動時にやっている事 – 全メタデータの変更チェック • ツールを起動していない間の中間データの変更検出のため必要 • 大量のファイルへのアクセス ディスクI/Oがボトルネックに

起動に時間がかかる問題への改善方法 • SSDの導入 – ワーキングコピーを配置しているドライブを入れ替える 大きく改善

リソースブラウザ起動時間の比較 （秒） 200 起動時間 1９１s 60s 1/3 約 0 HDD SSD ※対象ファイル数、約430,000時の起動時間比較

運用後の問題 • 起動に時間がかかる • コミット操作に時間がかかる

コミット操作に時間がかかる原因 • コミット時にやっている事 – 事前チェック + 変更チェック • これらのチェックを対象となるアセット全てに行ってい るため • 特にルートフォルダからの実行で待たされる

事前チェックの詳細 • 目的 – 不正なアセットをコミットさせない • プロジェクト全体に問題が広がるのを防ぐ • 内容 – メタデータとの整合性チェック – Windowsの大文字小文字問題の回避 • リネーム時 • PERFORCEサーバーがLinuxのため – etc…

変更チェックの詳細 • 目的 – 追加、編集、削除アセットの自動検出 • ユーザーに追加のオペレーションを行わせない • コミット漏れを防ぐ • 内容 – ファイルの変更検出のためのコマンド呼び出し(※) • サーバーへの問い合わせが発生するため重い ※PERFORCEのreconcileコマンド

コミット操作高速化の改善策 • 運用で回避 • キャッシュ機能 • サーバーのCPU負荷軽減 • チェンジリスト機能

コミット高速化の改善策１（運用で回避） • コミット操作は深い階層から行う – 常に出来るとは限らない • 「Favorites機能」を利用する – Favorites機能は、フォルダに対するフィルタ設定機能 • パス、編集者、更新日時、Width、Height、etc...など利用可能 • 例：Width > 1024 – 条件が変わった際に設定を忘れるとコミット漏れが発生

コミット高速化の改善策2（キャッシュ機能） • 変更検出キャッシュ機能の導入 – 前回の変更検出時の結果をキャッシュし、次回問い合わせ の際のチェックに再利用 – サーバーへの問い合わせを抑制する

コミット操作の高速化 速度比較（1） （秒） 9196s ※対象ファイル数、約430,000 任意の２ファイルを編集し操作を行った際の速度比較 61s 0 当初 キャッシュ機能 （フルキャッシュ、SSD時）

コミット高速化の改善策3（CPU負荷軽減） • 無視リストの指定方法の変更 – サーバーからローカルへ移行 • 当初は、除外指定をサーバー側で行っていた ※無視リストとは？ – リストに指定されたフォルダやファイルは、バージョン管理から除外される

サーバーでの除外指定の問題点 • 指定を追加する毎にサーバーのCPU負荷が増加 • 合わせて、一部のPERFORCEコマンドの応答時間が 増加 – パス渡して結果を取得するケースが該当 – 変更検出コマンドも該当 • コミット操作に時間がかかっていた原因の１つ

サーバーのCPU負荷軽減方法 • 無視リストの設定をローカルに移行 • サーバーのCPU負荷、コマンドの応答速度ともに改善 – コミット操作以外のオペレーションも全般的に高速化

コミット操作の高速化 速度比較（2） （秒） 9196s ※対象ファイル数、約430,000 任意の２ファイルを編集し操作を行った際の速度比較 61s 43s 0 当初 キャッシュ機能 CPU負荷軽減

コミット高速化の改善策4（チェンジリスト） • 「チェンジリスト機能」の導入 – アセットの変更検出時に、バックグラウンドで変更検出コマ ンドのリクエスト • 変更のあるファイルはPERFORCEの「チェンジリスト」へ登録される – チェンジリストから情報を取得し、ツールのビューに一覧表示 変更のあるアセットへ即アクセスしコミット可能に

コミット操作の高速化 速度比較（3） （秒） 9196s ※対象ファイル数、約430,000 任意の２ファイルを編集し操作を行った際の速度比較 61s 43s 0.1s 0 当初 キャッシュ機能 CPU負荷軽減 チェンジリスト

チェンジリスト機能のデモ

まとめ

まとめ • 『MONSTER HUNTER: WORLD』における快適な作業 環境へのアプローチ – 環境を移行し、内製ツールを導入 – 更新の待ち時間の最小化 • 不必要なファイルは取得しない – 内製ツールの高速化

今後について • ローカルストレージの圧迫問題が残されたまま – 解決方法は引き続き模索中 • PERFORCE最新版へのバージョンアップを検討 – 現在は2014.2を利用 – さらなる高速化や新機能に期待

ご清聴ありがとうございました

ご質問はありますか？ • 大規模アセット群と、快適なユーザー作業環境に対してのアプローチ – カプコンでのアセット管理について – Perforceについて – RE ENGINEでのアセット管理について • 『MONSTER HUNTER: WORLD』における快適な作業環境へのアプローチ – 内製ツールの導入 – 導入時のアプローチ – 運用後の問題と改善事例

付録

PERFORCE vs SVN • (株)東陽テクニカのサイトで確認出来ます – http://www.toyo.co.jp/html/ss/perforce/J_Perforce_ subversion.pdf

• http://www.toyo.co.jp/html/ss/perforce/J_Perforce_

用語集 • 中間データ – ツールで扱う編集データ。 • メタデータ – 中間データには含まれない付加情報。 – 編集者、幅、高さ、ハッシュ値、etc… • リソース – 中間データ（＋メタデータ）をコンバートして生成 – 実機で読み込む最適化されたデータ • アセット – 中間データ + メタデータ