00背景：为什么需要这个系统

问题：网络延迟吞噬操作体验

PVP 多人竞技游戏采用服务器权威架构——所有操作必须经过服务器确认才能生效。玩家按下方向键到角色响应，中间隔着一个 RTT（网络往返延迟），通常 60~200ms。这 0.1 秒意味着：

• 移动：追逃场景中，逃跑方推摇杆的瞬间角色不动，0.1 秒后才启动——感觉"粘手"、"不跟手"。
• 技能：守方看到攻击立刻按格挡，但指令到达服务器时攻击判定早已结束——"明明按了，没挡住"。

优化目标

让玩家完全感受不到网络延迟——推摇杆角色立刻动，按技能技能立刻出，体验趋近于单机。同时不牺牲服务器权威性（防作弊）。

解决思路

不等服务器确认，客户端拿到操作后立即在本地执行，同时把操作发给服务器。服务器独立计算结果后回传。两边结果一致——完美；不一致——客户端悄悄回退到服务器确认的状态，用保存的操作重走一遍，玩家无感知。

优化前：推摇杆 → 等 60~200ms → 角色才动；按技能 → 等 60~200ms → 技能才释放。追逃靠网速不靠操作，格挡靠运气不靠反应。

优化后：推摇杆 → 角色立刻动；按技能 → 技能立刻释放。攻守对抗回归操作本身，体验趋近于单机。

上述"本地立刻执行 → 服务器后台确认 → 偏差自动修正"的完整技术实现，就是本文档所阐述的客户端预测与回滚系统。后续章节将逐一展开其架构设计、核心难点和各子系统实现。

01技术方案概述

核心思想

相同输入 → 相同模拟算法 → 相同输出。

• 双端跑相同的模拟：客户端和服务器各自拿到输入，各自独立执行完全相同的模拟算法（物理、技能、Buff），各自产出结果。客户端在操作瞬间立即模拟并表现，不等服务器。
• 算法自身保证稳定：即使双端输入有时差导致结果不一致，客户端回滚到服务器确认的状态，用保存的输入重走一遍相同的模拟——算法是确定性的，重模拟的输出必然收敛。
• 所有玩法共享同一框架：基础移动、技能位移、Buff 速度补偿——本质上都是这个输入 → 模拟 → 输出框架在不同玩法维度上的延伸和实践。

02系统架构总览

架构设计决策：采用 Client-Side Prediction + Server Reconciliation 模式，而非帧同步 (Lockstep) 或纯状态同步。原因：非对称竞技以追逃和伪装为核心玩法，追逐方与逃跑方的技能、Buff、视野机制差异大，帧同步一致性成本高；而追逃场景下移动手感至关重要，纯状态同步的延迟感会严重影响追逃体验。预测回滚方案在保持服务器权威的同时，将玩家感知延迟降至接近零。

03核心指标

04预测与回滚流水线

4.1 完整帧处理时序

4.2 回滚与重新模拟流程

05核心技术难点

本节较长，分为两个难点：A. 双端模拟一致性 和 B. 回滚与重模拟。

场景还原：追逃对局中，逃跑方玩家被追击时按下前进键急需脱离。在传统状态同步中，客户端需要等待服务器确认才移动，延迟 = 1 个 RTT（约 60~200ms），角色动作发"粘"——追逃场景下这种迟滞直接影响生死。

预测回滚系统让客户端先行模拟——按下的瞬间角色就动了。但"提前算"带来两个必须解决的工程难题：

• 难点 A：双端模拟一致 — 相同输入 → 相同模拟 → 相同输出。双端对同一帧、同一输入，执行相同的模拟算法，必须算出几乎相同的结果。否则每次对比都要修正，角色反复回弹。
• 难点 B：算法自纠错 — 帧状态必须可回滚、可推演。模拟不可能 100% 正确（输入时差、Buff 延迟等），算法自身能回到出错帧，用正确输入重新模拟到当前帧，输出自动收敛稳定，玩家无感知。

两者共同保证算法输出稳定：A 让双端模拟结果一致率极高（减少修正频率），B 让不一致时算法自动收敛（保证修正质量）。

难点 A — 双端帧计算结果必须一致

类比：想象两个人在两个房间里，各自拿到一道一模一样的物理题（同一帧输入），必须独立算出完全一样的答案（角色位置）。听起来简单？但两个人用的计算器精度不一样（浮点硬件不同）、用的公式版本不一样（引擎 API 不同）、甚至桌子上摆的参考物都不同（碰撞场景参数差异）。这就是双端一致性面临的真实挑战。

