游戏卡顿白皮书 › 同步设计
被 ping 吃掉的短判定窗口 Timing window too short for latency + reaction
原因 ID sy-short-window · 主责 研发团队·服务器开发 · 配合 研发团队·客户端开发, 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
闪避、弹反、格挡这类需要反应的时间很短时，ping 会把这段时间吃掉，出现躲不开的攻击。
起因 BOSS 攻击预警 0.5 秒、弹反判定 0.2 秒这样的短判定窗口 → 结果 预警看到得晚（下行延迟 + 插值），自己的输入也到得晚（上行延迟 + tick 等待） → 画面表现 明明躲开了却被打中，弹反被吞
- 症状
- 吞操作/回档, 操作延迟
- 因素
- 延迟
- 谁会遇到
- 只有我, 仅特定功能
- 何时出现
- 做特定操作时
- 负责方
- 主责 研发团队·服务器开发 · 配合 研发团队·客户端开发, 运维团队·系统运维
- 研发团队要做的事
- 服务器：按服务器时间预约攻击预警并提前下发，把判定窗口延长相当于 ping 的时长（延迟补偿）。客户端：收到的预警按预约的服务器时间播放。
- 运维团队要做的事
- 在玩家多的地区附近部署服务器（地区服务器），从根本上降低 ping。
- 数值参考
- ping 150 ms、插值 100 ms 时，预警显示到自己画面上约需 0.18 秒，自己的输入到达服务器约需 0.1 秒。再加上人的反应时间 0.25 秒，0.5 秒的预警几乎不可能躲开。
- 监控图上
- 仅部分偏高 · 闪避、弹反失败率（按 ping 区间）
- 查看位置
- 在服务器日志中记录判定窗口的开始、结束时刻，玩家输入到达服务器的时刻，以及该玩家的 RTT，把失败率按 ping 区间（例如每 50 ms 一档）分开看
- 确认依据
- ping 越高的区间失败率明显越高，失败的输入在判定窗口结束后不久（RTT 加插值时间以内）才到达
- 排除依据
- 失败率与 ping 区间无关、大致相同，是机制难度问题。输入在判定窗口内到达却仍判失败，看判定代码或服务器校验
- 确认手段
- 需要游戏服务器/客户端的日志和指标
出处
- Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
简单反应时间平均约 231 ms（校正设备延迟后为 213 ms），近年的大规模研究为 233~400 ms - Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
越精确、截止时间越短的动作对延迟越敏感（第一人称约 100 ms、第三人称约 500 ms、全知视角约 1,000 ms 为极限） - NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
按服务器时间（ServerTime）预约事件，让所有客户端在同一时刻播放的方法
相关原因
同一层：同步设计
其他层中同样导致“吞操作/回档”的原因
查看含图示和实验的原卡片