游戏网络同步：延迟补偿、客户端预测与回滚

上一篇文章 游戏服务端进阶知识储备 讲了状态同步与帧同步的区别与适用场景；本文沿"帧同步"这条线深入竞技对战最硬核的部分：延迟补偿、客户端预测、回滚（Rollback）。这是格斗游戏、FPS、RTS 多人对战的灵魂——目标是让玩家感觉零延迟，而代价是架构复杂度显著上升。读完你不仅懂 GGPO 是什么，还能动手实现一个可回滚的帧同步骨架。

前置：状态同步基础见 游戏服务端进阶知识储备；物理确定性要求见 游戏物理与碰撞；AI 确定性见 游戏 AI：行为树、寻路与群集行为。

1. 网络模型回顾：帧同步的承诺

1.1 状态同步 vs 帧同步速览

帧同步的承诺：给定相同输入序列 + 相同初始状态 + 确定性模拟 → 所有客户端结果完全一致。这样服务端只做"输入转发与仲裁"，逻辑验算分摊给每个客户端。

1.2 朴素锁步（Lockstep）的痛苦

最朴素的实现是回合制锁步：等所有玩家本帧输入到齐，才推进一帧。代价：延迟 = 最慢玩家的延迟。100ms 延迟 × 60fps = 每帧等 6 帧，手感灾难。

朴素锁步时序（等待最慢者）：
客户端A ──输入──▶ 服务器 ──转发──▶ 客户端B
客户端B ──输入──▶ 服务器 ──转发──▶ 客户端A
下一帧 = 两方输入都到齐后才开始 → 延迟=max(RTT)

2. 延迟补偿（Delay Compensation）

2.1 服务端时间回溯

FPS 服务端常用的延迟补偿：当收到玩家射击事件时，服务端把世界"回滚到玩家开枪的瞬间"做命中判定，而不是用"现在"的状态。

玩家A 在 t=1.0s 开枪瞄准 B 的位置
但由于网络，服务端在 t=1.3s 才收到
服务端把世界状态回滚到 t=1.0s → 用那时的位置做射线检测 → 命中判定正确

这解决了"我明明打中了，服务端说没中"的经典抱怨。代价是服务端要能回放历史状态（保留一段时间的快照）。

2.2 客户端时间缓冲

对观战/回放型场景，客户端用缓冲 + 插值平滑远程对象：保留最近 N 个状态快照，渲染层插值到 now - buffer 的时间点，牺牲一点实时性换取平滑。

渲染时间轴：now - buffer（buffer 通常 = 100-200ms）
       │          │
  最近快照  播放位置(插值)

关键取舍：延迟补偿适合"判定中心在服务端"的 FPS；帧同步游戏则把补偿问题交给客户端预测 + 回滚。

3. 客户端预测（Client-Side Prediction）

3.1 先跑再说：不等待服务端

客户端预测的核心：本地立即执行玩家输入，不等服务端确认。

玩家按键 → 本地立即移动角色（预测） → 渲染即时反馈
服务端确认（Ack） → 本地预测与权威一致 → 无事发生
服务端纠正 → 本地与权威不一致 → 平滑修正

// 客户端预测骨架
void OnLocalInput(InputPacket input, float dt) {
    // 1. 立即本地模拟
    LocalSimulate(input, dt);
    // 2. 打包输入发服务端
    SendToServer(input);
    // 3. 保存"待确认"的历史输入
    pendingInputs.Enqueue(input);
}

void OnServerSnapshot(WorldSnapshot snap) {
    // 4. 收到权威快照，比对本地状态
    if (PredictionMismatch(snap.myEntity)) {
        // 回滚到快照时刻，重放 pendingInputs 中未确认的部分
        RollbackAndReplay(snap, pendingInputs);
    }
}

3.2 为什么预测能改善手感

没有预测时：本地输入 → 服务端模拟 → 状态回传 → 渲染，玩家感受到 2×RTT 的延迟。有预测时：本地立即模拟，延迟感知接近零，服务端只负责纠错。

预测失败时的处理：如果权威位置与本地预测偏差小（<阈值），直接平滑吸附；偏差大（如被击退），回滚重放。

4. 回滚机制（Rollback / GGPO）

4.1 回滚的思路

格斗游戏是回滚的教科书。核心思路：不等对方输入，先按"对方上次的输入猜测"推进本帧；当真实输入到达时，发现猜错就回滚到分歧点重算。

帧推进（乐观执行）：
帧 1：本地用 玩家B上次的输入(假设站防) 模拟
帧 2：收到 玩家B真实输入(前冲) —— 猜错了！
    → 回滚到帧1，用真实输入重算帧1、帧2
    → 若结果与已渲染帧有偏差，用重算结果替换并平滑过渡

因为模拟是确定性的，回滚后重算的结果与所有客户端一致，观战端也能精确复现。

4.2 GGPO 回滚的组件

GGPO 的典型实现需要四个组件：

// 回滚调度伪代码
void AdvanceFrame(FrameInput localInput) {
    // 1. 拿对端输入（可能是预测值）
    var remote = GetOrPredictRemoteInput(currentFrame);
    // 2. 保存当前快照用于回滚
    saveStack.Push(CloneWorld());

    // 3. 模拟本帧
    SimulateFrame(localInput, remote);

    // 4. 帧号推进
    currentFrame++;

    // 5. 若对端真实输入到达且与预测不同 → 回滚
    var real = TryGetConfirmedRemoteInput(currentFrame);
    if (real != null && real != remote) {
        RollbackToFrame(currentFrame - 1);   // 载入快照
        while (frame < currentFrame) {       // 重放
            SimulateFrame(GetLocalInput(frame), GetConfirmedRemoteInput(frame));
        }
    }
}