为什么难：三个维度的差异

客户端和服务器是两个完全独立的运行环境，从硬件到引擎到运行时，每一层都可能产生结果差异：

如果做不好会怎样？——"橡皮筋效应"

当双端计算不一致时，玩家看到的不是"角色平稳移动"，而是角色走两步就被拉回来，像被一根橡皮筋拽住——这就是网络游戏开发中常说的橡皮筋效应（rubber-banding）：客户端预测位置不断被服务器修正拉回，角色一会前进一会后退，操控感极差，对比纯状态同步延迟感反而更差——"预测做了不如不做"。

这就是为什么双端一致性是预测系统的生死线：一致性不够，回滚修正就频繁，手感反而比不预测更差。而要实现一致性，光调 Python 脚本层的参数远远不够——最终决定角色位置的是 C++ 引擎层的 CCT 碰撞检测。

解法核心：引擎层 C++ 改造

为什么脚本层调参数解决不了？ 角色每帧的位置 = 当前位置 + 速度 × dt，然后经过 CCT 碰撞检测（碰到墙壁推开、沿斜坡滑动、过不了台阶等）后得到最终位置。速度公式在 Python 脚本层可以轻易对齐，但碰撞检测发生在 C++ 引擎内部的 PhysX 物理引擎中，Python 无法介入。

更关键的是：客户端引擎（MEngine）原本没有"在任意时刻、任意位置发起一次独立的 CCT 移动并取回结果"的能力——它的 CCT 移动与渲染帧绑定。要支持预测系统在一帧内反复调用模拟（回滚推演需要），必须修改引擎 C++ 代码。

引擎改造清单

以下每一项都需要修改 C++ 引擎代码或引擎配置，不是 Python 脚本层能完成的：

不可消除的误差：跨平台浮点数

类比：同一道除法 10 ÷ 3，一个计算器显示 3.3333333，另一个显示 3.33333334——精度不同，最后一位就是不一样。CPU 的浮点运算也是如此：ARM 芯片（手机）和 x64 芯片（服务器）的浮点单元精度不同，算出来的结果在最低几位上必然有差异。

IEEE 754 浮点误差 —— 三个不可控因素

实测表明，同一输入 pos=(3.0, 0, 5.0) vel=(0.1, -0.03, 0.2) 在 ARM 和 x64 上输出差值约 ~2.38e-7/帧——肉眼不可见，但 30 帧/秒会累积。设计哲学：尽力对齐以减少误差 + 容错层处理不可避免的微小偏差。

完整的五层对齐体系

解决双端一致性不是单一手段，而是从引擎底层到脚本逻辑的五层对齐，每层解决一个维度的差异：

第 1、4 层需要引擎 C++ 改造，第 2、3、5 层在 Python 脚本层实现。五层协同把偏差控制在不可感知范围内。

偏差来源、对策与残余影响

难点 A 小结：双端模拟一致性跨越 C++ 引擎层和 Python 脚本层，需要新增引擎 API、锁定物理帧率、硬编码碰撞参数、预同步外部状态（速度因子、禁移集合等模拟输入），最终通过五层对齐把双端模拟偏差控制在肉眼不可感知的范围。而跨平台浮点误差是物理定律（IEEE 754）决定的天花板，只能容忍不能消除——这直接引出了难点 B 的必要性：算法必须能自纠错。

难点 B — 算法自纠错：帧状态可回滚、可推演

具体场景：逃跑方推摇杆右跑，客户端立即预测并持续向右跑了约 0.3 秒。此时收到服务器回包，告知 0.3 秒前那一刻的权威位置比客户端预测的偏左了 0.3m（因为服务器判定那一刻角色踩到了一个减速 Buff 区域，而客户端尚未收到这个 Buff 信息）。此时客户端已经基于错误的起点向前算了 0.3 秒，后续每帧都累积了偏差。系统需要做的是：把位置回退到服务器确认的那一刻（回滚），然后用保存的这 0.3 秒内的输入重新模拟一遍（推演），得到修正后的当前位置——整个过程在一帧（33ms）内完成，玩家看到的角色轨迹只有极微小的平滑修正，完全无感知。

为什么回滚不可避免

因为难点 A 无法做到 100% 一致——跨平台浮点误差是物理定律决定的，Buff 时序差是网络延迟决定的。只要有差异存在，服务器回包就可能告诉客户端"你算错了"。此时：

