多人在线游戏最难的事情之一，是让所有玩家看到“同一个世界”。

网络存在延迟、抖动、丢包和断线。假如四个玩家同时操作，服务端和每个客户端收到这些操作的时间都不同；如果没有同步机制，甲看到的牌已经打出，乙的画面里却还没摸牌，最终每个人都会进入不同的游戏状态。

解决这个问题的主流方案有两类：状态同步与帧同步。

一、状态同步：服务端告诉你“现在世界是什么样”

状态同步的核心思想是：

服务端维护唯一正确的游戏状态，并把状态变化或状态快照同步给客户端。

客户端更多是负责展示，以及在有限范围内做本地交互预测。

玩家操作 → 发送给服务端 → 服务端校验并执行规则 → 服务端广播状态变化 → 各客户端更新画面

以麻将为例，服务端是唯一可信裁判。玩家点击出牌后，客户端把“我想打这张牌”发送出去；服务端检查是否轮到该玩家、这张牌是否存在、是否受立直或振听限制；通过后，服务端更新牌局并广播“某玩家打出了某张牌”。

客户端收到后才正式把手牌移入河牌、更新剩余时间、显示相关特效。

状态同步的常见形式

1. 全量快照

服务端定期发送完整世界状态，例如：

第几局、谁是庄家、各家分数 所有公开牌、副露、宝牌、剩余牌数 当前行动者、倒计时、可执行操作

优点是简单可靠，特别适合断线重连：客户端拿到快照后可以直接恢复。

缺点是数据量大。如果高频同步角色位置、子弹、物理对象，全量快照会造成明显带宽压力。

2. 增量状态

服务端只发送变化的部分，例如：

玩家 A 摸牌 玩家 B 打牌 玩家 C 立直 宝牌翻开 当前行动者切换

优点是带宽更小，表现更及时。

缺点是客户端必须严格按顺序处理事件；如果中间丢失一条消息，状态可能逐渐偏离，通常需要定期快照校正。

3. 快照加增量事件

这是大多数在线游戏较实用的方案：

初始快照 + 连续增量事件 + 定期校验快照 + 断线后重新拉取快照

麻将、卡牌、回合制战棋、RPG 战斗等规则明确且服务端权威的游戏，通常很适合这种模式。

二、帧同步：服务端告诉你“每一帧大家输入了什么”

帧同步的核心思想是：

服务端不直接同步世界结果，而是收集所有玩家输入，并让所有客户端在相同帧序下执行同一份逻辑。

玩家输入 → 上传服务端 → 服务端按帧收集输入 → 广播“第 N 帧所有玩家输入” → 所有客户端执行第 N 帧逻辑

例如一款实时对战游戏中，第 120 帧收到：

玩家 A：向右移动 玩家 B：释放技能 2 玩家 C：停止移动 玩家 D：无操作

所有客户端都在自己的第 120 帧执行完全相同的规则。只要初始状态相同、输入顺序相同、逻辑计算完全确定，最终世界状态就会一致。

服务端更像“输入排序器”和“裁判”，而不一定需要每帧计算整个游戏世界。

帧同步的关键前提：确定性

帧同步要求各客户端执行后得到同样结果，因此游戏逻辑必须足够确定。

以下内容必须尽量避免或统一：

• 浮点数计算差异；
• 不同平台的随机数实现；
• 物理引擎结果不一致；
• 依赖本地时间；
• 遍历无序容器；
• 异步回调触发顺序不同；
• 不稳定的对象创建和销毁顺序。

常见处理方式包括：

• 使用整数、定点数代替关键浮点计算；
• 使用固定随机种子；
• 固定逻辑帧率，例如每秒 20、30 或 60 帧；
• 保证对象遍历顺序固定；
• 让随机、寻路、碰撞、伤害等逻辑完全由统一规则决定。

如果确定性被破坏，一开始可能只差一个很小的位置误差，几百帧后却可能演变为完全不同的战局。

三、状态同步与帧同步的核心区别

一句话概括：

• 状态同步同步的是“结果”。
• 帧同步同步的是“过程中的输入”。

四、延迟问题：为什么帧同步需要预测

如果严格等待服务端下发每一帧输入，游戏手感会很差。

假设网络延迟为 100 毫秒，逻辑帧率是每秒 30 帧。玩家按下移动键后，如果必须等待服务器确认再执行，至少要等 3 帧左右才能动起来，操作会明显滞后。

因此帧同步通常会引入本地预测。

玩家按下移动 → 客户端立即预测执行 → 同时把输入发给服务端 → 服务端收集并广播权威输入帧 → 客户端收到后进行确认或修正

玩家自己的操作先在本地生效，画面立即响应；之后再由服务端广播的权威输入确认。

这就是预测。

预测并不意味着客户端拥有最终裁决权。它只是为了改善手感。最终仍应以服务端确认的输入帧、规则校验或权威状态为准。

五、什么是回滚

预测带来一个问题：客户端可能提前执行了一个后来被否定的操作。

例如：

