ハイストリートマーケットがUnityのECSを使用してVR MMOをスケールさせた方法

ハイストリート：カラミティは、ハイストリートマーケットの次世代MMORPGの都市規模のスライスです。チームは、戦闘や進行などのコア機能をテストするために、プレイヤーコミュニティにリリースしました。

この段階で、チームはマルチプレイヤー体験のスケーリングに集中しています。開発中、彼らは技術的なボトルネックに直面しましたが、慎重なプロファイリングと反復を通じて、根本的な問題を特定し対処しました。これが彼らのやり方です。

ハイストリート：カラミティ：Unity のケーススタディ

スタジオは、技術的な課題を克服しながらマルチプレイヤー開発をどのようにスケールさせるのか？

ネットワークゲームの設定を始めたとき、チームは2つの主要な課題に直面しました：計算とレンダリングの非効率性。

「計算の面では、私たちの最大の課題は計算を効率的に処理することでした。これは、世界をシミュレートする任務を負ったサーバーに特に当てはまります」と、ハイストリートのCTOであるジャック・チャオは言います。「プレイヤーやネットワークエンティティが増えるにつれて、サーバーはそれらすべてを効率的に処理するのに苦労しました。」

レンダリングの面では、大規模で没入型VRの世界を構築することは難しいです。「VRは、プレイヤーが探るための多くのオブジェクトや興味のあるポイントを持つ魅力的な環境を要求します」とチャオは説明します。「しかし、スタンドアロンのVRハードウェアは、現代のPC GPUと比較してGPUパワーが限られており、レンダリングできる内容が制限されます。」

品質を維持するために、チームはVRに固有のパフォーマンス制限を考慮しながら、あらゆる角度から見ても良く見えるようにシーンを慎重に設計しました。

成果

最も最適化されたゲームエリアで72 fpsを達成

Scriptable Render Pipeline（SRP）の描画コールの数を80から5に削減

単一メッシュの三角形の数を200万から50万に減少

ネットワーク効率のためにUnity用のECSを採用

チームは最初に、データフローとゲームロジックを処理するためにMirrorのトランスポートレイヤーの上にカスタムサーバーを構築しました。「当時、ほとんどのネットワーキングツールはカジュアルなモバイルタイトル向けに設計されており、大規模なMMOには対応していなかったため、自分たちで作成する必要がありました」と、ハイストリートの技術アーキテクトであるオマール・スレームは言います。

Unityがパフォーマンスと大規模ゲーム向けに構築された生産準備が整ったフレームワークであるNetcode for Entitiesを導入したとき、チームはUnityのエンティティコンポーネントシステム（ECS）とNetcode for Entitiesに移行する機会を見ました。スケーラビリティを考慮して設計されたこのフレームワークは、複雑なゲームデータをより小さく、管理しやすい単位に分割するチャンク化を導入しました。これはチームがMMOにとって不可欠と見なしていたものです。

「Netcode for Entitiesでは、データはサーバー全体にブロードキャストするのではなく、範囲内のプレイヤーにのみ送信されます」とスレームは説明します。「また、マルチスレッド対応で、サーバーの操作がはるかに効率的になります。」

ネットワーキングを超えて、チームはUnity用のECSで完全に構築されたビヘイビアツリーシステムも開発しました。以前のバージョンでは、特にフロー制御に関連する一般的な機能を実装するのが難しかった。UnityベースのカスタムECSビヘイビアツリーは、この制限を解決し、パフォーマンスを損なうことなく柔軟で再利用可能なツールを提供しました。

チームは、サーバー、クライアント、またはその両方でビヘイビアツリーを実行する柔軟性を持たせるために、ネットワーク環境でシステムがシームレスに動作するように設計しました。これにより、非重要な動作をクライアントにオフロードし、パフォーマンスを向上させながら、コアゲームロジックの中央集権的な制御を維持できました。