如果没有回滚：客户端只能瞬间跳到服务器的正确位置。玩家看到角色突然闪现/瞬移，体验极差——相当于每隔几帧角色就"闪"一下。有了回滚推演：客户端回到出错的那一帧，用正确值重新模拟到现在。如果后续帧的输入没变，重新算出来的位置和原来差别极小，角色只需微调，玩家完全无感知。

回滚推演的三大技术挑战

回滚推演听起来简单——"保存一下、改一下、重算一遍"——但在实际工程中有三个硬约束：

1. 存什么：不只是坐标——每帧还有输入、速度因子、技能状态、禁移集合等，都要完整快照。
2. 怎么算：推演 10 帧 = 10 次完整物理模拟 + 技能状态更新，且必须在 1 帧（33ms）内完成。
3. 视觉不能闪：推演中不能重播动画、创建特效，否则玩家会看到技能"闪烁"或"重放"。

挑战 1 解法：每帧快照 —— 像游戏存档一样

客户端每帧往帧缓冲区里存一个完整快照。Buffer 就像一个环形录像带，最多保存 33 帧（约 1 秒），收到服务器确认后才丢弃旧帧：

每个快照保存的不只是一个坐标，而是一个完整的帧状态：帧号、当时的位置、当时的输入、物理模拟结果、技能系统快照。这些信息让推演时能精确"重放"每一帧的计算过程。

挑战 2 解法：回滚 + 推演 —— 一帧内重算 10 帧

当客户端在第 110 帧收到服务器对第 100 帧的确认，发现位置有偏差时，整个修正过程分 4 步：

1. 查找 — 在 Buffer 中定位服务器确认的 Frame 100，对比预测值 (3.01, 0, 5.02) vs 服务器值 (3.00, 0, 5.00)，偏差 0.02 > 阈值 0.00001，需要修正
2. 回滚 — 将角色位置重置为服务器权威位置 (3.00, 0, 5.00)，通知技能系统将状态也回退到确认帧
3. 推演（前滚） — 从服务器位置出发，逐帧重新模拟 101→110。每帧：取出保存的输入 → 查该帧速度因子 → 计算速度向量 → 调用 CCT 物理模拟 → 更新技能状态 tick(dt, roll_front_state=1)。最末帧 110 用 roll_front_state=2，标记为推演最终帧以修正视觉表现
4. 完成 — 恢复帧号到真实值 110，丢弃已确认的旧帧，重新模拟的位置经 Filter 平滑过渡到渲染模型

关键区分：推演不是"近似估计"或"插值"——每一帧都是完整的物理模拟（调用 CCT 做真实碰撞检测），和正常预测帧走的是完全相同的计算路径。10 帧推演 = 10 次 CCT 物理模拟，全部在 1 帧内完成，耗时 <1ms。区别只在于 roll_front_state 参数告诉技能系统"这帧是推演，跳过视觉表现"。

挑战 3 解法：推演状态三态设计 —— 分离逻辑与视觉

移动回滚只涉及一个坐标，相对简单。但技能系统有生命周期、视觉特效、状态机，回滚时绝不能"重新放一遍技能特效"——否则玩家会看到技能闪烁或重放。

解决办法是通过一个推演状态参数，让技能系统知道"当前是正常运行还是回滚推演"，从而精确控制行为：

效果：回滚推演 10 帧只用 <1ms（纯数学计算 + 物理模拟，不涉及 GPU）。玩家看到的动画始终平滑连续，没有闪烁或重放。如果没有这个设计，每次回滚都重新创建 10 帧的特效 + 播放 10 次动画，一帧内 GPU 提交量暴增，掉帧卡顿 + 视觉闪烁。

技能预测的双端对比：快照比对

客户端每帧为技能拍"快照"，服务器也拍。回包时两者比对——如果客户端预测的技能开始帧和服务器一致，说明预测正确；否则需要修正：

客户端快照记录"我认为这个技能从第 100 帧开始执行，当前已运行到第 110 帧"；服务器快照记录"服务器确认该技能从第 100 帧开始，服务器当前处理到第 105 帧"。

比对逻辑：若服务器确认的技能开始帧 == 客户端记录的技能开始帧 → 预测正确，技能继续运行；否则 → 预测失败，用服务器的值修正技能状态（可能需要回滚或取消技能）。

实战示例：眩晕预测的回滚

