各連線的傳送預算與優先順序 Per-connection bandwidth budget and priority

原因 ID pt-priority · 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）

伺服器對每條連線的傳送量設上限、從近的開始送時，上限被設得較低的那一邊，會較晚收到或收不到遠處的 NPC。

為什麼 在人多的地方，伺服器在每條連線的傳送量上限內依重要度依序傳送 → 於是頻寬推估偏低的連線（例：因為是背景視窗而接收確認較慢的那一邊），會一直延後後段的物件 → 畫面上 遠處的 NPC 只在一邊較晚出現或看不見

症狀: 看不見／幽靈物件, 輸入延遲
因素: 延遲
誰會遇到: 同一台電腦只有其中一個用戶端, 特定地點／頻道
何時: 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）
遊戲開發團隊要做的事: 伺服器：被延後的物件隨時間提高優先順序，避免一直輪不到（starvation），並保證最低更新週期。用戶端：在背景也及時送出接收確認，避免頻寬推估降低。
圖表上: 隨人數／負載上升 · 各連線延後的物件數、各連線的傳送量
查看位置: 在伺服器上依連線記錄每個 tick 的傳送位元組、傳送上限（推估頻寬）、沒送出而延後的物件數、各物件距離上次傳送經過的時間。Unreal 可在 Networking Insights 查看各連線的封包大小與其中包含的複製物件
符合的跡象: 看不見的 NPC 是在那條連線上被延後很久的物件，該連線的上限低於其他連線，且越擁擠延後的物件越多
不符合的跡象: 沒有延後的物件、那個 NPC 也及時送出時，問題在傳送之後的環節（接收緩衝區、載入、顯示選項）。所有連線都頂到上限時，是整個伺服器的傳送量或視野設計問題
確認方式: 需要遊戲伺服器／用戶端的 log 與指標

出處

Actor Priority in Unreal Engine Epic Games
頻寬飽和時，依優先順序（距離、視線、上次複製後經過的時間）挑選要複製的 actor。所有 actor 不一定每次都會被複製
State Synchronization Gaffer On Games
優先順序累積：這次沒放進封包的物件會優先放進下一個封包，頻寬上限即時調整
Networking Insights in Unreal Engine Epic Games
顯示各連線收發封包的大小，以及其中包含的複製物件與屬性