中EN
概念页

客户端预测与纠正重放

Client-Side Prediction & Reconciliation

本地客户端立刻用与服务器相同的运动(及可选武器)代码根据输入推进自己的角色,消除操作往返延迟;服务器仍是权威。权威纠正到达时已是「过去」,客户端丢弃过期缓冲、回绕到纠正状态再重放未确认输入,得到与服务器一致的「现在」。

问题

纯 C/S 下,按前进要等 RTT 才看到自己动——原版 Quake 的手感。QuakeWorld 引入客户端预测:客户端知道碰撞、摩擦、重力等,先本地猜结果。(What Every Programmer Needs To Know About Game Networking)

为何客户端不能当权威

若客户端直接上报「我的当前位置」,作弊者可瞬移、穿弹。故服务器必须权威;预测只是本地乐观执行。(What Every Programmer Needs To Know About Game Networking;Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization)

算法(Half-Life / 通用)

  1. 采样输入,生成 usercmd,发给服务器,并本地存档(含时间戳)。
  2. 以服务器最后确认的玩家状态为 from,按序对所有未确认命令跑与服务器共享的移动代码(HL 的 pm_shared/),得到预测位姿并渲染。
  3. 服务器快照确认某条命令后,比较预测与权威;误差超阈值则纠正。
  4. 纠正针对的是过去时刻:在环形缓冲里找到对应 Move,重置为服务器状态,重放之后所有输入到当前预测时间;世界其余部分可先固定。(Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization;What Every Programmer Needs To Know About Game Networking;Networked Physics (2004))
sequenceDiagram
  participant C as 本地客户端
  participant S as 权威服务器
  C->>C: 存 cmd t0..t4 并预测到 t4
  C->>S: 发送 cmd
  S->>C: 确认到 t1 的权威状态
  C->>C: 丢弃 ≤t1 的缓冲
  C->>C: 从权威 t1 重放 t2..t4

上图:纠正落在过去,靠重放对齐到本地的「现在」。

实现陷阱

  • 特效与声音:命令会被反复重跑,脚步声等只能在「该命令第一次预测」时播;服务器也不应再复制已在本地预测的效果。(Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization)
  • 纯客户端字段(如蹲下过程中的眼睛高度):需要滑动窗口保存中间状态,ack 后把客户端专有字段拷到新的起点。
  • 平滑:重放后的硬纠正可用指数平滑减弱抽动(Gaffer 对远程与本地纠正都用过类似手法)。(Networked Physics (2004);Source 的 cl_smooth / cl_smoothtime)
  • 预测范围:只能预测本地玩家及「只被其影响」的实体;其他人的输入不可知,远程实体走 快照插值。(Source Multiplayer Networking)

武器预测

把开火逻辑也放进共享代码,弹药、冷却、动画状态作为权威复制字段,则切枪/开火也可本地即时反馈。命中结果仍以服务器为准;没有 延迟补偿 时,高延迟玩家仍需提前量瞄准。(Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization)

与 UE5

角色移动组件与 Mover 的 ServerMove / ClientAdjustPosition / 保存移动重放,以及 GAS 预测,都是本模式的引擎实现。Iris/复制层提供权威状态通道,见 网络复制与 RPC。

  1. What Every Programmer Needs To Know About Game Networking
  2. Networked Physics (2004)
  3. gafferongames.com/post/networked_physics_2004
  4. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
  5. Source Multiplayer Networking
  6. Yahn W. Bernier (Valve, 2001)

相关页面

游戏开发多人网络游戏模型Multiplayer Networking Models多人游戏并不是共享同一份物理现实,而是每位玩家各自看到的近似。历史上主要两条路:对等锁步 (Peer-to-Peer Lockstep)(RTS 仍常用)与权威客户端/服务器 (Authoritative Client/Server)(动作/FPS 主流);后者再叠加客户端预测、插值与延迟补偿,把延迟藏进体验里。游戏开发快照插值Snapshot Interpolation发送端按固定频率拍下世界(或相关子集)的快照,接收端不跑权威模拟,而是把渲染时刻拨回一小段,在缓冲里的两份快照之间插值,用额外延迟换平滑,并扛住抖动与偶发丢包。Source 的实体插值与 clinterp 是同一思想的产品化。游戏开发延迟补偿Lag Compensation服务器在执行玩家开火等用户命令前,把其他玩家(及必要状态)回拨到「该命令在客户端生成时」所对应的世界时刻——扣除包延迟与客户端视图插值——再做命中判定,然后恢复。这样玩家可以对着自己屏幕上看到的目标直接开火,而不必凭感觉提前量;代价是可能出现「拐角后仍被击中」等时间悖论。游戏开发UDP 与游戏协议设计UDP & Game Protocol Design动作游戏的时间关键数据(输入、位姿、物理)只关心最新状态。TCP 的可靠有序流会在丢包时把头阻塞住;正确做法是游戏协议只走 UDP,自己做虚拟连接、按需可靠性与拥塞退避,并按数据类型选择「冗余重发」还是「直接丢弃旧包」。游戏开发 · UE5角色移动组件与 MoverCharacter Movement Component & Mover角色移动组件 (CMC) 用「客户端预测 + 服务器校验 + 纠正后重放」实现联网移动:自主代理先在本地移动并把操作存起来,用 ServerMove RPC 发给服务器重演,位置不符时服务器用 ClientAdjustPosition 纠正,客户端再按保存的操作重放;模拟代理只应用复制下来的移动并做平滑。实验性插件 Mover 计划接替 CMC,改用共享时间线、回滚与重模拟的模型,并且更模块化。游戏开发 · UE5网络复制与 RPCNetwork Replication & RPCUE 采用服务器权威 (Server-Authoritative) 的客户端-服务器模型:游戏真正在服务器上进行,服务器把状态复制 (Replication) 给客户端,客户端通过远程过程调用 (Remote Procedure Call, RPC) 向服务器请求操作。开发者需要显式声明哪些 Actor、属性、函数要走网络,并借助所有权、网络角色、相关性、优先级控制“发给谁、发多少”。UE 5.8 提供通用复制系统、Replication Graph 和实验性的 Iris 三套复制系统。游戏开发 · UE5Gameplay 能力系统Gameplay Ability SystemGameplay 能力系统 (Gameplay Ability System, GAS) 是 UE 用来构建「Actor 可拥有并反复触发的能力」的框架:能力系统组件 (Ability System Component, ASC) 是持有者,Gameplay 能力 (Gameplay Ability) 编排执行过程,属性集 (Attribute Set) 存数值,Gameplay 效果 (Gameplay Effect, GE) 改数值和标签,Gameplay 标签 (Gameplay Tags) 做状态与互斥,Gameplay Cue 负责表现。它内建复制与客户端预测,代价是概念多、上手重,

被这些页面引用1 篇

输入关键词开始搜索

滚轮或双指缩放 · 拖动平移 · 双击放大 / 还原