ゲームのセッションベースの構造を管理するために、チームはUnityのマルチプレイヤーサービスエコシステムに依存しました。Multiplay Hostingは、ゲームのセッションベースの性質に理想的な動的サーバー割り当てを可能にしました。「自動化により、DevOpsの負担が軽減され、ゲーム自体の構築に集中できるようになりました」とSleamは言います。Matchmakerは、設定や場所などのさまざまな要因に基づいてプレイヤーをグループ化するために使用され、バランスの取れた低遅延のマッチを確保するのに役立ちました。

Unity Lobbyは、プレイヤーがゲームセッションに参加する前にグループを形成し管理できるように、パーティーシステムを支えました。FriendsはLobbyと統合され、異なるサーバー間でパーティーを維持し、プレイヤーが最小限の実装努力で接続を保つことを可能にしました。

これらのツールは、ホスティング、マッチメイキング、パーティー管理、ソーシャルシステムをカバーする完全なマルチプレイヤーのバックボーンを提供し、実装を軽量でスケーラブル、高性能なゲームプレイに最適化しました。

Unity用ECSによるモジュール性の向上

チームは、GameObjectベースの設計からUnity用ECSへの移行中に急激な学習曲線を経験しましたが、オンボーディング後は生産性が大幅に向上しました。

「Unity用ECSは多くのオーバーヘッドを削減しました。これは部分的にはそのアーキテクチャによるものであり、部分的にはトップダウン設計アプローチに移行したためです」とQiaoは言います。「GameObjectsとは異なり、注意深く設計されていない限り、重複したロジックを引き起こすことが多いですが、Unity用ECSはモジュール式のコンポーネントベースの設計を強制しました。これにより、自然にクリーンでメンテナンスしやすいシステムが促進されました。」

チームは、Unity用ECSの最大の利点の1つは、ゲームデザインの変更を扱うのがどれほど簡単であるかだと共有しました。「古いシステムでは、変更にはしばしば複数のMonoBehaviourスクリプトに触れる必要がありました。Unity用ECSでは、動作はそれらのコンポーネントにリンクされたシステムによって駆動されるため、コンポーネントを追加または削除するだけで多くの変更が可能です」とQiaoは言います。「全体として、変更可能性とスケーラビリティはUnity用ECSで大幅に改善され、開発パイプラインが非常に効率的になりました。」

チームは、ゲームアーキテクチャに関する大きな課題にも取り組みました。従来のソフトウェアとは異なり、ゲームロジックはコードだけでなく、そのコードがどこに存在するかにも依存します。例えば、車のホイールに回転スクリプトを付けると動きをシミュレートしますが、同じスクリプトをスカイボックスに適用すると昼夜サイクルを駆動します。この空間的および階層的な依存関係は、チームがコードだけでなく、配置と階層の観点からもシステムを設計する方法を必要とすることを意味しました。

これに対処するために、チームのソフトウェアアーキテクトであるモハメド・ハムディは、UnityのECSのためのクリエイティブなグラフベースのアプローチを考案しました。この方法により、チームはエンティティ、コンポーネント、オーサリング、システムを視覚的かつモジュラーな方法で設計し、それらの配置と設定を定義することができました。そうすることで、小さな再利用可能なコードのブロックが、適用される場所によって非常に異なる目的を達成できるようになりました。

このシステムは後に、UnityのECSエンティティだけでなく、MonoBehaviour、GameObject、ビヘイビアツリー、Unityのビヘイビアグラフを統合するように拡張されました。Lucidchartの図とExcelシートの組み合わせを使用して、チームはゲーム全体のアーキテクチャを明確かつ効率的にマッピングし、検証しました。今後、彼らはこのアーキテクチャ手法を完全にエディタで可視化するための専用のUnityツールを構築する計画を立てており、実際の実装に対して検証する能力を持たせる予定です。

ハイブリッドアーキテクチャシステムを使用する

カスタムサーバーから移行した後、チームは最初に完全なECS for Unity物理アプローチを採用しました。彼らはこの方法を、特にサーバー側での効率的なデータ処理とスケーラビリティのために選択しましたが、特定のCPU側のレンダリング最適化のためでもありました。

