你开枪的那一刻，自己、对手和服务器，可能正处在三条不同的时间线上。理解它们，比记住“帧同步”或“状态同步”更重要。
按四部分阅读：先建立基础直觉，再用综述梳理同步问题与方法，接着比较商业框架与 Godot 原生 / netfox，最后拓展到近期研究。所有演示都是简化教学模型，不是网络实测，也没有运行论文的神经网络。
阅读路线：1 基础原理 → 2 综述：同步问题与方法 → 3 商业化框架 → 4 拓展阅读：近期研究。
2022 综述作为经典方法的分类地图；商业部分包含 Godot 原生 / netfox 技术对比、接入结构与验证方法。
先看延迟如何产生，再用交互演示理解插值、预测、回滚、命中补偿与状态同步。
按键后先等采样，再等发送，消息经过网络，服务器排到下一次模拟，结果还要回传和显示。网络 RTT 只覆盖这条链路的一部分。本地画面立即动了，不代表服务器已经认可；画面每秒刷新 60 次，也不代表它拿到了 60 份新状态。
预算假设：输入采样平均 8 ms、模拟耗时 2 ms、输出显示 8 ms；服务器到 tick 的平均等待为半个 tick；本例计算完立即发送，不额外等待快照批次。真实系统还要测发送队列、丢包重传、渲染、显示器与客户端处理。
延迟：到得晚。
抖动：有时晚一点，有时晚很多。
丢包：一次更新没到。
乱序：后发的先到。
排队：带宽或处理能力不够，旧数据堵着新数据。
输入迟钝：按了没反应。
远端卡顿：别人一顿一顿。
回拉 / 瞬移：预测被纠正。
结果争议：我看到命中，他看到躲开。
旧世界：动画很流畅，敌人的状态却很陈旧。
能直接减少实际等待的措施：更近的服务器、更少的排队、更短的处理周期。预测、插值和回溯则是在信息还没到时，决定显示什么、相信什么、最后如何裁决。
原理来源：[V] Valve：基本架构、客户端预测；[S] 综述 §3。预算计算为本文示例。
服务器每隔一段时间拍一张“位置照片”。收到就跳过去，会显得不连续。插值先缓存照片，把显示时间放在两张已经收到的照片之间，再补出中间位置。它用一点显示延迟换取稳定、连续的运动。
图中“最新状态”会一格一格跳；插值在两份快照之间平滑过渡；外推从最新状态出发，假设速度不变。轨迹在 2.4 秒突然反向，外推会继续朝错误方向走，直到新消息到达。
本例定义：目标显示时刻 = 估计服务器现在 − 基础单向延迟 − 额外缓冲。工程实现也可以把两项合称总插值延迟；两种口径都可以，不能把网络延迟重复加减。
设已收到快照 (t₀,x₀)、(t₁,x₁)，显示时刻为 tᵣ：
α = (tᵣ - t₀) / (t₁ - t₀) xᵣ = (1 - α) x₀ + α x₁ 仅当 t₀ ≤ tᵣ ≤ t₁ 才是插值
没有右端快照时，应选择有限外推、暂停推进或调整缓冲。每帧 lerp(current,target,0.1) 是追赶滤波，不自动建立正确的服务器时间轴。
字节流必须按序交付。一段字节丢失后，即使后面的新状态已经到达，应用也可能暂时拿不到它们。独立数据报允许直接采用更新的完整快照。
演示中用固定 220 ms 补齐丢失字节，只解释队头阻塞；并未模拟 TCP 拥塞控制、真实重传计时或链路带宽。UDP 也不会自动获得更短的传播时间。
来源：[I] Snapshot Interpolation；[V] Display of Targets。图示算法与合成网络由本文构造。
本地预测通常不需要 AI。你已经知道自己按下了“向右”，用与服务器尽量一致的规则先走一步即可。难点在于：服务器返回的是过去的状态，客户端已经又走了好几步。
这里客户端因遗漏一次外力，预测 #101 后的位置为 5，而服务器确认应为 4。#102 和 #103 又分别向右移动 1 格。正确的当前状态是 4 + 1 + 1 = 6，既不是旧的预测 7，也不是直接覆盖成过去的位置 4。
收到权威快照 S，确认输入编号 ack： 丢弃所有编号 ≤ ack 的输入 simulation_state = S 按原顺序重放剩余输入（使用原来的固定步长） visual_offset = 之前的显示位置 - 新模拟位置 逐渐衰减 visual_offset，只平滑显示层
同一输入可能被重放多次。脚步声、枪口火光、震动不应因此重复播放；命中、消耗和计分也需要稳定事件编号与去重策略。重放必须使用历史输入，不能重新读此刻键盘。
自己的预测还可能依赖远端对象：碰撞的玩家、移动平台、开关门。只保存自己的坐标而忽略这些依赖，重演就可能再次出错。预测范围越大，恢复状态与重算的成本越高。
来源：[V] PDF 第 5–7 页：Client Side Prediction 与效果去重。格子例子与伪代码由本文编写。
在格斗类回滚中，两边运行同一个确定性游戏。远端输入还没到时，先猜对方继续上一个动作；真实输入到达并且与猜测不同，就恢复到最早出错帧之前的状态，用正确输入重算到当前帧。不是把屏幕倒放，而是在两次画面呈现之间补算过去。
同一初始状态 + 同一组输入 + 同一规则，必须得到同一结果。需要保存位置、速度、血量、技能状态、随机数状态、生成销毁记录、计时器等所有影响结果的数据。
固定 tick 是必要的常用基础，但固定 tick ≠ 确定性。对象遍历顺序、浮点差异、未保存的物理接触状态，都可能导致分歧。
多等几帧，可以让更多真实输入赶上使用时间，从而少回滚。代价是本地动作也晚几帧开始。延迟式与回滚式可以混合。
等待再短也不能覆盖无限延迟。预测窗口到顶后必须有明确策略，例如暂时等待或断线处理，不能无限重算。
| 机制 | 回到哪里 | 随后做什么 | 典型用途 |
|---|---|---|---|
| 客户端校正 / reconciliation | 服务器确认的旧状态 | 重放尚未确认的本地输入；可能包含依赖对象 | 权威服务器的角色移动 |
| GGPO 式 rollback | 最早错误预测之前的完整相关状态 | 替换远端输入，重算后续模拟 | 确定性格斗、小规模对战 |
| 命中回溯 / lag compensation | 射手当时看到的历史碰撞状态 | 查询射线命中，随后继续当前世界 | 即时射线武器 |
它们共享“保存历史”的想法，但恢复的范围、输入来源和裁决权不同。服务器权威与回滚也不是互斥选项；OPODIS 论文研究的正是客户端—服务器架构下的回滚。
来源：[G] GGPO Developer Guide：Game State and Inputs、Synchronization、Synctest；[O] §2.2、§3–§4。
射手瞄准的是一个已经被网络与插值推迟的目标。如果服务器只检测“现在”的位置，射手明明瞄准身体，却可能打空。Valve 的做法是估计开枪时射手看到的历史时刻，在历史命中盒上检查射线。
本例固定：射手在服务器时钟 1000 ms 对应的时刻开枪；下行延迟 40 ms；目标在 980 ms 进入掩体。默认参数下，射手看到的是 900 ms 的目标；指令到服务器时已经是 1100 ms。服务器查 900 ms 的历史，能够判中；但目标早已进入掩体。
希望查询的历史时间 = 服务器处理时间 - 指令上行耗时 - 射手所见世界的落后量 本例：1100 - 100 - (40 + 60) = 900 ms
这是帮助理解的时间预算，不是把 RTT/2 直接塞进生产代码的配方。真实实现需要估计时钟偏移、校验命令 tick、限制客户端声明的插值量与历史窗口，并处理抖动；RTT 无法唯一分解为上行与下行。
回溯窗口越大，对高延迟射手越宽容，也可能让目标感觉更“冤”。窗口越小，掩体保护更接近当前时刻，但射手会遇到更多看似命中的空枪。这里需要游戏规则作取舍，不能靠同步算法让两种观察同时成为过去的事实。
工程上可以保存命中盒历史并在独立查询结构里检测。如果临时修改碰撞对象，则必须完整恢复并避免触发副作用。射线、移动子弹和爆炸不是同一问题：有飞行时间的炮弹，还要决定生成时间、飞行追赶、沿途碰撞和动态掩体怎么处理，不能把射线回溯直接照搬。
来源：[V] PDF 第 10–13 页：Lag Compensation、Game Design Implications。上限裁决与位置模型是本文教学设计。
Gaffer 的 State Synchronization 使用更具体的含义：两端都继续模拟，同时发送输入和状态纠正。它不同于“远端只保存快照并插值”的方案，也不要求像纯输入锁步那样永远逐位一致。
只发位置，接收端却沿错误速度继续跑，下一次纠正还会跳。对刚体，线速度和角速度常与位置、方向一样重要。
量化能节省带宽，但量化后的微小误差进入物理模拟后可能放大。Gaffer 在案例中同时量化两端，减小双方起点差异；这不自动保证任意引擎的确定性。
每帧累积对象的发送优先级，包预算允许时从高到低装入，真正装进去的对象才清零。近处交互对象频繁更新；暂时不重要的对象也会因累积而轮到。
AOI 决定“谁需要收到”，优先级决定“这次先发谁”。发得越多并不一定越实时：超过带宽后，等待队列会把新状态变旧。
收到正确状态后，如果把碰撞体慢慢拉向它，下一步模拟可能从一个既不属于客户端、也不属于服务器的状态出发。更清晰的做法是：恢复合适的模拟状态，再让模型相对它的视觉偏差逐渐归零。大型纠正要及时收敛，小抖动可以更柔和。具体碰撞策略仍需按游戏验证。
来源：[F] State Synchronization：Priority Accumulator、Jitter Buffer、Applying State Updates、Quantize Both Sides、Visual Smoothing。本文未复现其刚体案例性能。
商业框架里已经有其中相当一部分。关键是分清它们修改的是显示、预测状态、执行时刻，还是玩法规则。一个 SDK 提供 RPC 和属性复制，只说明消息能传过去；要做到低延迟体验，还需要输入历史、时间管理、重算、历史查询和发送预算。
下面“经典补偿”一组的分类沿用 2022 综述 §4；下面的操作步骤与数值例子是本文的工程化解释。框架能力见下一章官方资料，研究分支没有强行标成商业默认功能。
从左到右读；点击方法跳到详解。箭头表示应对关系，不表示能彻底消除问题。
三条必须连起来的依赖：
预测 → 输入编号与确认 → 历史恢复 → 重演 → 显示平滑 / 效果去重。
历史命中 → 射手显示时间 → 历史命中盒 → 合法窗口 → 权威裁决。
增量复制 → 每接收者已知基线 → 解码与 ACK → 基线失效时恢复。
共同使用“历史”不代表可以共用一套判定：预测历史服务于重算，命中历史服务于查询，增量基线服务于解码。
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games — Shengmei Liu, Xiaokun Xu, Mark Claypool
它梳理 85 篇同行评审文献，将技术归为四大组、11 种基础类型。对开发者最有价值的阅读方式，是用它区分：预测缺失的信息、调整执行时间、改变空间规则、调整呈现方式，各自在牺牲什么。
读完应得到的能力：当玩家抱怨“卡”时，先判断是响应慢、状态旧、位置跳还是结果不一致，再选机制。不要把全部问题压成一个 ping 数字。
经典补偿的四组、11 种方法：下文 2.3–2.6 分别介绍反馈、预测、时间管理与规则调整。
先让人知道操作已发生，或说明网络正在变差。不改变权威世界。
利用本地输入、历史运动或多个候选未来，在消息到达前生成可显示的状态。
有时等一等，有时查过去。管理不同机器的时间差，而非缩短传播距离。
放宽操作或命中条件。它可能改善可玩性，同时改变原本的竞技规则。
解决：开枪、互动、技能启动等待服务器时的“按了没反应”。
做法：按键时立即播放枪口火光、后坐力或准备动画，生成本地事件编号；请求同时发给服务器。返回结果后再确认伤害、消耗与奖励。若失败，取消尚未确认的效果。重放同一输入时用事件编号去重。
代价：已播出的声音不能收回，故即时效果与最终胜负需要不同确认策略。这与“立即模拟角色位置”的自预测不同；两者可以一起用。Unity NGO 的 anticipation 提供相近的先反馈、后校正构件，但具体技能效果仍由游戏编写。
综述 §4.1.1；NGO 的 anticipated / authoritative 两份值。
解决：玩家把网络延迟误认为操作无效或游戏规则失灵。
做法：统计 RTT、到达间隔与快照年龄，显示网络图标、数值、待确认标记；研究中也有“影子位置”或不确定区域。RTT 低但快照老，应暴露后者，而不是只显示绿 ping。
代价：它提升可解释性，不提高命中精度或减少传输时间。框架可提供测量数据，什么时候显示给玩家是产品决定；本次没有核实任何框架默认提供综述中的全部不确定区域可视化。
综述 §4.1.2。
解决：自己的移动要等一次往返才响应。
做法：为输入编号并记录步长 → 本地执行 → 发给服务器 → 收到“已执行到编号 k”的状态 → 恢复该状态 → 重放 k 之后的输入 → 平滑显示误差。服务器验证的是移动规则、速度和碰撞，而非相信客户端最终坐标。
真正需要框架管理的东西：输入环形缓冲、状态历史、过期确认、重放顺序、预测作用域和一次性效果。角色冲刺会影响移动时，冲刺状态也必须进入这条历史，不能只复制一个布尔值。
实现入口：UE CharacterMovement 的 SavedMove；Fusion Unity 的网络 tick；Unity Entities 的预测系统组。代价：碰撞依赖越多、延迟越大，重算越贵。不是所有对象都必须预测。
解决：远端玩家每收到一次消息就跳一下。
做法：按服务器时间戳收集快照；选一个稍旧的显示时刻 t；找到包围 t 的两份状态，再按时间比例插值。朝向可用四元数插值；位置有速度时可用 Hermite，但需要防止越过障碍或曲线过冲。
动态缓冲：记录消息到达的抖动分布，选择覆盖大部分抖动的缓冲；持续欠载时扩大，网络恢复后逐渐缩小，避免显示时间突然倒退。发生传送或重生时应清理历史，不能横跨整张地图插值。
代价：更平滑但更旧。框架插值通常负责网络时间轴；每帧固定比例 lerp 只是追赶滤波。Fusion 2.1 已公开基于抖动分位数的配置，见下面算例。
解决：最新状态已经过时，或丢了一两次更新。
做法：从时间戳 t₀ 的位置、速度出发，计算 x(t)=x₀+v₀Δt；可靠的加速度模型可加 ½aΔt²。设外推时间上限，超限后冻结、减速或扩大缓冲。新状态到了再纠正误差。
为什么不是万能：匀速车辆好猜，突然反向、被撞、跳跃结束与新障碍都可能猜错。只在当前世界射线检测，并不能推导过去发生的碰撞。学习型状态预测也是“如何补缺失状态”的一种模型选择，不必先上神经网络。
商业对应：UE 的部分网络物理模式、Fusion Forecast 都利用状态与速度进行前推/纠正；它们不等于每次恢复整段历史的 resimulation。选择时要看物理交互需求。
综述 §4.2.2.2；物理的两条路线；MPAI-SPG 是学习型补状态的研究例子。
解决：云端要等玩家输入再模拟和渲染，整个链路才开始工作。
做法：当前输入尚未知时，先计算“向左 / 向右 / 不动”等分支，准备相应状态或图像；真实输入到达时选择匹配分支，其余丢弃。覆盖不到的输入再走纠错路径。
代价：连续输入与多个玩家会导致分支组合爆炸，消耗额外计算和带宽。综述主要举 Outatime。不要把普通“保存过去，猜一个未来，错了重算”的 rollback，叫成同时预算多条未来。
商业状态：本次核实的框架文档没有证明它们默认采用这种多分支云渲染方案；不能因为都叫 prediction 就画上勾。
综述 §4.2.3，PDF 第 18 页。
解决：消息来晚时，直接在“现在”处理会与玩家所见冲突。
做法有两种：一是恢复检查点、插入晚到的真实输入并重算后续帧；二是保存历史命中盒，只对历史做命中查询，不重演整个世界。两者都要校验时间戳、限制历史窗口、避免副作用。
商业对应：Quantum 是确定性预测/回滚；Fusion Unity Host/Server 有 Hitbox 历史查询。二者保存的状态、权限和最后做的工作不相同。
代价：历史内存、重算 CPU、可撤销事件，以及“躲进掩体后中枪”的取舍。框架能提供机制，不能替设计者确定公平窗口。
解决：输入到达时间不同导致大量预测错误、执行不同步。
做法：立即发送本地输入，但安排到未来第 k+d 帧执行；或把收到的消息放入时间桶，按统一时刻应用。显示端的快照缓冲也是延后消费消息的相关做法，不能把执行延迟与显示延迟混成一个参数。
例子：60Hz 下人为等 2 帧约 33ms，可让这段时间内赶到的真实输入替代猜测。若晚到 5 帧，只覆盖了其中 2 帧，仍可能需要重算。
商业对应：Quantum 的输入延迟设置；Fusion 2.1 可让客户端用额外输入延迟约束重算数量。代价：本地操作晚开始，应与 CPU 峰值、纠正频率一起衡量。
综述 §4.3.2.1；Quantum 配置；Fusion 时间策略。
解决：某些公平性规则要求不同网络条件的玩家尽量同时看到事件。
做法：同一更新，先发给慢链路，晚些发给快链路。假设可准确估计单向延迟，目标到达时间为 T，则每个连接的发送时间为 T−估计传输时间。设最大等待上限，防止全体被最慢连接拖住。
代价：主动牺牲快连接的响应，且单向时间估计与抖动会破坏对齐。普通打包等待可能也延迟发送，但目的不一定是公平性。本次未核实所列 SDK 默认启用按玩家 ping 均衡的发送延迟。
综述 §4.3.2.2，PDF 第 21–22 页。
解决：玩家指向的是旧目标位置，精细瞄准难度变大。
做法：在合适范围内降低准星移动增益、让准星跟随目标，或修正弹道靠近目标。要限制作用距离、角度、目标选择，并按统一规则在权威端验证。
与命中回溯不同：回溯询问“过去这条射线是否命中”；控制辅助修改输入或射线，使其更易命中。商用游戏可以有瞄准辅助，但这不证明它是按网络延迟动态启用。
代价：改变技能要求与竞技平衡。综述中的许多实验研究本地系统延迟或鼠标操作，并不是公网多人验证；通常属于游戏玩法层，非通用复制器自动解决。
综述 §4.4.1。
解决：坏网络使原来的反应窗口、目标大小或移动速度过于苛刻。
做法：放大有效目标、降低游戏速度或延长动作有效时间。例如将判定半径 r 调整为 r+ε，实际上是更改判定规则，而不是恢复真实历史。调整幅度必须有上限，并防止不同系统重复补偿。
代价：可玩性可能改善，但玩家之间可能适用不同规则；若直接奖励高延迟，还可能出现人为制造延迟的激励。不能因为某游戏命中盒较宽就宣称它使用了延迟自适应属性调整。
商业状态：引擎允许你编写这些规则；本次没有证据表明所列网络框架默认执行综述这种按延迟调属性的策略。
综述 §4.4.2。
不在这 11 个叶节点里，却同样影响低延迟：AOI、优先级、增量压缩、输入冗余和发送节奏。它们主要控制“发送哪些数据、用多少带宽、何时送达”。带宽队列一旦堆积，再好的预测也只能补越来越旧的信息。
以下为跨资料的工程综述，不属于 2022 论文的 11 项分类。机制事实链接到原文；协议流程、数值例子和验收建议明确作为本文推导。
问题：位置不一致，究竟是通信问题还是规则分歧？
机制：先分开三个轴：拓扑是客户端—服务器还是对等连接；同步载荷是输入、状态还是事件；裁决权归谁。它们可以组合。“服务器权威”不等于只发状态，“回滚”也不等于必须 P2P。
落地过程：快照插值让远端主要显示收到的状态；Gaffer 式状态同步让接收端继续模拟并接受纠正；确定性输入同步让多端根据同一输入演算。选择后再决定哪些对象预测、哪些对象只插值，避免同一 transform 被两个控制器同时写。
代价与验证：代价转移：少发状态通常需要多算模拟和更严格的一致性；少做预测通常增加可见等待。角色、NPC、投射物可以走不同路线，但交互依赖必须明确。
问题：都叫第 100 帧，却并非同一时刻。
机制：消息带会话标识、序号和模拟 tick；时钟模块持续采样往返时间，估计服务器时间与不确定性。物理 tick、发送频率、渲染帧率分别管理。
落地过程：例如服务器 60 Hz 模拟、20 Hz 发快照，快照每次跨约 3 tick；渲染仍可 120 Hz。客户端预测时刻可以领先，显示远端时刻可以落后。时钟修正要限制追赶速度；重连或大跳变时显式重建时间基准。
代价与验证：RTT/2 只是对称路径近似。给客户端任意声明历史 tick 的权利，会把时钟估计问题变成裁决漏洞。记录偏移变化、输入迟到率和缓冲占用，而不只记录 ping。
依据与边界：Fusion 时间同步；数值及协议字段为设计示例。
问题：明明输入一样，几秒后位置却越来越不同。
机制：固定步长只是第一步。保存所有影响结果的状态，固定随机数流、对象迭代顺序和生成销毁时机，验证目标平台的数学与物理行为。纯输入锁步等待必需输入；预测回滚则先猜，再纠正。
落地过程：按 tick 对规范化状态计算校验值，首次不一致时比较分模块摘要，再定位具体字段。用同一录制输入做“连续执行”和“存档、恢复、重演”对照。权威快照可以修正有限分歧，但不能掩盖遗漏状态。
代价与验证：跨平台逐位一致的成本可能很高；只同步输入仍需要初始状态、加入恢复与失步修复。选择状态纠正路线时，也要限制分歧频率与回拉幅度。
依据与边界：Gaffer · Deterministic Lockstep；分模块诊断流程为本文建议。
问题：丢了一包，为什么之后的新位置也卡住？
机制：先按语义拆消息：可替代的新状态、不可跳过的输入、必须只生效一次的交易。序号拒绝旧状态；冗余携带近期输入并去重；关键事件做确认与幂等。收到、执行、最终提交是三种不同确认。
落地过程：输入包 105 可以携带 103、104、105；收到重复 104 不再执行。独立完整快照 105 能替代丢失的 104，但依赖 104 的增量不能。选择性重传、输入冗余或 FEC 是不同恢复策略；冗余更简单，FEC 以额外字节和编码/等待成本恢复有限丢失，本页不宣称具体 SDK 默认启用 FEC。
代价与验证：多通道不等于跨通道全局有序；可靠流中的缺失字节仍会挡住后续字节。Godot WebSocket 的底层语义不会因为 RPC 标记变成 UDP。最终要用突发丢包和带宽限制测试。
依据与边界：队头阻塞演示、Godot 传输边界、输入冗余实例。
问题：玩家一多，低 ping 也变成陈旧世界。
机制：先减少接收者，再减少对象与字段，再压缩编码，最后限制发送节奏。AOI/可见性决定谁收到；优先级决定本轮先发谁；量化限制精度；增量只发相对已知基线的变化。
落地过程：教学预算：每客户端 100 个对象 × 每次 40 字节 × 20 Hz = 80,000 B/s，尚未计包头与恢复。将相关对象降到 25 个就是 20,000 B/s。增量需记录每个接收者确认的基线；基线失效时回到完整状态。预算溢出时合并可替代的旧更新，关键事件另行排队。
代价与验证：AOI 切入要先发送可用初始状态；切出不等于世界停止模拟。提高频率可能压垮链路，过度量化可能放大物理误差。监测队列年龄、每连接字节数及对象最长未更新时间。
依据与边界：Snapshot Compression、优先级累积、Godot 可见性、netfox ACK 基线；预算为本文算例。
问题：角色碰上箱子后，总在来回纠正。
机制：建立依赖范围：角色站的平台、推动的箱子、碰到的玩家都可能影响重演。明确哪个对象只显示、哪个参与预测，以及历史状态覆盖到哪里。恢复位置速度并不必然恢复物理求解器内部状态。
落地过程：小范围交互可把依赖对象放进同一重演集合；其他对象使用服务器状态或简化代理。重要交互需要历史恢复与可控物理步进；弱交互对象可用外推与连续纠正。对象从只插值切换到预测时要初始化状态和历史。
代价与验证：预测范围越大，CPU 与历史内存越高；越小，碰撞越可能不一致。裁剪预测不能随意破坏接触依赖。限制每帧追赶量并设置降级策略，避免重算耗时又制造更多迟到。
依据与边界：商业物理路线、预测裁剪、netfox 物理接入；依赖集合为工程解释。
问题：回滚后伤害翻转了，但掉落已经发出。
机制：服务器验证输入权限、速率、时间窗口和动作规则；模拟状态与外部副作用分开。给事件稳定 ID，区分暂定、确认、提交，重演不会重复播放音效或重复入账。
落地过程：在允许历史修订的架构中，tick 104 的死亡可能被 tick 102 的迟到输入改写。可延后不可逆提交，或定义可撤销奖励与补偿规则。若只在客户端重演、服务器持续向前，则确认边界不同，应按实际协议设计。
代价与验证：同步算法不能验证所有作弊，也不能自动提供数据库恰好一次语义。幂等键要覆盖会话与动作身份；命中回溯只查询历史，不能直接替代所有技能的权威验证。
问题：刚进房间、回到 AOI 或重连时，状态突然错乱。
机制：恢复包提供一个一致的基准 tick、对象标识及代次、必要状态；后续更新按基准衔接。建立恢复过程的阶段：获取基准 → 补齐更新 → 进入实时。清理旧会话的输入、ACK 与预测历史。
落地过程：如果下载 tick 500 的基准时服务器到了 520，可缓存并应用后续变更；缺口超过可用历史就重新取基准。销毁后复用对象 ID 时带代次，避免迟到包“复活”旧对象。恢复期间不要把未初始化碰撞体送入预测。
代价与验证：恢复流量会与实时流量竞争；需要预算、超时和重新取基准的规则。主机迁移还涉及裁决权转移，不只是重新连一个地址。本节提供设计检查项，未验证现有项目实现。
依据与边界：工程推导；参照 状态基线与对象可见性、验证条件。
问题：固定缓冲在好网络太慢，在坏网络又不够。
机制：把控制循环分成观测、决策、执行：观测到达抖动和欠载；调整插值缓冲、输入等待、更新频率或预测范围；限制调整幅度与频率。每个调节项都有预算和上下限。
落地过程：分位数缓冲覆盖历史样本的多数尾部，但不保证下一次突变。学习方法还有两种不同对象：MPAI-SPG 猜游戏状态；CLAAP 猜网络延迟并决定何时启用昂贵预测。模型不可靠时退回有上限的外推或缓冲。
代价与验证：同时调所有旋钮会难以解释，甚至形成振荡。先与固定策略、简单统计控制比较，再评价学习收益；指标应含预测误差、输入响应、CPU、欠载与裁决翻转。研究逐篇分析仍放在第四部分。
依据与边界：Fusion 的时间配置、分位数算例、近期研究。
| 玩法需求 | 可验证的起始组合 | 优先暴露的风险 |
|---|---|---|
| 角色移动 + 射线武器 | 权威验证 → 本地输入预测/校正 → 远端插值 → 历史命中查询 → 特效去重 | 冲刺、动态掩体、回溯上限与服务器时间校验 |
| 小规模确定性对战 | 确定性模拟 → 输入同步 → 少量输入延迟 → 预测/回滚 → 最终事件确认 | 跨平台失步、历史上限、重复副作用 |
| 合作物理交互 | 权威状态 → 选择性预测 → 可控物理步进/恢复 → 纠正后的显示平滑 | 两人推同一物体、隐藏接触状态、重算峰值 |
| 大型持续世界 | 分区与兴趣过滤 → 对象优先级 → 量化/增量 → 恢复基线；近处动作另加预测 | AOI 边缘、切区、初始同步洪峰、跨区交互 |
这些是工程起点，不是互斥框架或性能承诺。逐步加入机制，并在相同输入、网络轨迹和带宽预算下验证。
这里比较的是公开文档可核实的机制，不是广告里的“低延迟”标签，也不是商业游戏采用率排名。版本口径：Fusion Unity 2（部分时间策略限 2.1）、Quantum 3、Unity NGO 2.13、Entities 1.10，以及 Epic 当前在线文档。Godot 版 Fusion 3 单列为开发预览。
| 框架 / 组件 | 提供的机制 | 如何接入 | 不能自动得到 |
|---|---|---|---|
| Photon Fusion Unity 2 | Host/Server 的预测与重演；快照插值；历史命中盒查询 | 网络 tick 中写模拟；注册输入与网络状态；配置 Hitbox | 任意脚本可安全重放、任意物理成本可接受；Shared 模式同等能力 |
| Photon Quantum 3 | 确定性模拟、确认输入、预测/回滚、verified / predicted 帧 | 用 Quantum ECS 与确定性库写玩法 | 把已有 Unity/Godot 非确定性物理原封不动搬进去 |
| Unreal CharacterMovement | 角色移动预测、保存移动、权威校正、重放与网络平滑 | 使用/扩展 CharacterMovement 与 SavedMove | 全部技能、刚体世界和射击命中都自动回溯 |
| Unity Netcode for Entities 1.10 | 预测 Ghost、输入与 tick、重演系统组、逐对象预测选择 | 预测逻辑加入 ECS 系统组，正确处理 Simulate 标记 | 普通 MonoBehaviour 自动加入历史重算 |
| Unity Netcode for GameObjects 2.13 | Anticipation：预期值与权威值分离、过期数据处理、平滑 | AnticipatedNetworkVariable / Transform；自己写请求规则 | 完整的输入历史 + rollback-and-replay 循环 |
| Photon Fusion Godot 3 预览 | Client-Server 输入队列、预测重置与重演；远端平滑；Forecast 物理路线 | Godot 4.6+ GDExtension；FusionServerReplicator | 生产成熟度保证，或 Unity 版所有功能已移植的保证 |
| Godot 原生 | 复制、RPC、生成与可见性构件 | 自行实现网络时间、预测与历史 | 复制属性不自动确认或重放输入 |
| Godot + netfox | 共享 tick、历史回滚、输入延迟/冗余、tick 插值 | 声明状态，接入回滚回调；物理另接驱动 | 不等于自带射手视角命中回溯或确定性物理环境 |
在 FixedUpdateNetwork() 里处理 tick 输入和模拟；客户端先预测，服务器快照到达后以权威状态为基础重演。渲染读取模拟状态之间的插值。这里的价值是框架统一管理时钟与重演，而不是开发者到处手写独立的 lerp。官方模拟循环。
射击则是另一条路径：给对象配置 HitboxRoot 与 Hitbox，调用 Runner.LagCompensation 查询历史。可用 sub-tick 选项对客户端当时看到的两个 tick 之间状态查询；历史长度可配置。官方限制是 Server / Host 模式。这不会消除目标与射手之间的公平性冲突。官方命中补偿。
Fusion 2.1 文档公开了按抖动分布选缓冲、允许一定比例迟到快照，以及用额外输入延迟限制重演量的设置。下例演示其中的分位数取舍；公式是本文自定，不是 Fusion 内部算法。
官方对应配置：Max Late Snapshots、Redundant Snapshots、Client Max Resims Per Frame，均注明 Fusion 2.1。Time Synchronization。本例的额外间隔是独立可加的教学余量，不能当作官方 Redundant Snapshots 的精确公式；尾部比例也不是实际卡顿率。
Quantum 将玩法放进自己的 ECS 和确定性数学、物理等库，Unity 负责呈现。常规同步的核心是输入；服务端协调输入与时钟，客户端运行模拟。这种结构省去了持续发送所有对象状态的需求，但要求玩法遵循确定性规则。需要权威玩法复核时，不能把协调输入的服务端自动视为完整裁判模拟。官方架构。
Verified 帧使用服务器确认的输入，Predicted 帧允许客户端提前运行。Quantum 文档描述了持续回滚/重演的工作方式，不能简单理解成“只要位置误差超阈值才重算”。Frames。输入延迟范围与回滚历史窗口可配置。SessionConfig。
其 Prediction Culling 还能跳过不相关对象的预测计算，而在 verified 帧维持必需的完整模拟。这与 AOI 不同：一个减少重算 CPU，另一个减少向某客户端发送的数据。官方裁剪说明。
本地自主角色把移动写入 FSavedMove_Character，发送移动数据；服务器重新执行并确认或纠正；客户端据此删除确认记录、重放剩余移动。其他机器上的角色走网络平滑。扩展冲刺、攀爬等移动时，影响模拟的额外数据也要保存、序列化和重放。官方 CharacterMovement 流程。
所以：使用 CharacterMovement 获得的是角色移动的预测机制；不能据此推断通用 Actor 复制也会重放全部逻辑，或 LineTrace 自动访问过去的命中盒。需要哪类历史，仍要选对组件或另行实现。
根据服务器与本地速度调整运动，使对象逐渐接近应在的位置。UE Predictive Interpolation 属于这一路线。它允许一些本地预测交互，成本通常比完整重算低，但碰撞和高延迟仍会降低质量。
保存每个物理 tick 的状态；按相同历史帧比较服务器结果，差异足够大时恢复、纠正、重算到当前。UE Network Physics 提供相关底层机制，需要 C++ 接入输入和自定义状态；消耗历史内存与重算 CPU。
Epic Networked Physics Overview。两种模式可以混用；“Predictive Interpolation”是特定物理模式名，不能直接等同于前文两快照之间的普通位置插值。
Fusion Unity 物理重演也要求框架接管物理步进，并把逻辑放进网络 tick。高延迟客户端需要重复做更多物理工作，应在目标最坏网络下测 CPU。Fusion Physics Addon 2.1。
IInputComponentData 表达带 tick 的输入；预测逻辑进入 PredictedSimulationSystemGroup，一帧显示期间可能执行多个模拟 tick。Ghost 可以选择预测或插值，NetworkTime 暴露模拟与插值时间。
一个细节很能体现框架价值：部分快照可能让不同对象处于不同确认时刻。代码必须尊重 Simulate 标记，只重算该 tick 真正需要更新的实体，否则会把部分对象多推进。一次性特效也要防止重复触发。官方预测循环与部分快照。
框架还提供预测平滑和逐对象切换预测模式。它改变的是客户端需要模拟的范围和时间，不是让所有 MonoBehaviour 自动确定性执行。1.10 功能入口。
AnticipatedNetworkVariable 与 AnticipatedNetworkTransform 分开保存预期值和权威值。你先让玩家看到结果，再根据服务器数据决定忽略旧响应、重新预期或平滑纠正。
它适合解释“点击后立即变色，随后确认”的交互。官方仍明确说明它没有完整的 rollback-and-replay 预测循环。回调能让开发者继续搭建系统，不等于已经替你记录并重放了全部移动输入。不能只因为产品叫 Netcode，就推断 NGO 与 Entities 的预测覆盖相同。NGO 2.13 Client anticipation。
UE Replication Graph 把相关对象组织成可复用的节点/列表，避免每个 Actor 每次逐一检查每个连接。官方用 Fortnite 的规模说明为何朴素检查会成为 CPU 瓶颈；这不是“所有对象每 tick 都广播”的方案。Replication Graph。
Iris 的优先级会跨网络 tick 累积，发送后重置，让低优先对象也有机会更新。这与 Gaffer 的优先级累积思想相近；过滤决定接收者，优先级决定发送顺序。当前相关文档带有 Experimental 提示，不能据此统一称作所有项目默认的成熟配置。Iris Prioritization。Iris 和 Replication Graph 是替代系统，不能假设同时叠加启用。迁移边界。
工程推导：增量数据应说明依赖哪份基线；基线没收到就需要恢复路径。输入可冗余带上最近几步，用序号去重。这通常比把所有高频状态排进可靠队列更能保持新鲜度，但不能消除突发丢包。
SDK 下载页提供 3.0.0 Preview，发布日期 2026-07-17，要求 Godot 4.6+，以 GDExtension 接入。官方明确说开发预览不用于生产，API 可能变化。不能再简单说“Photon 只有 Unity 集成”，也不能因此把成熟 Unity 版的所有特性都算给 Godot。官方 SDK 状态。
Client-Server 模式使用 FusionServerReplicator：queue_input() 入队，process_input_queue() 驱动同一份输入处理；本地预测、服务端权威执行。预测重置后重新执行缓冲输入，is_new 用来避免重复播放效果，state_reset 通知纠正。Prediction and Input。
Shared 模式是对象拥有者直接写状态；Client-Server 才是输入与权威模拟的路线。两种模式不能只看“谁更快”就替换，改模式会改变权限与代码结构。拓扑对照。本次未验证 Godot 版具备 Unity LagCompensation Hitbox/sub-tick 的同等历史查询 API，也没有安装、运行其 SDK。
原生 MultiplayerSynchronizer 管属性复制和可见性；你的预测控制器仍需负责输入确认、历史和校正。社区 netfox 已有 NetworkRollback / RollbackSynchronizer、输入延迟、输入冗余、显示偏移、历史上限与差异状态。其文档还描述了服务器接收旧输入后回算的行为，所以不能默认它和“服务器永不回滚”的设计完全相同。netfox 回滚指南。
刚体是额外的工程门槛。netfox 物理指南要求可手动步进的物理实现，并列出带步进能力的引擎构建或替代物理插件，配合 PhysicsDriver、NetworkRigidBody 和保存的物理状态。不要把“节点坐标能回滚”误认为整个物理世界已恢复。这里是该插件文档的条件，本次未测试你项目的引擎与插件组合。物理接入要求。
如果继续做 Godot 实时动作游戏：先验证一个权威角色的“输入 → 本地预测 → 服务器确认 → 重演”，再加入远端快照插值；射线武器另做历史命中盒。对比原生自建、netfox 与 Fusion Godot 预览时，用同一段输入和同一组网络扰动测纠正、CPU 和快照年龄，别只比较能否看到两个人移动。
这也解释了研究与产品的关系：经典方法已经被封装进框架；近期工作的价值常在预测模型、适应策略、计算预算或保证边界。本文核对的商业文档不能证明 MPAI-SPG、CLAAP 或该 OPODIS 模型已经被这些 SDK 集成。
框架资料核对日期：2026-09-11。版本、来源与未验证项清单。商业服务身份、开源许可、SDK 功能和生产成熟度是不同维度；本文没有评估价格、许可合同或吞吐量承诺。
Godot 原生、netfox 不能合并成一列。原生主要提供传输、RPC、属性复制与生成；netfox 在这些构件之上增加共享时间、历史、预测与回滚。与商业方案的差别，应看具体算法和集成范围，而不是付费与免费。
核对：2026-09-11。核心表以 Fusion Unity 2 的 Host/Server 模式为商业参照，时间策略特别注明 2.1；它不是可直接装入 Godot 的版本。netfox 发布页当前指向 v1.35.3，详细机制引用维护者文档；latest 可能领先发行包。下文“未核实”等于本次证据不足，不等于无法实现。
负责把约定的数据送到对端。你定义时间与纠正协议。
提供可参与回滚的时间循环和节点工具。你声明完整状态、接入可重演玩法。
把更多模拟、时间与历史机制放进统一框架。你仍负责玩法合法性与预测边界。
| 技术问题 | Godot 原生 | Godot + netfox | Fusion Unity 2 Host/Server |
|---|---|---|---|
| 共同的 tick 与时钟 | 物理帧和复制间隔不是跨机器共享时钟；时钟偏移、tick 对齐需自建。 | NetworkTime 驱动网络 tick；同步器区分远端、参考、模拟时钟，模拟时钟单向推进。[N1] | 框架管理预测与插值时间轴；2.1 暴露自适应时间配置。[F1] |
| 按键立即移动 | 自己采集带编号输入、本地模拟、发送，并记录待确认历史。 | RollbackSynchronizer 声明 Input / State 属性；在 _rollback_tick 中执行可重演逻辑。[N2] | 在 FixedUpdateNetwork 中消费输入，参与框架预测；网络状态随权威快照恢复。[F2] |
| 权威更新来了怎么办 | 复制器写属性；“确认到哪条输入、恢复与重放”不是它的职责。 | 恢复历史状态，按回滚 tick 重算，再记录状态；遗漏的玩法变量仍会造成持续纠正。[N2] | 从权威状态重演后续 tick；开发者仍须让相关逻辑与状态参与重演。[F2] |
| 远端画面平滑 | 网络时间戳与快照缓冲需设计；引擎物理插值不等于网络抖动缓冲。 | StateSynchronizer 配合 TickInterpolator；后者插值网络 tick 之间的显示状态，可用 teleport 跳过突变。[N3] | 快照插值与框架时间管理结合；缓冲保证尽量有可插值的样本。[F1] |
| 坏网络时自动等多久 | 自行测到达间隔、决定分位数、欠载策略和时钟调整。 | 有 input_delay、display_offset、history_limit；本次未核实与 Fusion2.1 相同的分位数缓冲控制器。[N2] | 2.1 按抖动分布配置允许迟到比例和冗余快照，亦可用输入延迟限制重演量。[F1] |
| 输入包丢失 | 传输层可选可靠/不可靠；输入冗余、去重、执行确认需另建。 | input_redundancy 把历史输入随新输入再发，减轻丢包缺口；突发丢包仍会超出覆盖。[N2] | 输入与预测机制集成；具体冗余与恢复表现仍须按 SDK 配置实测，不能比较一个通用“成功率”。 |
| 射手所见的历史命中 | 需自建历史命中盒、合法射击时间、查询与最大回溯窗口。 | 有回滚历史不等于有射手时间视角的命中查询。未核实开箱即用的同等 Hitbox/sub-tick API；FAQ 也指出 favor-the-shooter 不容易。[N4] | HitboxRoot / Hitbox + LagCompensation 查询历史；可选 sub-tick；限 Host/Server。[F3] |
| 刚体碰撞后重演 | 完整物理状态保存、恢复及可控步进要单独解决；复制 transform 不足以恢复物理世界。 | 物理驱动与 NetworkRigidBody 可接入回滚；指南要求支持手动步进的引擎/物理插件，且要保存 physics_state。[N5] | Physics Addon 接管步进、恢复和重演；多次物理计算增加客户端 CPU。[F4] |
| 只向相关玩家发送 | MultiplayerSynchronizer 有 per-peer 可见性过滤；相关性规则由你写。[G1] | v1.35.3 有接收者过滤；StateSynchronizer 源码亦使用 PeerVisibilityFilter。兴趣范围与大世界调度仍要设计。[N6/N7] | 已有兴趣管理体系；要区分复制筛选与客户端预测范围，详见前章。 |
| 状态与带宽 | 有复制间隔、按变化同步等构件；紧凑编码和总带宽预算仍需设计。[G1] | StateSynchronizer v1.35.3 按每个接收者 ACK 的基线编码差异；基线缺失时退回完整状态。[N7] | 状态同步与网络模拟集成；节省多少字节取决于状态、频率和对象范围，不在此给无依据的倍率。 |
| 声音、伤害、掉落去重 | 自己设计事件编号、确认条件和补偿规则。 | 在回滚环境中区分模拟与副作用；latest 指南列出输入到达状态查询。is_fresh 与 input_delay 有适用警告。[N2] | 模拟可能重复执行，框架不能替你决定一次伤害何时不可撤销。 |
| “确定性”的要求 | 内置联网不保证跨平台逐位确定。 | 客户端—服务器的状态纠正路线不要求严格逐位相同，但差异必须可控；它不是只同步输入的严格确定性框架。[N4] | 依赖权威快照纠正预测；与 Quantum 的确定性输入同步应分开评价。 |
最重要的三个差别：“有插值”不代表有自适应抖动缓冲；“有回滚”不代表有历史射线命中补偿；“可以纠正状态”不代表所有端必须逐位确定。技术对比要拆到这一层。
按游戏协议决定丢弃、限制、后续执行或对特定动作查历史。客户端收到确认再校正自身预测。历史命中查询可以只处理碰撞盒，不重算全部玩法。
这是权威状态预测的一类架构，不代表所有框架的默认晚包策略都相同。
晚到输入可能触发服务器从相关历史 tick 重演，再将更新状态发给客户端。参与回滚的对象、保存的变量与允许窗口决定能重算什么。[N2]
不能把这个行为当作“只在客户端回滚”。服务器也要有 CPU 与不可撤销事件的预算。
实际后果：如果 tick 104 已经发放掉落，tick 102 的新输入又改变了死亡结果，就需要延后提交、事件去重或补偿机制。把伤害代码移进 _rollback_tick 只是开始；还要决定哪一刻死亡成为最终结果。类似问题在其他回滚架构也存在，解决方式取决于它们的确认与历史规则。
| 商业路线 | 相对 netfox 的核心差别 | 面向 Godot 的实际意义 |
|---|---|---|
| Fusion Unity 2/2.1 | 同属状态纠正型预测，但时钟控制、历史命中查询、Unity 物理接管形成更集中的接口体系。 | 适合作为协议与功能参照；Unity 的 FixedUpdateNetwork/Hitbox 不是 Godot 原生接口。 |
| Quantum 3 | 提供确定性模拟环境、确认/预测帧；常规输入分发驱动相同模拟。netfox 通过权威状态纠正来容忍有限分歧。[Q1/N4] | 不能只替换网络插件，保留全部 Godot 玩法和物理不变；这是模拟架构迁移。 |
| UE CharacterMovement / Network Physics | 角色 SavedMove 与物理历史/步进由不同引擎组件深入集成；netfox 则通过节点配置、回调和额外物理驱动接入。 | 学习保存哪些移动状态、何时重算很有价值；无法直接安装这些 UE 组件到 Godot。具体机制见 UE 和 网络物理。 |
| Unity Entities 1.10 | 预测集成进 ECS 系统组与逐实体 Simulate 标记；netfox 以节点/属性为组织单位。 | 差异在调度与数据布局，不意味着 ECS 必然更快；用同样对象与玩法测量才可比较。见 Entities。 |
| Unity NGO 2.13 | 有 anticipation 构件，但没有完整回滚重放循环；就这项技术而言，不能笼统认为商业引擎官方包比 netfox 更完整。 | 保留 Godot 并采用 netfox，可以获得 NGO 本身没有提供的回滚循环；不代表全部功能与质量都胜出。见 NGO。 |
| Fusion Godot 3 预览 | 同在 Godot：FusionServerReplicator 用输入队列、prediction reset 和 buffered input 重演；netfox 用 NetworkRollback 的历史 tick 循环。[FG1] | 直接可比，但 Fusion Godot 仍是预览；不能借 Unity 版名声认定其拥有同等命中补偿、物理重演或自适应缓冲。见 SDK 状态。 |
| 你在同步什么 | 合适的构件 | 需要自己保证 |
|---|---|---|
| 自己控制、需要立即响应的角色 | RollbackSynchronizer + 相关 Input/State 属性 | 所有影响结果的变量参与历史；移动、碰撞、随机数与技能状态可重演。 |
| 服务器单独驱动的 NPC 画面 | StateSynchronizer + TickInterpolator | NPC 是否需要与预测对象交互；若需要，不能只考虑显示平滑。 |
| 渲染模型、朝向 | TickInterpolator | 只插值应显示的属性；传送重生重置插值，不污染下一次模拟。[N3] |
| 无需回滚的少量配置/状态 | 可保留原生 MultiplayerSynchronizer | 同一属性只能有清晰的写入负责人，避免原生复制器与回滚控制器争抢。 |
| 刚体交互 | 物理驱动 + NetworkRigidBody + RollbackSynchronizer | 可控步进、physics_state、接触状态恢复；按驱动文档验证，不能只保存位置速度。[N5] |
源码核对后的修正：一份旧节点指南仍说 StateSynchronizer 没有 delta/visibility，但 v1.35.3 源码已经有两者。第 46 行创建 PeerVisibilityFilter；第 169–200 行按连接取已确认的 reference_tick，生成差异状态；基线不存在、历史已清理或差异编码没有收益时，退回完整状态。第 235–264 行处理差异状态及 ACK。固定版本源码。
例如 A 确认到 tick 100，B 确认到 tick 96：服务器生成 tick 105 更新时，对 A、B 可以使用不同基线。如果 B 的基线已从历史清理，就发送完整状态。这说明 netfox 已有具体的带宽恢复机制；它仍不等于自动提供空间索引、大规模兴趣调度与固定字节预算。
下面是建议的验收条件，不是本次测得的结果。以两人角色移动、推箱子和射线开火为同一场景；固定逻辑 tick、状态发送频率、输入记录和网络轨迹。分别测原生自建、netfox 与可运行的商业候选。
成本直觉：历史内存大致随“对象数 × 每对象保存状态 × 历史 tick 数”增长，实际还含容器与物理缓存；重算耗时随重演 tick 和参与对象增加。只同步输入可能省网络，却要求每端模拟更多世界。状态筛选可能省流量，却增加依赖与恢复设计。任何框架都不能免除这些交换。
针对 Godot 的建议：原生足够支撑你自建任何一种协议，但工程量最大；netfox 已补齐许多时间与回滚构件，值得优先验证角色与小范围交互；严格射手视角命中补偿、复杂刚体恢复和大型世界调度要另设验收。Fusion Godot 可作为预览对照，不应直接当成成熟 Unity 版的替代品。
[G1] Godot MultiplayerSynchronizer；原生能力缺口指该组件未提供对应机制，不指引擎无法扩展。
[N1] NetworkTimeSynchronizer。[N2] NetworkRollback。[N3] TickInterpolator。[N4] netfox FAQ。[N5] Physics。[N6] v1.35.3 发行说明。[N7] v1.35.3 StateSynchronizer 源码（本地研究副本）。
[F1] Fusion 时间同步。[F2] 模拟循环。[F3] 命中补偿。[F4] Physics Addon。[Q1] Quantum Frames。[FG1] Fusion Godot 输入与预测。
这里只核实公开技术机制，没有宣称安装测试了这些 SDK，也没有用一个包的文档代替另一个版本。没有可比压测数据，所以不列延迟、并发量或 CPU 的“获胜排名”。
下面是为 Godot 4 提出的模块结构，不是已写入你游戏的实现。先做服务器权威 + 角色预测 + 远端插值，再按玩法决定是否增加全局回滚、命中回溯或学习模型。
| 模块 | 必须负责 | 最容易漏掉 |
|---|---|---|
| NetworkClock | 服务器时钟 / tick 估计、RTT 与抖动 | 把 RTT/2 当成准确单向延迟 |
| InputHistory | 输入编号、原步长、未确认输入 | 服务器确认“收到”不等于确认“已执行” |
| Simulation | 可显式 step 的玩法规则、状态保存 | 用墙上时间、随机数、SceneTree 顺序产生隐藏输入 |
| SnapshotBuffer | 时间戳、乱序处理、插值和超界策略 | 没有右快照却继续无限外推 |
| HitHistory | 历史命中盒、查询时间限制 | 动态掩体与射线武器之外的规则 |
| VisualRoot | 只平滑显示偏差、特效事件去重 | 平滑修改碰撞体，或重放时重复音效 |
MultiplayerSynchronizer 提供权威属性复制与可见性过滤，MultiplayerSpawner 处理生成/销毁；它们不会自动补齐输入历史、时间轴、预测重放和命中回溯。对于关键属性，明确谁写入模拟状态、谁写入显示状态，避免复制器和自定义校正互相覆盖。
原生端可用 ENet。连续快照通常适合不可靠模式配合序号；关键持久事件可可靠发送并去重，按用途分通道。连续输入可以冗余携带最近若干步，服务器按编号处理。不同可靠通道之间没有全局消息顺序，而共享链路仍有总带宽上限。
Godot 浏览器端不能直接用原始 UDP/ENet，可使用 WebSocket 或 WebRTC。WebSocket 的可靠有序字节流存在队头阻塞；RPC 的传输标记不能改变 TCP 的底层语义。WebRTC 部署还涉及信令、连接建立与可能的中继；原生支持需要相应扩展。
需要全局回滚时，先验证 save → step → load → step 两次得到的状态一致，再联网。不要假设直接把 _physics_process() 多调用几次，就等于完整重演 Godot 物理世界。
API 边界：Godot MultiplayerSynchronizer、High-level multiplayer、WebRTC（2026-09-10 核对）。模块划分为本文设计建议。
一个算法把画面变平滑，可能只是把整个世界再延迟 100 ms。另一个算法把预测误差降下来，可能多占用半个 tick 的 CPU。评估必须同时保留响应、状态新鲜度、纠正成本、游戏结果。
| 网络条件 | 要暴露的问题 | 注意口径 |
|---|---|---|
| 上下行分别设置延迟 | 输入慢与远端快照慢是否混为一谈 | 单向 75 ms ≠ RTT 75 ms |
| 抖动与乱序 | 插值缓冲耗尽、旧包覆盖新状态 | 记录实际到达序列 |
| 独立丢包与突发丢包 | 输入冗余、状态恢复、外推边界 | 暂停 TCP 字节流不等于模拟 UDP 丢包 |
| 带宽受限 | 旧消息队列堆积、AOI 与优先级失效 | 固定平均 RTT 也可能出现长期排队 |
| 服务器短时过载 | 模型推理或重算反过来制造延迟 | 区分网络与服务器处理时间 |
报告中给出中位数、p95/p99 和最大值，注明样本时长与配置。只用少量样本估计 p99 会很不稳定；只展示平均 FPS 又会漏掉偶发但决定胜负的错误。
不能。预测允许本地先显示结果，服务器仍需等到消息或按既定缺失输入策略推进。立即反馈和最终确认是两个时间。
不能。延迟越大，缺失信息与错误预测越多，保存和重算成本越高。窗口到顶会等待或降级，关键结果也可能明显翻转。
不一定。还要看递归误差、首次突变、最坏推理时间、真实玩家分布与错误恢复。MPAI-SPG 的候选模型排序在递归测试中就发生了变化。
不能由名字得出这个结论。要检查服务器实际验证了什么、模拟了什么、哪些结果由客户端决定。复制状态的中心节点与完整服务器裁决并不等价。
本章为实验设计建议。本次交付验证的是文档、演示和原文下载，没有修改或测试你的 Godot 游戏网络性能。
在经典方法与框架实现之后，再看研究如何推进它们：MPAI-SPG 预测缺失的游戏状态；CLAAP 预测网络并按需调度昂贵的状态预测；OPODIS 则分析理想一致性的边界。三篇分别回答不同问题，不能当作可互换的联网库。
AI Server-Side Prediction for Latency Mitigation and Cheating Detection: The MPAI-SPG Approach — Daniele Spina et al.
服务器缺少某辆车的数据时，学习型模型利用过去的车辆状态和赛道上下文，预测位置、速度和朝向。它关心的是其他玩家看到这辆车能否继续自然运动。模型使用 LSTM 加 MLP，案例建立在 Unity 和 Mirror 上。
重要结果：离线验证误差最低的模型，在连续使用自己预测结果的测试里反而表现最差。这说明“预测一步准”不等于“连续补多步稳定”。
证据边界比标题更重要：12 人、单工作站、1 名真人与 3 辆 AI 车；以预测状态替代部分更新，没有在用户实验中注入真实网络延迟。反作弊由于预测不够准确，没有完成用户实验验证。
原文证据 PDF 第 4–5 页：用 Unity ML-Agents 生成约 200 万条记录，按 50% / 25% / 25% 分为训练、验证、测试。推理耗时超过服务器一步，因此增加采样/预测间隔 D；列出的最佳候选采用 D = 0.2 秒。不能据此宣称已经实现每个 60 Hz tick 的学习型预测。
第 5 页表 I 与图 4：模型 4 验证 MAE 最低，但递归预测表现差，最终用户实验选模型 1。第 6 页表 II：AL2 每约 10±2 秒连续启用 0.3 秒；AL3 每约 8±2 秒连续启用 0.6 秒。它们是预测激活设置，不是测得的网络 RTT。
体验与响应评分未检出显著差异（p=0.26、0.68）；AL3 的异常行为评分显著差于 AL1。未检出差异不等于证明体验完全相同。AL1 总是先进行，也可能混入熟悉游戏的影响。
设计推导 在 Godot 里先录制真人急刹、碰撞与转弯，再比较保持上次输入、匀速外推和学习模型。除一步 MAE，还应测试连续 100/200/400 ms 数据缺失后的误差与恢复回拉。模型残差大的合法操作必须允许存在，不能直接认定作弊。
验证边界 案例客户端发送车辆空间状态，不能把文章的“权威服务器”标签等同于已实现完整、可信的输入验证与服务器物理裁决。训练场景较窄，跨赛道、跨玩家、战斗碰撞泛化仍需测试。
Real-time Latency Prediction for Cloud Gaming Applications — Doriana Monaco et al.
CLAAP 使用 RBF 神经网络预测接下来的延迟，并用贝叶斯在线变点检测判断网络规律是否发生变化，必要时重训练。游戏实验把它放在 SPG 前面：只对预测会出现高延迟的客户端启动状态预测，从而减少不必要的计算。
这里的贡献包括控制补偿成本，不只是“用 AI 猜未来”。论文报告平均预测误差改善约 21%；这是延迟预测误差的变化，不是网络 RTT 降低 21%。
细读后的修正：标题和训练轨迹来自云游戏，但 §6 的系统实验使用 Unity/Mirror 多人赛车与应用层延迟轨迹注入。不能直接把该实验说成商业云游戏平台的端到端视频交互验证。
原文证据 §3–§5：RBF 隐藏单元可理解为不同“历史延迟模式”的相似度探头，输出层加权组合。默认使用最近 6 个值、20 个中心，预测下一个值；训练轨迹按约 16 ms 取样。变点检测按 50 点窗口分析，触发后在新数据上适应。
PDF 第 7 页表 2：Offline 的平均 NRMSE 为 0.074，Online 为 0.058；汇总重训练开销均值 17 ms，是该实验口径下的累计开销，不应当误读成“每次预测必花 17 ms”。第 10 次运行 Online 反而略差。§5.5 还明确指出：突发变化的首次尖峰不能被准确预知，模型是在后续相关数据上更快适应。
§6 比较持续运行 SPG、SPG-CLAAP、SPG-LSTM、SPG-EWMA；采用四分钟会话、AI 驾驶、六台客户端机器和高性能工作站。低/中/高严重度指 5% / 20% / 50% 客户端被分配延迟轨迹，不是每个包的丢失率。CLAAP 在该实验中维持约 60 FPS 至 80 客户端，简单 EWMA 也表现出低开销，但误判更多。
设计推导 先问“按需激活”贡献多少，再问“神经网络”额外贡献多少。把 EWMA、最近值、分位数规则当基线，检查漏判导致的卡顿和误报浪费的 CPU。推理与重训练都应有时限和过期结果丢弃策略。
验证边界 FPS、推理耗时与资源用量不能替代瞄准、驾驶控制和公平性的用户实验。论文结尾也把更多游戏类型与 QoE 验证列作未来工作。原文 §6.1 客户端数量列表与表 3 的配置列表并不完全一致，复现时应明确每张图使用的场景；不要自行补齐缺失数据。
Formalizing Rollback Netcodes for Robust and Real-Time Client-Server Architectures — Yérom-David Bromberg, Jérémie Decouchant, Manon Sourisseau, François Taïani
论文用游戏相关权重衡量状态的“语义距离”。背景物体位置差一点，可能无关紧要；命中和未命中、死亡和存活的分歧，则可能改变胜负。理想沉浸性要求玩家看到的状态与服务器状态始终足够接近。
在作者的模型下，维持这种理想性质会约束延迟与游戏状态变化；当对手可以任意拖延消息时，不能同时保证同样的理想体验与抗延迟攻击性质。
这是在给定模型下分析保证边界，不是测出一种更快的回滚算法，也不是“所有网络游戏都不可能公平”的通用定理。
原文证据 §3–§4 假设客户端—服务器拓扑、可对齐的离散 tick、可靠消息、确定性更新函数。服务器收到该 tick 所需的所有输入才计算对应权威状态。很多现实服务器采用截止时间和缺失输入预测，并不逐项满足这一模型。
§4.2 先用加权距离描述重要程度，再用可见性投影只比较玩家看得见的部分。最直观的关系是：如果 A 与权威状态相差不超过 η，B 也不超过 η，那么共同可见部分中 A 与 B 的距离最多 2η；这来自三角不等式。它只是理解语义一致性的入口，不能代替论文后面的完整证明。
设计推导 把“被迫纠正位置 10 cm”和“撤销一次死亡”分开计数。在最终确认前，枪口火光可以先播，但击杀、掉落等关键结果应有更谨慎的确认策略。限制回溯时间也会影响真正遭遇坏网络的用户，需要公开一致的规则。
验证边界 本文提供直观解释，没有独立形式化验证所有定理。应特别注意论文中 rollback 主要指权威服务器纠正与客户端重算，不能把所有结论直接套到纯 P2P GGPO。本文也不会把其对延迟攻击的讨论称作已部署的防御系统。
| 资料 | 关键问题 | 主要证据 | 不能推出 |
|---|---|---|---|
| 2024 MPAI-SPG | 缺失车辆数据怎么补 | 模型测试与小样本用户实验 | 真实公网、反作弊已验证 |
| 2025 CLAAP | 什么时候需要昂贵预测 | 轨迹预测与赛车系统实验 | RTT 降低 21%、80 人 Godot 容量保证 |
| OPODIS 2025/2026 | 理想语义一致性需要什么条件 | 形式模型与理论分析 | 任意架构下的通用性能或公平性结论 |
PDF 页码从下载文件第一张开始计数，MPAI-SPG 与 CLAAP 含机构封面。经典网页另存为作者源 Markdown；其远端视频未打包，正文讲解使用本地原创 SVG 演示。
重点：PDF 第 5–7 页预测与效果去重；第 8–10 页目标显示；第 10–13 页命中补偿。PDF 从 GameDevs 镜像下载，内容与 Valve 文章交叉核对。
重点：优先级累积、抖动缓冲、速度状态、模拟纠正与视觉平滑。属于工程文章。
重点：快照缓冲、线性/Hermite 插值、丢包与显示延迟。属于工程文章。
重点：确定性、状态序列化、无渲染重算、预测上限、逐帧一致性测试。属于开发指南；归档日期 2026-09-10。
重点：§3 背景与影响，§4 分类与方法。期刊 54(11s)，Article 243。
重点：§III–IV 方法与模型，§V 真人实验，§VI 局限。DOI 10.1109/GEM61861.2024.10585519。
重点：§3–4 RBF 与变点检测；§5 预测评估；§6 SPG 调度实验。264:111235；2025-04-10 在线发表。
重点：§3 模型前提，§4.2 语义距离，§5 约束与延迟攻击。LIPIcs 361，11:1–11:17；出版页面日期 2026-01-07，会议名称保留 2025。
原始文件保留各自版权与许可，下载供个人研究使用。图解、类比和动画为本文重新设计；没有将论文图表中的趋势臆造为精确数据。完整下载来源、文件大小与 SHA-256 见 文件清单，方法与核对记录见 阅读笔记。