遊戲 Lag 白皮書 › 同步設計
先行演出後遭伺服器拒絕 Client-side feedback rejected by server
原因 ID sy-optimistic-reject · 主要負責 遊戲開發團隊（用戶端開發） · 協同 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
自己畫面上先呈現的打擊、技能，事後沒有被伺服器認可時，明明看到的結果就變成沒發生過。
為什麼 在伺服器確認前先播放打擊特效與技能動作（先行演出） → 於是 伺服器重新檢查射程、目標位置、冷卻與資源後拒絕 → 畫面上 噴血了卻沒有傷害，技能只有動作沒有效果，只有冷卻在跑
- 症狀
- 吃指令／回檔, 拉回
- 因素
- 延遲
- 誰會遇到
- 只有我, 只有特定功能
- 何時
- 做特定動作時
- 負責單位
- 主要負責 遊戲開發團隊（用戶端開發） · 協同 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 用戶端：只有傷害數字、死亡、獎勵這類需要確定的部分才依伺服器結果顯示，常見的拒絕原因先在本地檢查，被拒絕時還原冷卻與資源並顯示原因。伺服器：射程與目標位置檢查保留 ping 的餘裕，在拒絕回應中附上原因，收集各技能的拒絕比例作為指標。
- 數值參考
- 拒絕回應會在按下後晚 ping + tick 等待的時間才到。ping 150ms 時，約有 0.2 秒會以為「打中了」。
- 圖表上
- 只有部分偏高 · 各技能的伺服器拒絕比例（依 ping 區間）
- 查看位置
- 在伺服器端收集各技能的拒絕比例與拒絕原因（射程、目標位置、冷卻、資源），並依玩家 RTT 區間分開。在用戶端記錄先行演出的動作被拒絕的次數
- 符合的跡象
- 拒絕集中在特定技能以及射程、目標位置類原因，ping 越高拒絕比例越高
- 不符合的跡象
- 拒絕原因是冷卻、資源且與 ping 無關時，要查用戶端與伺服器的資料值（冷卻、消耗）是否不同。沒有拒絕、演出卻在伺服器回應後才開始時，是伺服器回應後才演出（請求-回應方式）
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
- 深入了解
- 先行演出是遮蓋 ping 最好的方法。只是用戶端與伺服器用來判斷的資訊（對手位置、剩餘資源）差異越大，拒絕就越頻繁。把各技能的拒絕比例收集成指標，就容易找出判定不一致的地方。
出處
- Using Gameplay Abilities in Unreal Engine Epic Games
Local Predicted 能力在用戶端立即執行，但由伺服器做最終決定，並可能推翻結果 - Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
在用戶端預測武器射擊並先播放效果，再以伺服器結果修正預測誤差
相關原因
同一層：同步設計
同一症狀（吃指令／回檔）在其他層的原因
查看含圖解與實驗的完整版卡片