【Unite Tokyo 2018 フォローアップ】運営中コンテンツにおける大型アップデート成功のための考え方とUnity最適化手法


みなさんこんにちは、Cygames にてシニアゲームエンジニアを務めている金井と申します。

5/9に開催された Unite Tokyo 2018 にて、「運営中コンテンツにおける大型アップデート成功のための考え方とUnity最適化手法」という題名にて弊社の稲田と共に講演を行いました。聴講していただいた皆さま、ありがとうございました。

講演資料の公開と講演後に会場にて多数のご質問をいただきましたので、フォローアップという形になりますが、可能な限りご返答したいと思います。

大型アップデート開発の人数規模はどれくらいですか?

プロジェクト全体での具体的な人数は挙げられないのですが、アップデート作業に従事したプログラマは7人程度です。

3ヶ月と短い開発期間で、どのようなフローで最適化を行ったのですか?

流れとしては、高品質版のルック開発を先行して行い、その後に高品質版が安定して動作する端末のスペックを検証して動作保証できる端末の大まかな目安を付けます。その後、処理負荷計測等を行いチューニングを行っていきます。
ただ、大型アップデートで追加したすべての機能を利用すると処理負荷が非常に高くなるため、利用される現実的な組み合わせを何点かピックアップし、それを元に計測とチューニングを行っています。

モデルの修正が多数入ったと思われますが、修正や追加を行ったデータの品質管理はどのように行ったのでしょうか?

リリース時と同じフローでチェックを行い、品質を担保してます。
アーティストによるDCC上でのチェック、QAによるチェック、ツールによる自動チェック(例えばコリジョンデータのエラー検出)など、一般的なことを行いました。チェックコストは大きくなりますが、大型アップデートの規模を考えると、必要なコストだったと感じています。

シャドウマップのアルゴリズムはどのような物ですか?

一般的な投射テクスチャマッピングを使用しており、カスケードシャドウのような特別なことは行っていません。検証期間中は距離減衰等もテストしましたが、作業時間の兼ね合いからオミットされています。

キャラクターモデルのスペックアップについては行われたのでしょうか?

頂点数が増加しており、主に肩や肘のポリゴンが分割されています。アニメーションの互換性を保つため、補助ボーン等については導入を見送っています。

ETC2フォーマットはiOSで使えないのでは?

その通りで、ETC2フォーマットは主にAndroidプラットフォームでの利用となります。ASTCフォーマットも選択肢として考えられますが、対応している端末数が読めないため、ETC2を採用しています。

リポジトリの管理はどのように行っていますか?

アプリ本体とアセットバンドル化されるフォルダ以下を別リポジトリ化して管理しています。同一リポジトリでの管理は、push/pull時の手間や、アセットバンドルビルド時の手間があり、アセット数によっては非現実的となるためです。

以上、いただいたご質問への返答となります。
みなさまのご参考になれば幸いです。