Performance & Optimizations

興趣管理

BR200使用最終一致性複製模式，該模式允許客戶端僅接收他們感興趣的網路物件的資料。這提高了效能並減少了網路流量。在興趣管理操作手冊中瞭解更多資訊。

每個玩家都會基於相機的方向定義一個錐形區域，以接收前方和附近物體的資訊。興趣管理附加元件用於定義玩家的興趣。

玩家只接收區域內物件的狀態，其他物件不同步。

BR200還包含特殊元件，以進一步降低效能成本和網路流量：

StaticNetworkTransform
生成時靜態物件的一次性位置/旋轉同步。StaticNetworkTransform用於物品盒。關卡中可能有數百個盒，StaticNetworkTransform的使用比NetworkTransform更佳。

NetworkAreaOfInterestProxy
NetworkAreaOfInterestProxy用於不需要同步位置或旋轉但仍需要由興趣管理系統篩選的物件。例如，擁有Agent的武器不需要同步轉換，但應根據武器是否在玩家感興趣的區域來接收其連網資料。興趣區域計算的位置取自指定的物件。就武器而言，它是基於擁有代理的位置。此功能的網路流量耗用為零。

儘管上述功能對網路流量有重大影響，但有一些改善更好的地方：

• 💡 基於關卡設計的更好的興趣區域錐形限制
• 💡 預先計算的可視區域

有關興趣管理的其他資訊可以在興趣管理操作手冊與興趣管理附加元件中找到。

基準

在無周邊專用伺服器執行個體上進行穩定60Hz模擬的建議最大玩家數：

實際效能和玩家計數在很大程度上取決於遊戲模式。死亡競賽是所有玩家都一直活躍的比賽，它總是比淘汰後玩家耗用低的皇家對戰的要求來得更高。它也受到關卡設計（地圖大小、玩家密度）和遊戲設計的影響（強迫玩家不斷移動/觀看/射擊的影響，與200名不太移動者的影響不同）。上面的數字代表了最壞的情況——生成後的第一分鐘——所有玩家都在積極移動、查看和射擊。

關於Unity Game Server Hosting虛擬機器的附註： 影響效能的另一個因素是當前指派的硬體的規格。雖然一場對戰（遊戲伺服器執行個體）可能幾乎無法處理60名玩家，但另一場比賽可以運行100名玩家卻沒有任何問題。這是由於不同的硬體規格造成的。建議在裸機伺服器上運行，以獲得更高的玩家計數和更好的穩定性。

分析

除了常見的分析工具外，此範例還提供了用於在發佈模式下進行遊戲離線分析的工具。當使用-recordSession參數啟動遊戲時，每幀都會記錄引擎差量時間和玩家計數，並以CSV格式存儲在檔案中。然後，可以透過提供的Python指令碼（可在Assets/Extras.zip中獲得）處理該檔案，該指令碼將生成帶有圖表的HTML檔案。

檔案是在Application.persistentDataPath路徑或-dataPath XXX命令中指定的路徑上建立的。

上圖顯示了由藍線和引擎差量時間表示的玩家計數不斷增加（高達200）（大部分時間都是穩定的，在16ms以上幾乎沒有峰值）。除了DeltaTime和PlayerCount，您還可以使用自訂的StatsRecorder執行個體建立自己的一組追蹤屬性。

池

在射擊專案中，預計會生成大量物件（拋射物、槍口效應、撞擊、命中效應等）。由於一個新物件的具現化是花費巨大的，所以BR200中的所有內容都是池化的。

有兩種類型的池：

• NetworkObjectPool 用於對NetworkObjects進行池化。NetworkObjectPool執行了INetworkObjectProvider介面，並被傳遞到Networking指令碼中的NetworkRunner.StartGame功能中。有關更多資訊，請查看Fusion操作手冊中的網路物件提供者部分。

• ObjectCache 是一個通用的GameObject池，用於非連網對象，如衝擊效果。它具有在指定延遲後傳回物件的功能。ObjectCache在程式碼的其他部分可以透過場景內容存取。