한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

伺服器回應後才演出（請求-回應方式） Request-response (no client-side feedback)

原因 ID sy-request-response · 主要負責 遊戲開發團隊（用戶端開發） · 協同遊戲開發團隊（伺服器開發）

在含圖解與實驗的完整版中開啟卡片 →

按下按鈕後，在伺服器回應之前既沒有動畫也沒有音效。ping 直接就是反應速度。

為什麼 技能、移動、撿取都等伺服器確認後才播放 → 於是從按下的瞬間起，在往返時間 + tick 等待這段期間毫無反應 → 畫面上 ping 150ms 時，每個動作都慢 0.2 秒

症狀: 輸入延遲
因素: 延遲
誰會遇到: 只有我
何時: 一直都有, 做特定動作時
負責單位: 主要負責 遊戲開發團隊（用戶端開發） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 用戶端：動畫、音效、特效在按下時立即開始（先行演出），只有結果（傷害、獎勵）等伺服器確定後才顯示；移動與普通攻擊先預測並立即反映；收到伺服器的位置校正時，從該位置重新套用尚未獲得確認的輸入。伺服器：用收到的輸入自行計算移動，只在與用戶端預測位置的差距超過門檻時才送出校正值。
數值參考: 反應時間 ≈ ping + tick 間隔的一半 + 一個畫格。20 tick、ping 150ms 時約 190ms。
圖表上: 一開始就一直偏高 · 從輸入到開始演出的時間、RTT（ping）
查看位置: 在開發版本的用戶端 log 記錄按鈕輸入時間、第一個動畫／音效開始時間、伺服器回應抵達時間，並與遊戲內 RTT 對照。用引擎的網路模擬（Unreal NetEmulation.PktLag）或測試伺服器上 Linux 的 tc netem 加入延遲，改變 ping 反覆測量
符合的跡象: 演出開始的時間點總是與伺服器回應抵達同一瞬間，從輸入到演出的時間約為 RTT + tick 等待，且隨加入的延遲等量增加
不符合的跡象: 按下立即開始演出、只有傷害數字等結果較晚出現的話，是正常設計。ping 低的地方也慢了 tick 間隔以上時，是雙重 tick 等待或用戶端畫格的問題
確認方式: 需要遊戲伺服器／用戶端的 log 與指標
深入了解: 回合制、卡牌、放置型這類不需要快速反應的遊戲，用這種方式最簡單也最安全。問題出在有即時操作的遊戲連移動或普通攻擊也這樣做的時候。

出處

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
只等伺服器結果的用戶端，延遲 500ms 時所有動作都要 500ms 後才看得到。以用戶端預測與伺服器校正解決
Using Gameplay Abilities in Unreal Engine Epic Games
Local Predicted 在按下時立即執行，由伺服器做最終決定；Server Initiated 沒有預測，施放者會看到延遲
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
用戶端先預測並儲存移動，只在伺服器誤差超過容許值（MAXPOSITIONERRORSQUARED）時才校正，校正後重新套用儲存的移動
Using Network Emulation in Unreal Engine Epic Games
在伺服器、用戶端加入最小／最大延遲與封包遺失比例來測試，在主控台以 NetEmulation.PktLag 這類指令設定
tc-netem(8) — Linux manual page iproute2
對送出的封包加入延遲、抖動（delay TIME JITTER）與遺失（loss random PERCENT），模擬真實網路的測試工具

伺服器回應後才演出（請求-回應方式） Request-response (no client-side feedback)

出處

相關原因

同一層：同步設計

同一症狀（輸入延遲）在其他層的原因