以眩晕被动技能为例：F100 客户端预测眩晕命中（添加禁移 + 播放眩晕特效）→ F105 服务器判定目标有霸体，眩晕无效 → F110 客户端收到 NACK，回滚移除禁移 + 清除特效 → F111 恢复正常移动。预测错误的体验代价是玩家看到眩晕特效闪了一下就消失——仍然比"没有预测但延迟高"的体验更好。

推演细节：历史速度因子的精确回放

推演每帧时，必须使用该帧当时对应的速度因子，而非当前帧的值。服务器会预推送未来 17 帧的速度因子序列，推演时按帧号精确匹配：

推演循环中的速度因子查找过程：

1. 在服务器预推送的速度因子序列中，按帧号精确匹配查找当前推演帧对应的服务器速度因子
2. 将服务器因子与客户端预测因子逐项相乘，得到最终合成速度因子
3. 用合成后的速度因子参与该帧的速度计算和物理模拟

反例：如果错误地使用了"当前帧"的因子来推演历史帧 → 加速 Buff 结束后推演旧帧时，速度因子从 1.5 变成 1.0 → 推演出来的位置比原始预测短了 30% → 角色突然"缩回去"。

难点 B 小结：算法自纠错机制要做到"快、准、静"——快：10 帧完整模拟在 1ms 内完成；准：用正确输入重走完全相同的模拟算法，确定性保证输出收敛；静：推演状态三态设计分离逻辑与视觉，修正对玩家完全透明。这就是"输入 → 确定性模拟 → 输出"框架的自稳定性——即使输入有时差，算法重新拿到正确输入后必然收敛到正确输出。

两大难点的协同

难点 A（双端模拟一致）决定了双端输出的一致率。一致性越高 → 回滚修正越少 → 手感越平滑。五层对齐体系把双端模拟偏差压到肉眼不可感知。

难点 B（算法自纠错）决定了不一致时的收敛速度。回滚重模拟越快越精确 → 输出收敛越快 → 即使双端短暂不一致也不影响体验。

缺一不可：只有 A 没有 B → 偶尔不一致就导致角色瞬移，算法脆弱；只有 B 没有 A → 每帧都在回滚重模拟，CPU 负载高，且频繁修正让角色微抖。A 把"需要修正"的概率降到极低，B 把"修正的代价"降到极低——两者共同保证了算法在任何情况下输出都是稳定的。

06移动预测系统

框架层面的两大难点讲完了，下面逐个展开各子系统的实现，从最基础的移动预测开始。

6.0 角色位置的多源驱动

在预测系统中，角色位置不是单一运动公式决定的。除了基础摇杆移动外，还有多种机制会改变角色位置，每种机制在预测系统中的处理方式不同：

所有位置源最终汇聚为速度向量，经 CCT 碰撞检测后输出最终位置，再经 Filter 平滑到渲染模型。

为什么不能只考虑基础移动？ 在追逃玩法中，角色大部分时间都在奔跑（基础移动），但关键时刻的位置变化往往来自非基础移动：被钩子拉回、被击退撞墙、冲刺加速追击、加速 Buff 拉开距离——这些场景恰恰是延迟感最强、最需要预测的时刻。预测系统必须覆盖所有位置源的模拟逻辑，才能保证输出稳定。

这些位置源虽然输入不同，但都遵循同一个核心框架——输入 → 确定性模拟 → 输出。它们的区别仅在于"输入从哪来"和"模拟算法用哪条路径"：

• 输入 = 摇杆 + 速度因子：基础摇杆移动双端各自拿到摇杆输入，独立计算速度 + CCT 碰撞。Buff 速度因子由服务器预推送，客户端乘入速度公式后走相同 CCT 路径。禁移集合非空时输入被屏蔽，模拟直接返回原位置。
• 输入 = 技能参数：冲刺/突进由 MoveStrategy 替换速度计算，输入变为技能配置的方向、最大速度、加速度、距离上限，模拟输出仍走 CCT 碰撞。钩子拉拽输入变为目标点坐标 + 牵引加速度。
• 输入 = 动画曲线：击退/击飞切换为动画驱动模式（motion_type=1），位移由引擎动画系统计算，双端仍各自独立运行相同动画。传送/闪现为瞬时位置跳变。翻越障碍的起点/终点由双端各自地形查询确定。

下面 6.1 节展开基础摇杆移动的模拟流水线——这是最核心的路径，也是其他位置源（Buff 速度、MoveStrategy）的计算基础。

6.1 基础移动：从摇杆输入到角色移动

玩家推动摇杆到角色在屏幕上移动，中间经过5 个阶段的模拟计算。客户端和服务器各自独立执行相同流程，客户端先于服务器完成并立即表现：

