한국어 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 150 ms 时，所有动作都慢 0.2 秒

症状: 操作延迟
因素: 延迟
谁会遇到: 只有我
何时出现: 一直, 做特定操作时
负责方: 主责 研发团队·客户端开发 · 配合研发团队·服务器开发
研发团队要做的事: 客户端：动画、声音、特效在按下时立即开始（预表现），只有结果（伤害、奖励）在服务器确认后显示；移动、普通攻击先预测并立即呈现；收到服务器的位置校正后，从该位置起重新应用尚未被确认的输入。服务器：用收到的输入自行计算移动，只有与客户端预测位置的差距超过阈值时才发送校正值。
数值参考: 反应时间 ≈ ping + tick 间隔的一半 + 一帧。20 tick、ping 150 ms 时约 190 ms。
监控图上: 一直偏高 · 从输入到表现开始的耗时，RTT（ping）
查看位置: 在开发版本的客户端日志中记录按键时刻、第一个动画或声音开始的时刻、服务器响应到达的时刻，与游戏内 RTT 并排对照。用引擎的网络模拟（Unreal NetEmulation.PktLag）或测试服务器上 Linux 的 tc netem 加入延迟，改变 ping 反复测量
确认依据: 表现开始总是与服务器响应到达在同一时刻，从输入到表现的耗时等于 RTT + tick 等待，并且随加入的延迟同步增加
排除依据: 表现在按下时立即开始，只有伤害数字这类结果较晚，是正常设计。ping 很低时也慢出一个 tick 间隔以上，则是双重 tick 等待或客户端帧的问题
确认手段: 需要游戏服务器/客户端的日志和指标
深入了解: 回合制、卡牌、放置类这类不需要快速反应的游戏，这种方式最简单也最安全。问题出在有实时操作的游戏里，连移动、普通攻击都这样做的时候。

出处

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
只等服务器结果的客户端，延迟 500 ms 时所有动作都要 500 ms 后才能看到。用客户端预测和服务器校正解决
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)

出处

相关原因

同一层：同步设计

其他层中同样导致“操作延迟”的原因