4.3 回滚的代价与权衡

回滚不是"所有游戏适用"：RTS 上千单位快照栈会吃掉大量内存；MOBA 用状态同步 + 服务端权威更省事。回滚的主场是少量角色、强交互、低状态量的对战游戏（格斗、2D 平台竞技）。

4.4 输入预测策略：回滚频率的调节阀

回滚性能取决于预测命中率。常见的输入预测策略：

工程实践：对"高频关键输入"（攻击、闪避）用保守等待或智能预测，对"低频次要输入"（视角、表情）用保持上帧。回滚频率 = 低预测质量 × 高关键输入，会让 CPU 白白重放；合理组合能把回滚率压到 5% 以下。

5. 断线重连与观战

5.1 输入重发与快照补发

断线重连的帧同步方案：

重连流程：
1. 客户端重连，携带最后确认的帧号 lastAckedFrame
2. 服务端/对端把 lastAckedFrame+1 之后的所有输入重发
3. 客户端从重连点开始重新模拟（或先载入最新快照再重放）
4. 关键：本地要丢弃重连前的预测状态，从权威点重放

实现上，服务端应维护输入历史环形缓冲（如最近 300 帧），供重连客户端快速补齐。

5.2 观战（Spectator）的确定性红利

帧同步的最大红利之一：观战端只需接收输入序列，本地跑同一份确定性模拟，就能与对局完全一致。服务端只需广播输入流 + 周期快照用于快速追帧（catch-up）。

观战端 = 无输入客户端：
  接收输入流 → 确定性模拟 → 渲染
  落后太多 → 载入服务端周期快照 → 继续重放

5.3 传输层：UDP + 可靠投递

帧同步输入追求低延迟，通常跑 UDP，可靠性在上层实现。关键组件：

// 按帧号排序的输入缓冲（抗乱序 + 抗丢包）
SortedDictionary<int, InputPacket> inbox;  // key = 帧号
InputPacket? GetConfirmedInput(int frame) {
    return inbox.TryGetValue(frame, out var p) ? p : null;
}
// 模拟层只认帧号，不关心底层是 TCP/UDP 或谁先到

关键设计：模拟层只消费"按帧号确认的输入"，网络层的乱序、丢包、延迟都在此边界内消化。这保证了 网络层的任何实现细节都不会污染确定性模拟。

6. 确定性：回滚的地基

6.1 确定性破坏源清单

帧同步/回滚最大的敌人是非确定性。任何客户端模拟结果不同，回滚与观战就全部失效：

6.2 定点数实现要点

// 定点数（16.16 格式）的加法与乘法
public struct Fix16 {
    public long raw;   // 高16位整数，低16位小数

    public static Fix16 operator +(Fix16 a, Fix16 b) => new Fix16 { raw = a.raw + b.raw };
    public static Fix16 operator *(Fix16 a, Fix16 b) => new Fix16 { raw = (a.raw * b.raw) >> 16 };
    // sqrt/sin/cos 用查表或 CORDIC 算法保证各平台一致
}

工程提示：先别急着全量定点化。用固定步长 + 固定帧号 + 统一随机种子清理 80% 的非确定性，再用定点数处理几何计算。全量定点化开发成本很高，只对"判定敏感"的部分做。

6.3 输入帧的组织

确定性模拟必须能精确回答"第 N 帧的输入是什么"。输入打包成逐帧输入块：

struct InputPacket {
    int frame;          // 逻辑帧号
    uint buttons;       // 按位存储按键：0x01=左, 0x02=右, 0x04=拳...
    sbyte stickX, stickY;  // 摇杆量化
}
// 序列化 → 网络传输 → 对端反序列化，保证字节级一致

7. 最佳实践与总结

帧同步+回滚架构落地检查单：

1. 先做确定性：没有确定性，回滚/观战全部免谈。固定步长 + 帧号 + 同步随机种子是第一优先级。
2. 模拟与渲染解耦：逻辑帧推进独立于渲染帧，渲染从"显示帧历史"插值，回滚才不闪屏。
3. 输入优先于状态：帧同步传输的是输入，状态只用于纠正与重连。
4. 快照栈预算化：限制回滚深度（如最多 8 帧），超过预算走"等待输入"（降级为锁步）。
5. 网络层与模拟层分层：网络只负责输入可靠传输与乱序重排（用帧号排序），模拟层不知道网络存在。

框架选型：

• 格斗/2D 竞技：GGPO（开源，已被多数格斗游戏采用）或自研精简回滚。
• RTS：需要确定性 + 大状态量，常自研（或基于确定性引擎）。
• 派对/休闲竞技：可接受轻微延迟，用状态同步 + 服务端权威更省成本。

回滚是对"延迟"最激进的宣战：它用乐观执行 + 悔棋换取了"感觉零延迟"。但它是建立在对模拟完全掌控之上的奢侈品——先保证确定性，再谈回滚。这篇文章帮你建立的地基，恰好是这类游戏从 0 到 1 最难的部分。

相关阅读：游戏服务端进阶知识储备 讲解帧同步与状态同步的全貌对比；游戏物理与碰撞 讲解物理确定性的具体实现；游戏引擎架构：ECS 与资源管理 讲解固定步长帧循环这一回滚的地基。