【网络通信】帧同步入门：确定性模拟的取舍

实战应用：用在哪里

帧同步是竞技玩法的经典方案：服务器只广播玩家的操作指令，各端用同一套确定性逻辑各自模拟，战斗的流畅度不受网络往返牵制。5v5 竞技场、攻城阵法演练这类强操作玩法，帧同步的取舍值得想清楚再上。

指令广播的骨架

---帧驱动：固定 66ms 一帧，广播指令
local FRAME_MS = 66
function Lockstep.tick()
    local frame = Lockstep.frame + 1
    local cmds = Lockstep.collectInputs()
    -- 把本帧全部指令打包广播
    local pkt = { frame = frame, cmds = cmds }
    Lockstep.broadcast(pkt)
    Lockstep.apply(pkt)
    Lockstep.frame = frame
end

---指令的紧凑编码
function Lockstep.encode(actor, op, x, y)
    -- 指令 8 字节：玩家 2 字节 + 操作 1 字节 + 坐标 2 字节 + 帧 3 字节
    return actor.slotId + op * 256 + x * 1024 + y * 524288
end

服务器以 66 毫秒一帧的节奏收指令、打包、广播，客户端收到帧包后执行本帧指令。指令压缩到 8 字节：竞技场 10 个玩家的满帧广播不到百字节，带宽的占用可以忽略。帧同步的流畅来自客户端本地预演：自己的操作即时生效，服务器的帧包到达后按帧重放校正。

确定性的代价

---确定性红线：禁用浮点与非确定源
local FIXED_ONE = 1000
function Fixed.mul(a, b)
    -- 定点数乘法：(a*b)/1000，全端一致
    return math.floor(a * b / FIXED_ONE + 0.5)
end

---烈火剑法的伤害在帧同步下的结算
function Combat.fireSword(atk, lv)
    return Fixed.mul(atk, 1200 + lv * 150)
end

确定性的红线清单：浮点运算因各端 CPU 的实现差异会分叉，定点数替代；math.random 必须用同帧同种子；遍历 table 的顺序不确定，排序后处理。烈火剑法的伤害公式用定点数实现，任何一端算出的结果逐位一致。断线重连的代价也在此：重连者要拉全量帧历史快进追帧，8 秒的战斗回放压缩到 2 秒内放完，追帧的体验是帧同步方案的隐性成本。

验证与监控

一致性的校验：各端每 100 帧上报状态哈希，哈希不一致立即分叉告警；追帧时长的分位统计，超过 5 秒的追帧优化快进速率。

踩坑记录

浮点的伤害公式在两类手机上算出不同结果，战斗第 400 帧角色位置分叉，全量换定点数后一致。table 的 pairs 遍历顺序曾经决定技能结算顺序，A 端先烧 B 端先冻，战报对不上，结算前按 ID 排序。帧率波动时曾经用真实时间差补帧，破坏了帧的确定性，逻辑帧与渲染帧解耦。

上线要点

帧同步只用于竞技与演练场景，开放世界的 MMO 主流程仍走状态同步，两套方案按场景分治。确定性红线的检查进代码评审清单，新人的第一次分叉 Bug 是最好的教材。帧包的丢包容忍：丢一帧插补，连丢三帧请求重发，弱网的体验有兜底。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。