パフォーマンスと最適化
インタレスト管理
Fusion BRは、Eventual Consistency レプリケーションモードを使用し、クライアントが興味のあるネットワークオブジェクトに関するデータのみを受け取ることができるようにします。これにより、パフォーマンスが向上し、ネットワークトラフィックが減少します。
各プレイヤーは、カメラの向きに基づいて円錐形の領域を定義し、前方や近くのオブジェクトに関する情報を受信します。
AoI（Area of Interest）は1つのボックスで表現されるため、大きさの異なる複数のAoIを使用することで円錐の形状を実現します。上の画像は、エリアの設定を示しています。プレイヤーは、これらのエリア内のオブジェクトに対してのみステートを受け取り、その他のオブジェクトはスキップされます。
また、このプロジェクトには、パフォーマンスコストとネットワークトラフィックをさらに削減するための特別なコンポーネントが含まれています。
StaticNetworkTransform
スポーン時に静的オブジェクトの位置と回転を一度だけ同期させます。StaticNetworkTransform はアイテムボックスのために使用されます。レベルには何百ものボックスが存在する可能性があり、StaticNetworkTransformの使用は NetworkTransform よりも最適です。
NetworkAreaOfInterestProxy
NetworkAreaOfInterestProxy は、位置や回転の同期は必要ないが、インタレスト管理システムによるフィルタリングが必要なオブジェクトに使用されます。例えば、Agent を所有する親になった武器はトランスフォームを同期させる必要はありませんが、そのネットワークデータは武器がプレイヤーの関心領域内にあるかどうかに基づいて受信される必要があります。AoI計算のための位置は、指定されたオブジェクトから取得されます。武器の場合、所有するエージェントの位置が基準となります。この機能は、ネットワークトラフィックのオーバーヘッドがゼロです。
NetworkCulling
ローカルカリングのための小さなユーティリティです。ネットワークオブジェクトが一定期間、ステートオーソリティから新しいステートを取得しない場合（プレイヤーの AoI 以外）、そのネットワークオブジェクトはカリングされます。
上記の機能はネットワークトラフィックに大きな影響を与えますが、さらなる改善の余地が残されています。
- レベルデザインに基づく、より良いエリアオブインタレストコーンリミット
- 可視性ゾーンの事前計算
- プレイヤーBを撃っているプレイヤーAをプレイヤーBのインタレストオブジェクトのリストに手動で追加して、ネットワークデータを確実に受信して見えるようにすることができる（たとえば、入ってくる弾丸がはるか後ろから撃たれたにもかかわらずプレイヤーに見えるようになるなど）。
インタレスト管理に関する詳しい情報は、Fusion Interest Management セクションにあります。
ベンチマーク
ヘッドレス専用サーバーで安定した60Hzシミュレーションを行うための推奨最大プレイヤー数です。
| 構成（ハードウェア＋ビルドタイプ） | プレイヤー数 |
|---|---|
| Mac Mini M1 2020, Mac server (Silicon) | 200 |
| Core i9-10900K, Windows server | 200 |
| Multiplay Bare Metal (Intel® Xeon® E-2288G @ 3.70GHz), Linux server | 200 |
| Multiplay Virtual Machine (GCP N2 - Intel® Xeon® @ 2.80GHz), Linux server | 60 - 80 |
実際のパフォーマンスとプレイヤー数は、ゲームプレイモードに大きく依存します。すべてのプレイヤーが常にアクティブであるデスマッチは、排除されたプレイヤーのオーバーヘッドが低いバトルロイヤルよりも常に要求が高くなります。また、レベルデザイン（マップサイズ、プレイヤー密度）やゲームプレイデザイン（プレイヤーに常に移動/視線/射撃を強いることは、200人のキャンパーとは異なる影響を与えます）にも影響されます。上記の数値は最悪のケースを表しています。スポーン後の最初の1分間、すべてのプレイヤーが活発に動き、見たり、撃ったりしています。
マルチプレーバーチャルマシンに関する注意
パフォーマンスに影響を与えるもう一つの要因は、現在割り当てられているハードウェアの仕様です。あるマッチ（ゲームサーバー）は60人のプレイヤーを処理するのがやっとですが、別のマッチは100人のプレイヤーを問題なく実行できます。これは、ハードウェアの仕様が異なることが原因です。ベアメタルサーバーで動作させることで、より多くのプレイヤー数を処理し、安定性を向上させることができます。
プロファイリング
一般的なプロファイリングツールに加え、このサンプルではリリースモードのゲームをオフラインで解析するためのツールも提供しています。ゲームを -recordSession パラメータで起動すると、エンジンのデルタタイムとプレイヤー数がフレームごとに記録され、CSV形式のファイルに保存されます。このファイルは提供されたPythonスクリプト(Assets/Extras.zipに含まれています)で処理することができ、グラフ付きのHTMLファイルを生成することができます。
ファイルは Application.persistentDataPath パス、または -dataPath XXX コマンドで指定されたパスに作成されます。
上の画像は、青い線で表示されるプレイヤー数の増加（最大200人）とエンジンのデルタタイム（16ms以上のピークはほとんどなく安定している）を示しています。DeltaTime と PlayerCount 以外に、カスタムの StatsRecorder インスタンスで独自のトラッキングプロパティを作成することができます。
プーリング
シューティングゲームでは、大量のオブジェクトが生成されます（発射物、マズルエフェクト、インパクト、ヒットエフェクトなど）。新しいオブジェクトのインスタンス生成にはコストがかかるため、Fusion BRでは全てのオブジェクトをプールしています。
プールには、2つのタイプがあります。
NetworkObjectPoolは、NetworkObjectsをプールするために使用されます。NetworkObjectPoolはINetworkObjectPoolインターフェースを実装し、NetworkingスクリプトのNetworkRunner.StartGame関数に渡されます。詳しくは、FusionマニュアルのNetwork Object Pool セクションを参照してください。ObjectCacheは、インパクトエフェクトのような非ネットワークオブジェクトに使用される、一般的なGameObjectプールです。指定した時間後にオブジェクトを返す機能がついています。オブジェクトキャッシュは、SceneContextを通して、他の部分からアクセスすることができます。