技能位移时的流水线变化：当角色处于冲刺、突进、钩子拉拽等技能位移状态时，流水线的第 2~3 步被 MoveStrategy 替换：

• 冲刺/突进（RMMoveStrategy）：速度不再由摇杆+查表决定，而是按"匀加速→最大速度→距离上限停止"的策略计算，方向和参数由技能配置决定。
• 钩子拉拽（HookMoveStrategy）：速度方向指向钩子施放者，按"加速牵引→接近时减速"计算。

这些 MoveStrategy 的输出仍然是速度向量，最终仍送入第 4 步 CCT 碰撞检测——因此冲刺撞墙会停下，被钩子拉到障碍物前也会停住。物理碰撞保证位移结果的合理性。

6.2 独立预测 CCT 实例

客户端创建一个完全独立的 IEntity + CharCtrlComponent，专门用于预测物理模拟，与渲染角色的 CCT 完全隔离：

1. 创建一个独立的物理实体（IEntity）和角色控制器组件（CharCtrlComponent）
2. 设置碰撞参数——必须与服务器完全一致：碰撞层 = 31、台阶高度 = 0.3、胶囊体半径 = 0.3、半高 = 0.65（总高 1.3m）
3. 将实体放入当前场景的根区域，使其能参与碰撞检测

为什么需要独立实例：预测循环需要在一帧内反复调用 CCT 模拟（回滚推演时一帧模拟 10+ 次）。如果复用渲染角色的 CCT，会污染渲染位置导致角色闪烁。独立实例让预测计算和渲染完全解耦。为什么要放入场景：CCT 碰撞检测需要知道周围的墙壁、地形、障碍物，独立 CCT 必须进入场景区域才能获得正确的碰撞信息。

6.3 双端 CCT 物理模拟对比

客户端和服务器的 CCT 调用方式不同（不同引擎 API），但输入输出语义完全对齐：

两个 API 的调用形式不同，但内部都走 PhysX 的 CCT::move() 碰撞检测管线，输入语义（位置+速度+dt）和输出语义（碰撞后位置）完全一致。

6.4 速度计算全流程

每帧速度合成 5 步流程：

pose_type 与动画的关系：姿态类型决定了角色当前的姿态（站立、蹲伏等），它同时影响速度（蹲伏时基础速度降低）和动画（蹲伏时播放蹲伏移动动画）。预测系统只关心速度数值，不直接控制动画播放。动画由渲染侧的状态机根据 pose_type 和速度大小自动匹配。

6.5 运动模式切换：物理驱动 vs 动画驱动

游戏中角色的移动有两种驱动方式，通过运动模式属性动态切换：

切换时机由服务器通过属性同步触发（如技能释放导致击飞动画）。切换后，模拟的输入源从摇杆变为动画曲线——本质上仍然是双端各自运行相同的模拟，只是模拟内容从"物理驱动位移"变为"动画驱动位移"，保证双端输出一致。动画驱动模式下 Filter 关闭物理位移应用、摇杆输入清零、yaw 取模型当前朝向。

CCT 模式下的精细控制：在 CCT 物理模式下，还有一个子开关控制客户端的模拟时机——独立模拟（默认，客户端立即执行 CCT 物理模拟）或等待服务器模拟结果（牺牲即时性换取更高一致性）。用途：某些特殊场景下（如服务器需要精确控制位置），可以临时让客户端从"先模拟后对比"切换为"等结果再应用"。

6.6 禁移集合

角色在某些状态下不能移动（如被眩晕、释放技能前摇中）。预测系统通过一个集合管理所有禁移来源：

• 检查：每帧物理模拟开始前，先检查禁移集合是否为空。只要集合非空，直接返回原位置，跳过整个速度计算和 CCT 模拟。
• 添加：技能触发禁移时（如眩晕生效），将自身标识加入集合。
• 移除：技能结束禁移时（如眩晕恢复），将自身标识从集合中移除。

使用集合而非布尔值是因为：多个技能可能同时禁移（眩晕 + QTE），任一个解除后如果用布尔值就会误开移动。集合保证"所有禁移来源都解除后才恢复移动"。这个集合在双端都维护，推演时也参与计算。

6.7 预测位置到屏幕渲染：Filter 平滑

