游戏卡顿白皮书 › 同步设计
回滚网络代码预测失败 Rollback misprediction
原因 ID sy-rollback · 主责 研发团队·客户端开发
在含图示和实验的完整版中打开此卡片 →
先预测对手的输入并显示出来，猜错了就回滚重新计算。ping 越高，回滚的幅度越大。
起因 对手改变了输入（与预测不同） → 结果 实际输入晚到约半个 ping，就要回滚这么长时间重新计算 → 画面表现 对手的动作跳过几帧或突然改变
- 症状
- 瞬移
- 因素
- 延迟, 抖动
- 谁会遇到
- 只有我
- 何时出现
- 做特定操作时, 偶尔随机
- 负责方
- 主责 研发团队·客户端开发
- 研发团队要做的事
- 混入 1~3 帧输入延迟以减小回滚幅度，设置回滚上限。
- 数值参考
- ping 100 ms（单向 50 ms）时，60 FPS 下约回滚 3 帧。设置 2 帧输入延迟后减少到 1 帧。
- 监控图上
- 偶发随机尖峰 · 回滚帧数，RTT（ping）
- 查看位置
- 客户端在每次回滚时记录回滚的帧数、当时的 RTT、输入延迟设置、回滚和重新计算的耗时
- 确认依据
- 反馈对手动作跳变的时刻回滚帧数大，平均回滚幅度约为（单向延迟 − 输入延迟）÷ 帧时长，ping 越高越大
- 排除依据
- 回滚幅度很小却出现一卡一卡，是重新计算超过一帧时长的性能问题。回滚之后两边画面的结果仍然不同，是计算结果不一致（desync）
- 确认手段
- 需要游戏服务器/客户端的日志和指标
出处
- GGPO Rollback Networking SDK GGPO
预测对手输入先行推进，实际输入不同时，从出现偏差的时间点到当前重新计算 - 8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2' GDC
用回滚消除帧同步的本地输入延迟，在 16 ms 内最多回滚 8 帧并重新计算
相关原因
同一层：同步设计
其他层中同样导致“瞬移”的原因
查看含图示和实验的原卡片