遊戲 Lag 白皮書 › 同步設計
過於嚴格的伺服器驗證 Over-strict server validation
原因 ID sy-strict-check · 主要負責 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
伺服器對移動速度、冷卻時間、射程檢查得太嚴格時，連因抖動而擠在一起抵達的正常輸入也會被拒絕。
為什麼 「一個 tick 內可移動的距離」、「冷卻時間容許誤差 0ms」這類嚴格標準 → 於是 因抖動使兩個指令擠在同一個 tick 抵達時，就被判定為違規 → 畫面上 拉回，冷卻好了技能卻被拒絕
- 症狀
- 拉回, 吃指令／回檔
- 因素
- 抖動
- 誰會遇到
- 只有我
- 何時
- 偶爾隨機發生, 移動中／切換地圖時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 以累積容許量（token bucket）方式檢查，保留 ping 與抖動的餘裕。
- 圖表上
- 偶爾隨機飆高 · 伺服器驗證拒絕、位置校正次數
- 查看位置
- 在伺服器 log 中，每次驗證拒絕或位置校正都記錄原因、該 tick 抵達的該玩家指令數、與前一個指令的抵達間隔
- 符合的跡象
- 拒絕與校正集中在一個 tick 內擠進 2 個以上指令的時刻，而以數秒為單位加總的移動量、使用次數都在規則範圍內
- 不符合的跡象
- 以數秒為單位加總仍超出規則時，可能真的是加速或作弊。拒絕集中在特定電信業者與晚間時段時，是集中在特定電信業者玩家的驗證誤判
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
出處
- Source SDK 2013: player.cpp Valve
以每個 tick 累積的指令處理預算（最多 sv_maxusrcmdprocessticks 24 tick）容許擠在一起抵達的指令。開發註解提到擋得更嚴格時，連正常玩家也會出現卡頓 - RFC 2697: A Single Rate Three Color Marker IETF
token bucket：以平均速率（CIR）與一次容許的突發量（CBS）判定
相關原因
同一層：同步設計
同一症狀（拉回）在其他層的原因
查看含圖解與實驗的完整版卡片