パフォーマンスと最適化

インタレストマネジメント

BR200では、最終的整合性（Eventual Consistency）リプリケーションモードを使用しており、クライアントは関心のあるネットワークオブジェクトに関するデータだけを受け取ることができます。これにより、パフォーマンスが向上し、ネットワークトラフィックが削減されます。詳細はインタレストマネジメントマニュアルをご覧ください。

各プレイヤーは、カメラの方向に基づいた円錐状の範囲を定義し、その範囲内の前方や近くのオブジェクトに関する情報を受け取ります。プレイヤーの関心範囲を設定するために、インタレストマネジメントアドオンが使用されます。

プレイヤーは、その範囲内のオブジェクトの状態のみを受信し、それ以外のオブジェクトは同期されません。

BR200には、パフォーマンスコストとネットワークトラフィックをさらに削減するための特別なコンポーネントも含まれています。

StaticNetworkTransform
静的なオブジェクトの位置と回転を一度だけ同期するためのコンポーネントです。これにより、生成時に静的オブジェクトの位置と回転を一回だけ同期します。StaticNetworkTransformはアイテムボックスなどに使用されます。レベル内に数百個のアイテムボックスが存在する場合でも、NetworkTransformよりもより最適なパフォーマンスを発揮します。

NetworkAreaOfInterestProxy
NetworkAreaOfInterestProxyは、位置や回転を同期する必要のないオブジェクトで、しかし関心管理システムによるフィルタリングは必要な場合に使用されます。たとえば、所有しているAgentの子として親子関係にある武器は、位置や回転を同期する必要はありませんが、その情報はプレイヤーの関心エリア内にあるかどうかに基づいてネットワーク経由で受信されるべきです。この場合、AoI計算に使われる位置は、特定のオブジェクトから取得されます。武器の場合は、所有しているエージェントの位置を基準にします。この機能はネットワークトラフィックにほとんど影響を与えません。

上記の機能はネットワークトラフィックに大きな影響を与えますが、さらに改善できる余地もあります。

• 💡 レベルデザインに基づく関心エリアのコーン制限の改善
• 💡 事前計算された可視ゾーンの導入

関心管理に関する詳しい情報は、インタレストマネジメントマニュアルアニュアルおよびインタレストマネジメントアドオンをご覧ください。

ベンチマーク

ヘッドレスの専用サーバーインスタンスで安定した60Hzのシミュレーションを実現するための推奨最大プレイヤー数は以下の通りです。

実際のパフォーマンスとプレイヤー数は、ゲームプレイのモードによって大きく異なります。デスマッチ（全てのプレイヤーが常に活動している状態）は、エリミネーションされたプレイヤーが少ないバトルロイヤルよりも常に高負荷です。また、レベルデザイン（マップのサイズやプレイヤー密度）やゲームプレイの設計（プレイヤーに常に移動・見回し・射撃を強いる場合と、200人のキャンパーがいる場合では影響が異なる）も影響します。上記の数字は最悪のケースシナリオを示しており、スポーン後の最初の1分間にすべてのプレイヤーが積極的に移動・見回し・射撃している状況を想定しています。

Unityゲームサーバーホスティングの仮想マシンについての注意点：
パフォーマンスに影響を与えるもう一つの要因は、現在割り当てられているハードウェアの仕様です。１つのマッチ（ゲームサーバーインスタンス）が60人をほぼ対応できる程度でも、別の環境では100人を問題なく対応できる場合もあります。これはハードウェアの仕様の違いによるものです。より多くのプレイヤーの対応や安定性の向上には、ベアメタルサーバーでの運用を推奨します。

プロファイリング

このサンプルは、一般的なプロファイリングツールに加えて、リリースモードでのオフライン解析用のツールも提供しています。ゲームを-recordSessionパラメータで起動すると、エンジンのデルタタイムやプレイヤー数が毎フレーム記録され、それらのデータはCSV形式のファイルに保存されます。その後、このファイルはAssets/Extras.zip内の提供されているPythonスクリプトで処理でき、グラフ付きのHTMLファイルを生成します。

作成されるファイルは、Application.persistentDataPathのパスに保存されるか、-dataPath XXXコマンドで指定されたパスに保存されます。

上の画像は、青線で示される最大200までのプレイヤー数の増加と、エンジンのデルタタイム（ほとんどの時間で16msを超えるピークが少ない安定した状態）を示しています。DeltaTimeとPlayerCountの他に、独自の追跡したいプロパティのセットをカスタムのStatsRecorderインスタンスで作成することも可能です。

プーリング

シューター系のプロジェクトでは、多くのオブジェクトのスポーン（発射弾、銃口エフェクト、衝突エフェクト、ヒットエフェクトなど）が期待されます。新しいオブジェクトのインスタンス化はコストが高いため、BR200ではすべてのオブジェクトをプーリングしています。

プールには2種類あります：

• NetworkObjectPool
  これはNetworkObjectsをプールするためのもので、INetworkObjectProviderインターフェースを実装しています。このプールは、Networkingスクリプト内のNetworkRunner.StartGame関数に渡されます。詳しくは、FusionマニュアルのNetwork Object Providerセクションを参照してください。

• ObjectCache
  これは汎用的なGameObjectプールで、ネットワーク非対象のオブジェクト（例：インパクトエフェクト）に使用されます。一定時間後にオブジェクトを返却する機能も備えています。ObjectCacheには、SceneContextを通じてアクセスできます。