1. 玩家本地预测第 100 帧释放技能。
2. 客户端立即播放动作、计算命中。
3. 服务端收到请求后发现：该技能仍在冷却，或者玩家在第 99 帧已经被控制。
4. 服务端下发的权威第 100 帧中，没有这次技能输入。

此时客户端已经“走错了未来”，就需要回滚。

回滚的基本流程：

保存历史状态 → 本地预测执行未来帧 → 收到较早的权威输入或权威状态 → 回到对应历史帧 → 应用权威数据 → 重新模拟后续各帧

举例：

本地已经模拟到第 110 帧 服务端确认第 100 帧存在差异 回滚到第 99 帧 → 应用服务端确认的第 100 帧输入 → 重新计算第 100 到第 110 帧 → 得到修正后的当前状态

回滚并不是把画面瞬间倒放。逻辑状态会回退并重新计算，表现层通常会通过平滑修正来避免角色突然跳动。

回滚需要保存什么

为了能够回到过去，客户端需要保留一个有限窗口内的历史数据：

• 每个逻辑帧的完整或可恢复状态；
• 每个逻辑帧收到的权威输入；
• 本地预测输入；
• 随机数状态；
• 必要的对象生命周期信息。

例如保留最近 1 到 3 秒的帧历史。若逻辑帧率是每秒 30 帧，则要缓存 30 到 90 帧的数据。

窗口过小，网络抖动时可能无法回滚到足够早的位置；窗口过大，内存和重算成本会增高。

六、预测与回滚的典型组合

实时竞技游戏中常见模式如下：

客户端： 立即执行本地输入 保存每帧历史状态 上传输入 服务端： 校验输入 组织权威帧 广播所有玩家输入或权威结果 客户端收到权威帧： 若与预测一致，继续运行 若不一致，回滚并重新模拟

其中有三种常见策略。

1. 输入延迟

所有人都延迟若干帧执行输入，等大多数网络消息到齐后再模拟。

优点是简单，回滚少。

缺点是操作有固定延迟，网络差时体验明显下降。

2. 预测加回滚

客户端先执行，后校正。

优点是手感好，适合格斗、动作、射击等强操作游戏。

缺点是实现复杂，需要严格确定性和历史状态管理。

3. 混合方案

常见于商业游戏：

• 对自己角色使用预测；
• 对其他玩家使用插值或有限预测；
• 对关键规则使用服务端确认；
• 对位置、动画等表现进行平滑修正；
• 对资源、伤害、胜负等结果保持服务端权威。

七、帧同步中的随机数与确定性

随机数是帧同步最容易踩坑的部分之一。

如果每台设备随意调用本地随机数，即使输入完全一致，也可能在某一帧抽到不同结果，随后整个战局都会分叉。

正确做法通常是：

对局开始时确定随机种子 → 每个客户端使用同一种伪随机算法 → 在完全一致的调用顺序下取随机数 → 所有人得到同样结果

但仅仅统一种子还不够。调用次数也必须一致。假如某个客户端因一个分支条件不同，多调用了一次随机数，之后所有随机结果都会错位。

因此，帧同步项目中应避免让表现层、异步逻辑或平台差异影响核心随机数调用。

八、麻将更适合哪种同步方案

麻将通常更适合状态同步，而不是完整帧同步。

原因是：

• 麻将是离散操作和回合推进，不是高频移动；
• 规则校验强，服务端必须防作弊；
• 存在隐藏信息，不能把完整状态或随机过程交给所有客户端；
• 断线重连天然适合用服务端快照恢复；
• 玩家对几十毫秒级本地响应的要求远低于格斗或射击游戏。

麻将中可以借鉴帧同步的思想，例如：

• 为每条事件提供严格递增的顺序号；
• 客户端按顺序消费事件；
• 重连后从快照序号继续接收事件；
• 回放按同一事件序列重建状态；
• 对牌桌表现使用本地队列，确保动画不因网络抖动乱序。

但不建议把牌局规则完全交给客户端同时计算。尤其牌山、手牌和隐藏信息应始终由服务端权威维护。

九、如何选择同步方案

可以根据游戏特征判断。

适合状态同步的情况：

• 回合制、卡牌、麻将、棋类；
• 规则复杂且强防作弊；
• 隐藏信息较多；
• 可接受服务端权威带来的少量操作延迟；
• 需要稳定的断线恢复和跨端一致性。

适合帧同步的情况：

• 实时操作强；
• 单位或对象数量多；
• 输入数据远小于状态数据；
• 希望降低服务端模拟压力；
• 可以投入成本保证确定性；
• 可以接受预测、回滚和反作弊体系的复杂度。

十、总结

状态同步和帧同步没有绝对优劣，核心差异在于“同步结果”还是“同步输入”。

状态同步强调服务端权威、规则安全和恢复简单；帧同步强调统一模拟、低带宽和实时手感。

预测解决“等待服务端太慢”的问题：先让客户端快速响应。回滚解决“预测可能出错”的问题：收到权威结果后回到过去，重新推演未来。

对于实时竞技游戏，预测与回滚往往是帧同步体验的关键；对于麻将等强规则、隐藏信息、多断线恢复需求的游戏，状态同步加快照、事件序列和严格版本控制，通常是更稳妥的工程选择。