快照傳送頻率太低 Low snapshot / update rate

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

伺服器每秒只送幾次位置更新（快照）時，內插緩衝就得相應拉長，看到的其他角色會是更久以前的狀態。

為什麼 為了節省傳輸量，每秒只送 5～10 次位置更新 → 於是要畫得流暢，緩衝就得設成封包間隔的 2 倍（200～400ms）；設得短的話，只漏掉一個封包就會停住 → 畫面上 對手轉向較晚才看到，與判定不一致。緩衝短時會卡頓，封包遺失時出現瞬移

症狀: 卡頓, 瞬移, 吃指令／回檔
因素: 延遲, 遺失
誰會遇到: 整個伺服器
何時: 一直都有
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）
遊戲開發團隊要做的事: 伺服器：近距離或戰鬥中的目標送得頻繁、遠處目標送得少；只送有變化的部分（差異壓縮），縮小單次大小並提高頻率。用戶端：依封包間隔自動調整內插緩衝長度。
數值參考: 每秒 10 次的話封包間隔 100ms、緩衝 200ms。再加上 ping 150ms 的單向延遲 75ms，看到的對手約是 0.3 秒前的狀態。
圖表上: 一開始就一直偏高 · 各用戶端的封包抵達間隔、內插緩衝長度
查看位置: 在伺服器端封包擷取中只篩選送往某位玩家的流量，用 Wireshark 的 I/O Graphs 查看每秒封包數與間隔。有遊戲端 log 的話，同時查看各物件的更新間隔與用戶端內插緩衝的餘裕（距離下一個快照抵達的剩餘時間）
符合的跡象: 位置更新一直很稀疏，每秒 5～10 次（間隔 100～200ms），內插緩衝設得超過 200ms，或緩衝餘裕經常歸 0
不符合的跡象: 更新送得很密、只有抵達間隔不穩時，是抖動或封包遺失。人多擁擠時只有遠處物件收得少，是各連線的傳送預算與優先順序
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
每秒 10 次更新時，內插 200ms 可以承受一次遺漏。Half-Life 預設為每秒 20 次、內插 100ms
Snapshot Interpolation Gaffer On Games
每秒 10 個的話，要承受連續兩個遺失需要 350ms 延遲；每秒 30 個時可降到 150ms
State Synchronization Gaffer On Games
以優先順序累積讓重要物件更常送出，並在頻寬上限內輪流傳送其餘物件
8.8. The “I/O Graphs” Window Wireshark
把符合顯示篩選器的封包數、位元組數依時間區間畫成圖表