中EN
概念页

快照插值

Snapshot Interpolation

发送端按固定频率拍下世界(或相关子集)的快照,接收端不跑权威模拟,而是把渲染时刻拨回一小段,在缓冲里的两份快照之间插值,用额外延迟换平滑,并扛住抖动与偶发丢包。Source 的实体插值与 cl_interp 是同一思想的产品化。

与锁步对照

无法保证确定性、或人数超过锁步舒适区时,改为传状态快照。接收端可以完全不跑物理,只做视觉重建;代价是带宽随对象增长。(Snapshot Interpolation)

抖动与缓冲

即使 60 pps,包到达间隔也不均匀:有的帧两包、有的帧零包。直接渲染「最新一份」会打嗝。做法:把快照在插值缓冲里多留一会儿,渲染时刻取「现在 − 缓冲延迟」,在 straddling 的两份快照间插值。(Snapshot Interpolation)

Source 默认约 20 快照/秒,默认插值期 100 ms(cl_interp 0.1),使得丢掉一份仍常有两份可用:

interpolation period=max⁡(cl_interp, cl_interp_ratio/cl_updaterate)\text{interpolation period} = \max(\texttt{cl\_interp},\ \texttt{cl\_interp\_ratio} / \texttt{cl\_updaterate})

(Source Multiplayer Networking)

插值质量

  • 位置线性插值:样本点处一阶不连续;绕父物体旋转的附着物可能沿弦「穿」过去。
  • Hermite:再带线速度,端点位置与速度都匹配,低发送率下观感好得多。
  • 朝向:对许多刚体,slerp 已够用,不必为角速率上更高阶。(Snapshot Interpolation)

Bernier 强调:更新间隔会随带宽 choke 变化,只跟「上一包→最新包」滑动的简单插值会扁掉弹跳轨迹;应保留位置历史,按目标时间搜索夹住它的两份样本。(Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization)

传送/瞬移要用标志或距离阈值打断插值,否则会「平滑飞过地图」。

丢包与外推

快照时间关键但不要求可靠——绝不走 TCP。丢了就跳过,朝缓冲里更新的样本插。经验:2–5% 丢包时,缓冲约 3× 发送间隔 可扛连续丢两包,再加少量抖动裕量;10 pps 时约 350 ms。外推能减延迟,但对碰撞丰富的刚体很容易穿地、弹错;Source 仅在历史耗尽时线性外推,且限制约 0.25 s(cl_extrapolate_amount)。(Snapshot Interpolation;Source Multiplayer Networking)

延迟与发送率

插值延迟叠在网络延迟之上。降延迟的正经办法是提高快照率(并配合 快照压缩与增量编码):30 Hz 约 150 ms 级缓冲,60 Hz 可到约 85 ms 量级(Gaffer 经验数)。(Snapshot Interpolation)

插值造成的固定「看见别人在过去」必须纳入 延迟补偿,否则命中对不齐准星。

flowchart TD
  R["收到快照:按序号插入缓冲"] --> T["渲染时刻 = 客户端时间 - 插值延迟"]
  T --> F{"缓冲中有夹住 T 的两份快照?"}
  F -- "有" --> I["在两份之间插值位姿/动画"]
  F -- "没有" --> E["短时外推或停在最后样本"]
  I --> D["绘制远程实体"]
  E --> D

上图:远程实体始终画在略过去的时刻;本地玩家预测不走这条路径。

  1. Snapshot Interpolation
  2. gafferongames.com/post/snapshot_interpolation
  3. Source Multiplayer Networking
  4. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
  5. Yahn W. Bernier (Valve, 2001)

相关页面

游戏开发多人网络游戏模型Multiplayer Networking Models多人游戏并不是共享同一份物理现实,而是每位玩家各自看到的近似。历史上主要两条路:对等锁步 (Peer-to-Peer Lockstep)(RTS 仍常用)与权威客户端/服务器 (Authoritative Client/Server)(动作/FPS 主流);后者再叠加客户端预测、插值与延迟补偿,把延迟藏进体验里。游戏开发确定性锁步同步Deterministic Lockstep锁步不同步物体状态,只同步驱动模拟的输入;各方从相同初态用相同固定步长推进。带宽与对象数量无关,但要求比特级确定性,且每人延迟受最慢输入到达时间约束,通常适合约 2–4 人。游戏开发快照压缩与增量编码Snapshot Compression & Delta Encoding提高快照率以降低插值延迟,必须把每快照比特打下来:有界量化、四元数「最小三分量」、静止省略,以及相对对端已确认基线的增量编码。Source 的 delta snapshot 与 ack 跟踪是同一家族的工程实现。游戏开发客户端预测与纠正重放Client-Side Prediction & Reconciliation本地客户端立刻用与服务器相同的运动(及可选武器)代码根据输入推进自己的角色,消除操作往返延迟;服务器仍是权威。权威纠正到达时已是「过去」,客户端丢弃过期缓冲、回绕到纠正状态再重放未确认输入,得到与服务器一致的「现在」。游戏开发延迟补偿Lag Compensation服务器在执行玩家开火等用户命令前,把其他玩家(及必要状态)回拨到「该命令在客户端生成时」所对应的世界时刻——扣除包延迟与客户端视图插值——再做命中判定,然后恢复。这样玩家可以对着自己屏幕上看到的目标直接开火,而不必凭感觉提前量;代价是可能出现「拐角后仍被击中」等时间悖论。游戏开发 · UE5网络复制与 RPCNetwork Replication & RPCUE 采用服务器权威 (Server-Authoritative) 的客户端-服务器模型:游戏真正在服务器上进行,服务器把状态复制 (Replication) 给客户端,客户端通过远程过程调用 (Remote Procedure Call, RPC) 向服务器请求操作。开发者需要显式声明哪些 Actor、属性、函数要走网络,并借助所有权、网络角色、相关性、优先级控制“发给谁、发多少”。UE 5.8 提供通用复制系统、Replication Graph 和实验性的 Iris 三套复制系统。游戏开发 · UE5角色移动组件与 MoverCharacter Movement Component & Mover角色移动组件 (CMC) 用「客户端预测 + 服务器校验 + 纠正后重放」实现联网移动:自主代理先在本地移动并把操作存起来,用 ServerMove RPC 发给服务器重演,位置不符时服务器用 ClientAdjustPosition 纠正,客户端再按保存的操作重放;模拟代理只应用复制下来的移动并做平滑。实验性插件 Mover 计划接替 CMC,改用共享时间线、回滚与重模拟的模型,并且更模块化。

被这些页面引用4 篇

输入关键词开始搜索

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