「1つの重要な利点は、ECS for Unityが従来のボーンベースのシステムよりもはるかに効率的に処理できる頂点アニメーションを介してスキンメッシュアニメーションを扱うことです」と、ハイストリートマーケットのテクニカルアーティストであるアルウィン・ジョシーは言います。「しかし、VRでは、CPUとGPUの両方が制約を受けており、ECS for Unityベースのアニメーションの恩恵を完全に受けるためには、まずシーンの複雑さを減らしてリソースを解放する必要がありました。」

ゲームの複雑なアニメーションのために、彼らのワークフローはECS for UnityとMonoBehaviourを組み合わせたハイブリッドシステムに進化しました。

画面上に複数のキャラクターを視覚化するために、彼らは一部の処理をGPUにオフロードしました。ネットワークとゲームループの論理的側面からCPUが過負荷になることが明らかだったため、彼らはルカンカアニメーションシステムを採用しました。

「物理学については、すべての物理エンティティをサーバーとクライアント間で同期させ、メインの物理ワールド上に構築しました」とスリームは説明します。「最初は複雑でした。サーバーはすべての物理エンティティを同期させていました。その後、複数の物理ワールドを持つことを探求し、ECS for Unityでローカル物理計算を続けるか、MonoBehaviourでローカル物理を行うかの選択に直面しました。

MonoBehaviourは、ボタンを押したり、手が壁を通り抜けないようにするなど、リアルな物理的相互作用を可能にするHurricaneやFreehandなどのサードパーティのVRツールとの統合を許可します。一方、UnityのECSは、MonoBehaviourのようにストアに利用可能な既製のサードパーティツールがなかったため、チームがこれらのシステムをゼロから構築する必要がありました。

「最終的に、クライアント側のVRインタラクション、例えば手の衝突にはMonoBehaviourを使用して、応答性と没入感を確保しました」とSleamは言います。「一方、サーバー側の物理演算は、モンスターを攻撃するなどの重要なゲームプレイインタラクションを処理しました – 検証のために。」

このハイブリッドアプローチは、セキュリティと没入感のバランスを取り、チートを防ぐためにサーバー上でゲームプレイに重要な衝突判定を実行し、クライアント上でローカルで重要度の低いインタラクションを管理します。

安定したVRパフォーマンスのためのドローコールの削減

UnityのECSとRukhankaはスケールの可能性を開きますが – 例えば、数千のアニメーションキャラクターをサポートすること – チームのVRにおける最大の課題の一つは、特に厳しいCPU/GPU制約の下でのパフォーマンス最適化でした。

「従来のゲームとは異なり、VRはCPUとGPUの両方を完全に負荷させます」とJoshyは説明します。「オフロードは、シーンが高度に最適化されていない限り、常に選択肢ではありません。」

プロジェクトを構築した後、彼らは最初にMeta QuestのOVR statツールを使用して、重いエリアやフレームドロップを特定するための予備的なパフォーマンスチェックを実行しました。次に、開発ビルドを作成し、Meta QuestをUnity Profilerに接続して、CPU-GPUデータ転送、テクスチャメモリ使用量、レンダリング階層、およびドロータイミングを分析しました。

「パフォーマンスを向上させるために、最近は手動でレンダリングを制御することでドローコールの中断を減らすことに焦点を当てています。ライティングは大きな課題でした – 最初はサイズを減らすためにトゥーンスタイルの圧縮でライトマップをベイクしましたが、ライトマップされたオブジェクトと非ライトマップオブジェクトを混ぜるとシェーダーのバリアントの問題が発生しました」とJoshyは言います。「これを解決するために、私たちはライトマップを完全に放棄し、完全に環境照明されたトゥーンシェーダーを採用しました。これにより、より一貫したパフォーマンスとレンダリングの制御が得られました。

チームはまた、段階的な減衰を持つスポットライトを使用し、シェーダーバリアントを最小限に抑えました – 不透明および透明クリップ用の1つのセルシェーダー、そしておそらく草用です。彼らは手動でドロー順序を制御しました：不透明オブジェクトはレイヤー1、透明オブジェクトは2、クリップオブジェクトは3。これにより、バッチ処理を一貫させることでドローコールの中断を減らすことができました。

