遊戲 Lag 白皮書 › 同步設計
被 ping 吃掉的短判定區間 Timing window too short for latency + reaction
原因 ID sy-short-window · 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）, 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
閃避、格擋、防禦這類需要反應的時間很短時，ping 會把這段時間吃掉，出現躲不掉的攻擊。
為什麼 像王的攻擊預兆 0.5 秒、格擋判定 0.2 秒這樣短的判定區間 → 於是 預兆較晚看到（下行延遲 + 內插），自己的輸入也較晚抵達（上行延遲 + tick 等待） → 畫面上 明明躲開了卻被打中，格擋被吃掉
- 症狀
- 吃指令／回檔, 輸入延遲
- 因素
- 延遲
- 誰會遇到
- 只有我, 只有特定功能
- 何時
- 做特定動作時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）, 基礎設施團隊（伺服器基礎設施）
- 遊戲開發團隊要做的事
- 伺服器：以伺服器時間排程攻擊預兆並提前送出，把判定區間延長 ping 的長度（延遲補償）。用戶端：把收到的預兆配合排定的伺服器時間播放。
- 基礎設施團隊要做的事
- 在玩家多的地區附近部署伺服器（地區伺服器），從根本降低 ping。
- 數值參考
- ping 150ms、內插 100ms 時，預兆出現在自己畫面上約需 0.18 秒，自己的輸入抵達伺服器約需 0.1 秒。再加上人的反應時間 0.25 秒，0.5 秒的預兆幾乎不可能躲開。
- 圖表上
- 只有部分偏高 · 閃避、格擋失敗率（依 ping 區間）
- 查看位置
- 在伺服器 log 記錄判定區間的開始與結束時間、玩家輸入抵達伺服器的時間、該玩家的 RTT，並把失敗率依 ping 區間（例：每 50ms 一級）分開來看
- 符合的跡象
- ping 越高的區間失敗率明顯越高，失敗的輸入在判定區間結束後不久（RTT 加內插時間以內）才抵達
- 不符合的跡象
- 失敗率與 ping 區間無關、差不多時，是招式難度問題。輸入在判定區間內抵達卻仍判定失敗時，要查判定程式碼或伺服器驗證
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
出處
- Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
簡單反應時間平均約 231ms（校正設備延遲後為 213ms），近年的大規模研究為 233～400ms - Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
越精準、期限越短的動作對延遲越敏感（第一人稱約 100ms、第三人稱約 500ms、上帝視角約 1,000ms 為極限） - NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
依伺服器時間（ServerTime）排程事件，讓所有用戶端在同一瞬間播放的方法
相關原因
同一層：同步設計
同一症狀（吃指令／回檔）在其他層的原因
查看含圖解與實驗的完整版卡片