预测系统的输出是一个逻辑位置（CCT 物理模拟后的精确坐标），直接赋给角色会导致微小抖动。Filter 组件在两者之间做平滑过渡：预测逻辑位置 → Filter（输入：累计时间, x, y, z, 朝向角）→ 渲染模型位置。累计时间每帧递增、每 10s 重置一次以防浮点溢出。Filter 不是简单线性插值——它在引擎 C++ 层完成从当前渲染位置到预测位置的平滑过渡。回滚推演后的新位置也通过 Filter 输入，保证修正对玩家透明。

两个位置的区别：预测逻辑位置是物理层的精确预测坐标（用于逻辑判断、Buffer 存储、发送给服务器对比）；模型渲染位置是经过 Filter 平滑后的位置（用于屏幕显示）。两者在大部分时间几乎一致，只有回滚修正时会短暂出现微小差异，Filter 负责在几帧内消除这个差异。

07技能预测系统

7.1 技能预测：核心算法的延伸

技能预测和移动预测遵循相同的核心框架（输入 → 模拟 → 输出），但在输入完备性上存在本质差异：

移动模拟输入完备——摇杆方向、速度因子等在客户端本地完全可知，双端拿到相同输入执行相同模拟，结果确定性高。技能模拟输入不完备——技能结果依赖对方状态（目标有没有霸体、敌方有没有攻击），这些输入客户端不完全知道，因此双端模拟可能产生不同结果。

输入不完备意味着技能模拟比移动模拟更容易出现双端不一致。但核心算法的回滚重模拟机制天然处理了这种情况：客户端先按已知信息乐观模拟，服务器用完整信息独立模拟后回传结果，客户端收到后通过相同的回滚重模拟流程修正。关键是修正要快、要无感知。

7.2 技能预测通用流水线

7.3 Snapshot 快照机制

每个预测技能每帧会生成一份快照（Snapshot），记录该技能当前的预测状态。快照随帧数据在双端传递，用于对比预测是否正确。客户端快照记录"客户端认为的技能开始帧号 + 当前运行帧号 + 各技能自定义字段"，服务器快照记录"服务器确认帧号 + 服务器当前帧号 + 模拟结果字段"。快照内容由各技能子类自定义，基类只负责帧号对比。核心逻辑：如果双端的"技能开始帧号"一致，说明预测正确；不一致则修正为服务器的值。这种设计让每个技能可以传递自己需要的额外对比数据（如格挡成功标记、眩晕失败标记等）。

7.4 典型技能案例

以下挑选三个典型技能，从简单到复杂展开讲解预测实现方案：

典型技能 1：逃跑方嘲讽

复杂度：低 —— 纯客户端表现，不影响对方状态

典型技能 2：眩晕被动

复杂度：高 —— 影响移动状态，需要双端对比，有不一致回滚

典型技能 3：格挡/弹反

复杂度：最高 —— 有前摇、免疫窗口、格挡成功判定、动态时长扩展，多种双端对比结果

技能效果：逃跑方角色举盾格挡，前摇 4 帧后进入免疫窗口。如果在免疫期间被追逐方攻击，触发"弹反"效果（成功格挡），免疫持续 3 帧后结束；如果没有被攻击，持续到技能总时长 35 帧后自然结束。格挡是逃跑方在被追击时的关键自保技能。

为什么预测困难：

核心难点：双向事件信号 + 精确帧窗口

交叉

眩晕 ↔ 格挡 双向联动：眩晕被动在触发时检查免疫 Buff 字典，如果格挡存在则 dispatch 免疫事件。格挡技能监听此事件，标记格挡成功并延长技能持续时间用于播放弹反动画。两个技能在预测时间线上互相影响。

窗口

4 帧前摇精确控制：格挡释放后的前 4 帧，免疫状态尚未生效。如果眩晕恰好在这 4 帧内触发，格挡无效——但客户端和服务端可能因为网络延迟在不同 tick 判定"是否过了前摇"，导致结果分歧。

一次性

格挡成功后免疫窗口消耗：格挡成功后免疫 Buff 字典仅保留 3 帧（播放弹反动画期间），之后移除。这意味着格挡是一次性消耗品——成功一次后即失效，不会重复触发。

时间线与状态机

每帧预测逻辑

格挡技能每帧执行（客户端和服务器双端一致）：

1. 技能是否结束？
  已持续帧数 ≥ 总时长 → 清除特效，结束技能

2. 技能进行中 → 是否过了前摇？
  已持续帧数 ≤ 4（前摇中）→ 不免疫
  已持续帧数 > 4（过了前摇）→ 进入免疫判定：

    2a. 是否已经格挡成功？
    尚未成功 → 持续免疫（等待被攻击触发格挡）
    已经成功 → 判断距离成功帧的时间：
      ≤ 3 帧 → 免疫有效（格挡后的短暂保护）
      > 3 帧 → 移除免疫，结束技能