「ドローコールを分割する隠れた問題をキャッチするために、私たちはUnity Frame Debuggerに大いに依存してバッチ処理とドロー順序を確認しました」とJoshyは続けます。「GPUプロファイリングは、レンダリングの最適化とドローコールのオーバーヘッドを削減するための主要なツールの一つでした。」

柔軟性とパフォーマンスのバランス

チームが開発を拡大するにつれて、特に戦闘が行われるアリーナシーンでレンダリングの課題に直面しました。

「私たちの目標は、Meta Quest 2のようなデバイスで72fpsを維持することですが、三角形の数が500,000未満でも、パフォーマンスの問題に直面しています」とJoshyは言います。

彼らはGPUシェーダーの切り替えを減らすためにSRPバッチャーを使用していますが、スタンドアロンVRでは、GPUの制約はPCよりもはるかに厳しいです。「私たちは、200万の三角形を持つシーンでも、単一のメッシュと単一のマテリアルであればスムーズにレンダリングされることがわかりました。しかし、私たちのゲームのオープンで垂直な環境では、そのような単純化は実用的ではありません」とJoshyは言います。

パフォーマンスを向上させるために、チームは以下の方法でドローコールを最小限に抑えることに焦点を当てました：

アートチームによるカスタムメッシュベーキング

マテリアルの柔軟性とバッチ処理のバランスを取るためにアセットをサブメッシュにグループ化する

世界をチャンク化し、アセットごとではなくチャンクレベルのLODを生成する

Unity互換のシステムのためにECSを使用してチャンクをストリーミングする

LODシステムだけを使用することで、シーンを約200万の三角形から500,000に削減するのに役立ちました。

このアプローチは、いくつかの柔軟性を犠牲にし、アーティストの作業負荷を増加させましたが、特にMeta Quest 2のようなデバイスではハードウェアの制限を考慮すると必要でした。

「最終的に、ドローコールを80から5に最小限に抑えることが私たちの最大の勝利です」とJoshyは言います。「私たちはそれに基づいてコンテンツとワークフローを再構築しています - たとえそれがマテリアルの多様性を制限することになっても - 現在のハードウェアで安定したVRパフォーマンスを得るための最も実行可能な道だからです。」

スマートな方法でのスケーリング

チームがVR MMORPGを開発する中で、彼らが最も重要な考慮事項と見なすスケーリング、アーキテクチャとグラフィックスの両方の観点からのスケーリングに引き続き焦点を当てています。

「初日から大規模なMMOを目指すなら、高いエンティティ数と同時ネットワークを処理するためにUnity用のECSが必要です。最初から非常に詳細なビジョンがない場合、段階的にスケーリングするのも良い方法です」とQiaoは言います。「私たちは最初に「0から100」のアプローチを取り、ピークスケールのために早期に最適化しました。振り返ってみると、私たちはインフラを早すぎる段階で過剰に構築し、ゲームプレイやコンテンツに向けられるべきリソースを消費しました。」

グラフィックスの観点から、チームはVRの利点と欠点を認識しています。「有機的で柔らかいメッシュは、かなりの計算リソースを消費し、VRではうまく機能しません。私たちのゲームは有機的な要素を持つトゥーンスタイルを使用しており、キャラクターや環境デザインなどの他の領域のグラフィックス予算を制限しています」とQiaoは言います。

全体として、チームはVRゲームのパフォーマンスを最大化するために、クリーンで低詳細なテクニカルスタイルの環境を選択することを推奨しています。「クリーンなシーンデザインとワールドビルディングを行うことで、他のキャラクターデザインや構造デザインのためのグラフィックスやリソース予算を増やすことができます。パフォーマンスを考慮して設計することが重要です」とQiaoは言います。

Unity Pro を今すぐダウンロード

強力なツール、サポート、公認パートナー、活発なコミュニティの力を利用して、大規模スタジオがリリースするタイトルの品質と成功に勝るとも劣らないゲームの制作を開始しましょう。