Optimizing Deep Rock Galactic Survivor for mobile
Adam Axler - Unity
Senior Content Marketing Manager
このウェブページは、お客様の便宜のために機械翻訳されたものです。翻訳されたコンテンツの正確性や信頼性は保証いたしかねます。翻訳されたコンテンツの正確性について疑問をお持ちの場合は、ウェブページの公式な英語版をご覧ください。
複雑なPCゲームをモバイルのプレイヤーに提供するには、何が必要でしょうか？ファンデイゲームズのディープロックギャラクティック：サバイバー弾幕シューティングループと、 『Deep Rock Galactic 』のドワーフ、クラス、武器、そして採掘メカニズムを組み合わせた作品。移植を担当したPiktiv社にとっての課題は、数千もの敵や環境要素を同時にシミュレートしながら、GPU、CPU、メモリのバジェットがごくわずかなハードウェア上で安定したフレームレートを維持することだった。
モバイルでその体験を実現するには、敵の数に応じてコストが増加するシステム、つまり経路検索、物理演算演算クエリ、敵のレンダリング、ダメージ数値、環境レンダリングなどを再構築する必要があった。開発チームは、ゲームを3GBのiPadに収めるだけでなく、最新のフラッグシップモデルから数年前のAndroid端末までスプレッドにサポート、さらに開発が活発に行われているPC版との一方的なマージを維持する必要もあった。
エンジニアリングマネージャーのマーカス・エケルンド氏と主任エンジニアのフレドリック・アケルブロム氏に、移植について話を聞きました。ディープロックギャラクティック：サバイバーモバイルにおける彼らのカスタムソリューション、そして断片化されたデバイスランドスケープ全体でどのようにパフォーマンスを最適化したか。
Funday GamesとPiktivの間で、引き継ぎはどのように行われたのですか？
マーカス・エケルンド：PC版がまだ開発段階だった頃に分岐オフたため、モバイルポートの開発を開始した時点ではPC版はバージョン1.0に達していませんでした。当初の計画では、モバイル版をメインブランチにマージ予定だったのですが、開発過程で大きく乖離してしまったため、その意味ではまだ別々の状態です。PCからモバイルへとマージので、一方通行ではありますが、逆方向では統合されません。
ポートに関して技術的に行った作業については、あまり協力関係はなかった。UIとUX、そしてUIをどのように適応させるかについては、他にも多くのことがありました。それによって私たちは非常に迅速に行動することができ、また、既存のシステムからオフしたことで、彼らが構築した多くのシステムを破壊的に改変することができました。つまり、それらを解体し、全く異なるアプローチを取ることができたのです。なぜなら、私たちは異なる最適化目標を念頭に置いていたからです。
モバイルポート開発にあたって、最も重視した技術目標は何でしたか？
フレドリック・オーケルブロム：正面私たちが掲げた技術的な目標の多くは、単純に以下の通りでした。これをモバイルで動作させることは可能でしょうか？また、どの程度のスパンのデバイスにヒットできるでしょうか？Apple製品を外観と、実際に配送できる細かな粒度はそれほど多くありません。最新の製品があり、次に現在入手可能な多くの製品を含む少し広いカテゴリがあり、そしてその他すべてがある。少なくとも中間カテゴリをヒットべきだ。
繰り返し発生した問題の一つは、iPad 1台を除いて、すべてのデバイスに4GBのRAMが搭載されているにもかかわらず、iPad 1台だけが3GBしか搭載していないことでした。そこで、それが主要な技術目標となった。このiPadでクラッシュせずに動作させることはできますか？使える容量は約1,850MBで、その制限を超えるとゲームオーバーだった。初期の作業の多くは、RAMを適切に調整することに費やされ、その後、さまざまなプラットフォームでのゲームの実際のパフォーマンスをより詳細に外観ことができました。一方、 Androidは現時点で約9,000種類ものデバイスが存在するため、それらすべてが正常に動作するようにすることは、独自の専門知識を要する。
ディープロックギャラクティック：サバイバー | ファンデーゲーム
PCからモバイルハードウェアへのヒットにおいて、最も大きなパフォーマンス上のボトルネックは何でしたか？また、それらをどのように克服しましたか？
FÅ:特に目立ったコアシステムはいくつかあり、それらは数千ものアクティブなオブジェクトを抱えていた。ダメージ数値、発射物、ワールド観そのもの、そしてアニメーション化された3Dの敵キャラクター。
例えば、ダメージテキストは元々 TextMesh Proを使用したゲームオブジェクトでした。しかし、画面上に1000体の敵がいて、それらに手榴弾を投げつけると、すべての敵にダメージ数値を表示する必要がある。ボトルネックはテキストメッシュの生成です。フォントが文字文字列を視覚的なものに変換する。
終了的には、0から9までの数字のスプライトシートを使用した、通常のUnityパーティクルシステムを採用しました。
自分：もう一つの例は、 PCにビルトインナビメッシュシステムを使用した、すべての敵の経路検索です。また、 Unityのエンジニアチームからもサポートを受けており、そのうちの一人がフローフィールドナビゲーションを用いた解決策の開発に着手しました。別のエンジニアは、物理演算クエリの多くを最適化するために、KDツリーを用いたソリューションを構築した。
FÅ:敵のレンダリングでは、画面に同時に約1000個ものスキンメッシュレンダラーされることになり、それではうまく機能しません。実際には、これらの敵キャラクターはほぼ全て単一のアニメーションしか持っていないため、複数のアニメーションをサポート必要は実際にはありません。
その代わりに、このシステムではアニメーションの各キーフレームをテクスチャに焼き付ける方式を採用しています。私たちはこのようにすべてのフレームを処理し、それらすべてをGPU上のシェーダーによって頂点アニメーション化します。そのため、CPU負荷は実質的に発生しません。
単一の静的メッシュとテクスチャにベイク処理することで大きな改善が見られ、技術的にはすべて同じメッシュとマテリアルになっているため、 GPUインスタンス化などの処理も可能になります。
ディープロックギャラクティック：サバイバー | ファンデーゲーム
フローフィールドとKDツリーは内部でどのように動作するのか、また、それらは何を置き換えたのか？
FÅ:フローフィールドは、経路検索におけるコストが発生する場所の反転である。通常、20 個または 30 個のエージェントが環境内を経路検索場合、その環境のメッシュをベイク、各エージェントが自身の経路検索を担当します。エージェントが数千台になると、コストはエージェントの数にスケールして増加する傾向があるため、それはかなり大きなボトルネックになります。
レベル全体にグリッドを作成し、ターゲット地点から開始と、その周囲のすべてのタイルが目標地点を指す矢印を描画。一ステップ前に出て、すでに矢印が描かれている最も近いものに再び矢印を向け、フィールド全体をカバーするまでこれを繰り返します。つまり、エージェント1人あたりのコストではなく、経路探索を行う領域のサイズに基づいてコストが決まるということです。
さらに制限することも可能です。敵の位置に基づいて計算を行うため、すべての敵とプレイヤーを含むバウンディングボックスを作成し、その内部のスペースのみを更新。
空間クエリには、KDツリーを使用しました。広い部屋があって、その真ん中に線を描画と、突然その部屋は二つの空間に分割される。簡単にクエリできるツリー構造体を作成します。ここに点と半径があります。そこにあるものを何でもください。
それは、例えば「ここで手榴弾が爆発したので、この円の中にいるすべての敵を見つけなければならない」といった、より複雑な物理演算演算クエリの多くを置き換えることができるだろう。終了的に完璧な適合だったかどうかは確信が持てません。なぜなら、KDツリーを頻繁に再生成する必要があるからです。敵は常に移動しているので、KDツリーを頻繁に再構築する必要があるのです。
流れ場
モバイルデバイス全体でのテストとチューニングはどのように進めましたか？
FÅ:まず最初に行ったことの一つは、ゲームが動作するはずのデバイス、つまり少なくとも30fpsは出せるであろう比較的低スペックなデバイスを確立することでした。
私たちは、一連のシナリオを設定できる自動パフォーマンス測定システムを構築しました。合計6つのシナリオを実行しましたディープロックギャラクティック：サバイバー。この測定モードに合わせてゲームをビルドすれば、デバイス上で起動するとすぐにバイオームに入り、6つのシナリオが実行されます。
一つは、プレイヤーが静止した状態から始めて、プレイヤーに向かって移動する1000体の敵をスポーンというものです。もう一つは、500体の敵をスポーン、プレイヤーにこれらの武器をすべて装備させて、あらゆる方向に自動的に発射させるというものです。そうすることで、何が起こっているのかをビットスプレッドできます。CPU、GPU、メモリなど、測定可能なものはほぼすべて測定します。すべてのバイオームで実行することで、特定のバイオームにパフォーマンス上の問題がないかどうかを確認できます。
Unity Profilerは、特に初期段階で容易に改善できる点や最大の効果が得られる点を探していた時期に、CPUパフォーマンス監査のための主要ツールの1つでした。
ディープロックギャラクティック：サバイバー | ファンデーゲーム
Addressablesは、モバイルにおけるコンテンツとメモリ使用量の管理にどのようにヘルプたのでしょうか？
FÅ:Addressablesは、iPadの3GBメモリ制限を達成する上で重要な役割を果たしました。概して、私たちは早い段階で、分かりやすいと感じられた事柄から着手しました。例えば、異なるバイオームが存在する場合、同時に複数のバイオームにいることはないので、それらのグラフィカルなアセットや設定をすべて切り離すことができます。
Addressablesは、これまで完全に同期していたものに非同期動作を導入するものであり、ゲームによっては、システム全体を非同期に再構築することは、かなり大きなアーキテクチャの課題となる可能性があります。しかし、この状況においては、それは私たちにとって最適な選択だった。
ディープロックギャラクティック：サバイバー | ファンデーゲーム
モバイル版の成功を測るために、どのようなパフォーマンス指標を追跡していますか？
FÅ:私たちの目標のほとんどは、業績に関連したものでした。これらのモデルでは30fpsをヒット、フラッグシップモデルでは60fpsを期待しています。
でディープロックギャラクティック：サバイバー虫を倒すと、たくさんの青く光る立方体が飛び出してきて、それを拾うことでレベルアップできます。自動計測シナリオの一つでは、10秒間に約4,000件もの計測が発生し、初期段階で深刻なパフォーマンスヒットました。最初の最適化を行った後は、もはや測定不可能だった。
敵の動きと物理演算を最適化したことで、フレームレートの下限も大幅に向上した。それが流れ場となり、さらに通常の物理演算システムとは無関係に、すべての敵を移動させる役割を担う、10個から15個もの依存関係を持つ一連のBurstジョブへと発展した。
このゲームはレベルを継続的に生成するため、1階部分とすべての壁は個々のオブジェクトから構築されます。常に同じ角度で上空からのカメラを使用しているため、物体が見えるボックスを簡単に計算し、それらのオブジェクトをすべて収集して、独自のバッチ描画コマンドを使用してレンダラーに送信することができます。これはGPUにとってもCPUにとっても大きな改善だった。なぜなら、それらの描画呼び出しを個別に送信するのは、CPUにとってかなりの負荷だったからだ。
ディープロックギャラクティック：サバイバー | ファンデーゲーム
PCゲームをモバイル向けにポートうとしている開発者への、あなたの一番のアドバイスは何ですか？
自分：重要なのは、特効薬を見つけることではなく、常に異なるシステム間の連携である。
FÅ:毎フレーム数千ものエンティティを処理するようになると、さまざまなコンポーネント間でデータを出し入れするコストがかなり大きくなり始めます。データをネイティブコンテナに格納し、プロセス全体を通して同じネイティブコンテナを使用するように管理できれば、大きな利益を得ることができます。
自分：このプロジェクトから得られたもう一つの教訓：例えば、ゲームを開発したとして、完成後にUnity用のECSや、データ指向テクノロジースタック（DOTS）システムのいずれかを使用して開発すべきだったと気づくことがあるとします。ゲーム全体を完全に変換して書き直す必要はありません。私たちはBurstコンパイラーと多くのネイティブデータ型のみを使用しています。
ディープロックギャラクティック：サバイバーSteam、 Xbox 、 App Store 、 Google 再生で入手可能です。Unity開発者によるその他の記事は、 Unityブログとリソースハブをご覧ください。