服务器快照携带的三个关键信息

信息	含义	客户端如何修正
技能结束帧	格挡成功后技能时长被缩短（从 35 帧变为成功帧+3）	用服务器的值更新客户端的技能结束时间
格挡是否成功	服务器判定：在免疫窗口内是否受到了攻击	如果客户端没预测到格挡成功，补发免疫效果
格挡成功帧号	格挡成功时对应的客户端帧号	对齐免疫窗口的起始时间，确保"成功后 3 帧"双端一致

双端对比的四种结果

这类技能的关键点：预测逻辑必须双端完全一致（服务器也运行同样的 pd_tick），快照字段精确传递格挡成功帧号以对齐免疫窗口，四种对比结果都有专门的修正路径。这是预测系统中技术复杂度最高的技能类型。

眩晕 + 格挡 = 预测系统中复杂度最高的交叉场景

两个预测技能在同一条预测时间线上相互影响：眩晕检查格挡的免疫字典，格挡的免疫事件被眩晕 dispatch 触发。预测失败时两个技能都需要独立回滚到正确状态。设计原则：以服务器为准，目前不对格挡做延迟补偿——格挡和眩晕各自修正为服务器状态即可。

7.5 技能预测架构：HybridSkillSystem

所有预测技能通过技能状态管理系统统一管理，每帧按优先级排序执行：

这种统一调度体现了核心算法的一致性：回滚重模拟时，技能系统和移动系统走的是完全相同的模拟路径——禁移集合、免疫 Buff 字典在重模拟中被正确更新，确保移动模拟拿到的输入状态与首次模拟一致，算法输出自然收敛。

08速度 Buff 预测系统

速度 Buff 预测是核心算法在"输入同步"维度上的延伸。在追逃玩法中，加减速 Buff 直接改变移动模拟的速度因子输入——如果双端的速度因子不一致，即使摇杆输入完全相同，模拟输出也会发散。本系统通过服务器预推送未来 0.5 秒（17 帧）的速度因子序列，确保客户端在模拟时拿到的速度因子输入与服务器一致。

Buff 叠加规则

• 相同 Buff ID：层数叠加，每层独立结算开始/结束时间
• 不同 Buff ID：效果逐项叠乘（最终速度因子 = 各 Buff 因子连乘）
• 支持 Buff 临时禁用：临时抑制指定 Buff，禁用期满自动恢复
• 过期 Buff 自动 GC，每帧清理 dirty 列表

09技能与 Buff 适配案例

前面章节介绍了预测系统的框架和子系统。本节通过 5 个机制案例 + 3 个典型技能，展示具体适配过程中的工程复杂度与解法。

10服务器饥饿预测

以上是预测系统在各玩法上的适配。接下来关注极端网络条件下的容错设计。

当网络丢包导致服务器输入缓冲区为空时，服务器不会停止模拟，而是进入饥饿预测模式：

设计原则：服务器绝不预测技能释放。服务器饥饿预测仅复用移动方向，技能指令一律清空。技能释放涉及游戏结果判定，错误预测的代价远高于延迟。若饥饿期间客户端实际发出了技能指令，待收到后通过指令追加队列立即补发。

11网络传输优化

11.1 协议栈设计

11.2 冗余发包与丢包恢复

滑动窗口机制：

• 客户端每帧发送时，附带最近 8 帧的历史输入，实现前向纠错
• 服务器连续 3 帧未收到输入时，开启滑动窗口（大小 13 帧 ≈ 400ms），通知客户端加速发包
• 客户端根据服务器反馈的缓冲区保障大小动态调节发送频率

11.3 自适应发送频率

• 服务器缓冲区积压（> 2 帧）→ 客户端发送间隔 × 1.1（降频，减少积压）
• 服务器缓冲区即将耗尽（≤ 1 帧）→ 客户端发送间隔 × 0.9（加速，防止饥饿）

11.4 延迟检测与动态开关

12调试与可视化

开启 PREDICT_VISUAL_ENABLE=True 后，场景中会渲染三个球体：红球（客户端预测位置，r=0.3）、紫球（服务器权威位置，r=0.1）、绿球（回滚重模拟位置，r=0.2）。三球重合说明预测准确；分离距离直观反映偏差大小。

实时监控面板

