遊戲 Lag 白皮書 › 同步設計
Rollback netcode 預測失敗 Rollback misprediction
原因 ID sy-rollback · 主要負責 遊戲開發團隊（用戶端開發）
在含圖解與實驗的完整版中開啟卡片 →
先預測對手的輸入並呈現出來，猜錯時就回溯重新計算。ping 越大，回溯的幅度越大。
為什麼 對手改變輸入（與預測不同） → 於是 實際輸入晚了 ping 的一半才抵達，於是回溯這段時間重新計算 → 畫面上 對手的動作跳過幾個畫格或突然改變
- 症狀
- 瞬移
- 因素
- 延遲, 抖動
- 誰會遇到
- 只有我
- 何時
- 做特定動作時, 偶爾隨機發生
- 負責單位
- 主要負責 遊戲開發團隊（用戶端開發）
- 遊戲開發團隊要做的事
- 搭配 1～3 個畫格的輸入延遲以縮小回溯幅度，並設定回溯上限。
- 數值參考
- ping 100ms（單向 50ms）時，在 60fps 下約回溯 3 個畫格。加上 2 個畫格的輸入延遲，就減少到 1 個畫格。
- 圖表上
- 偶爾隨機飆高 · 回溯的畫格數、RTT（ping）
- 查看位置
- 由用戶端在每次回溯時記錄回溯的畫格數、當時的 RTT、輸入延遲設定、回溯與重新計算花費的時間
- 符合的跡象
- 回報對手動作亂跳的瞬間，回溯畫格數很大；平均回溯幅度約為（單向延遲 − 輸入延遲）÷ 畫格時間，ping 越大幅度越大
- 不符合的跡象
- 回溯幅度小卻仍出現卡頓時，是重新計算超過一個畫格時間的效能問題。回溯後兩邊畫面的結果仍持續不同時，是計算結果不一致（desync）
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
出處
- GGPO Rollback Networking SDK GGPO
預測對手的輸入先往下執行，實際輸入不同時，從出現差異的時間點重新計算到現在 - 8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2' GDC
以 rollback 消除 lockstep 的本地輸入延遲，在 16ms 內最多回溯 8 個畫格並重新計算
相關原因
同一層：同步設計
同一症狀（瞬移）在其他層的原因
查看含圖解與實驗的完整版卡片