13技术亮点与创新总结

14Q & A

Q1：预测系统的性能开销大吗？

首先要明确一个前提：每个客户端只预测自己操控的角色。6 人对局（2V4）中，其他 5 个玩家的位置、动画、轨迹都由服务器状态同步驱动，不走预测系统。预测系统的计算量 = 1 个角色的模拟开销，不会随对局人数增长。

• 客户端计算：常规帧只做 1 次速度合成 + 1 次 CCT 碰撞 + 1 次 Filter 输入，计算量远小于渲染帧。独立 CCT 实例不带渲染组件，纯物理模拟。回滚帧（偶发）最坏重模拟 10+ 帧，实测总耗时 < 1ms。
• 服务器计算：每个预测玩家每秒 30 次模拟 tick。6 人对局 = 每秒 180 次 tick。服务器每 5 秒采样"饥饿预测率"，正常网络下 < 5%，无额外开销。
• 带宽：单帧上行 < 150B（Protobuf + zlib），8 帧冗余总计 < 1.2KB，30 FPS ≈ 4.5 KB/s 上行——远低于手游移动网络预算。

Q2：表现良好的核心要点是什么？

预测系统"表现好"不是指"预测总是对的"，而是"对的时候立即响应，错的时候玩家无感知"。实现这一点靠三个层面：

• 一致率要高：五层对齐把双端模拟偏差压到 < 0.00001m/帧，绝大多数帧不触发修正。一致率越高，玩家越感受不到预测的存在。
• 修正要无感：回滚重模拟走完全相同的模拟路径，输出与原始预测差异极小。Filter 组件在引擎层做位置平滑过渡，修正幅度在 1~2 帧内消化完毕，玩家肉眼不可见。
• 输入要同步：影响模拟结果的所有输入（速度因子、禁移状态、运动模式）都有对应的同步机制——预推送、属性同步、集合同步。输入一致了，输出自然一致。

反过来说，如果一致率低（每帧都修正）或修正不平滑（直接跳到新位置），玩家会感到角色"一会前进一会后退"，手感比不预测更差。

Q3：这是竞技游戏，公平性怎么保证？时间差带来的逻辑冲突怎么解决？

核心原则：预测只是客户端的视觉提前量，不影响服务器的判定结果。

所有玩家的输入最终都汇集到服务器，由服务器按统一的帧序逐帧处理。服务器不关心输入是早到还是晚到——它只看自己当前帧该消费哪个输入，按到达顺序放入缓冲区，逐帧取出执行。每个玩家的模拟在服务器上是独立串行的，不存在并发冲突。

时间差带来的典型冲突与解法：

本质：预测系统不改变游戏的判定公平性——它只改变了"玩家什么时候看到结果"，不改变"结果是什么"。所有判定由服务器统一执行，所有客户端最终收敛到同一结果。

Q4：什么情况下会用裸 UDP？为什么不用 KCP？

核心考量是延迟和响应速度。预测系统的整个意义就是消除延迟，如果传输层本身引入额外延迟，就和系统目标矛盾了。因此上行（客户端→服务器）使用裸 UDP，下行（服务器→客户端）仍走 KCP。

上行为什么用裸 UDP：预测帧数据是高频（30次/秒）、小包（<150B）、时效敏感的数据。KCP 的 ARQ 重传机制会为每个包附加序号、确认号、重传缓冲，显著增大包体；更关键的是，丢了的帧不需要重传——一个迟到 100ms 的旧帧对预测毫无价值，不如直接丢弃。预测系统用自研冗余发包替代可靠性：每包携带最近 8 帧数据（FEC 思路），收到任意一包就能恢复近 8 帧。

下行为什么用 KCP：服务器回包包含权威位置 + 速度因子序列 + 技能快照，这些数据不能丢——丢了一帧权威结果意味着客户端无法对比、无法修正，会导致预测偏差累积。下行频率也是 30 次/秒，但每帧结果都不可替代。KCP 的可靠传输保证每帧结果都送达，代价是偶尔多几 ms 的重传延迟——但下行延迟不影响操作手感。

包体超限保护：当压缩后上行包体 > 400B 时，放弃携带冗余历史帧，只发当前帧——避免 UDP 包体超过 MTU（~1400B）导致 IP 层分片。

总结：上行追求最低延迟（裸 UDP + 冗余替代重传），下行追求不丢数据（KCP 可靠传输）。上行决定操作响应速度，下行决定修正及时性——两个方向的需求不同，所以传输策略不同。