帧同步
核心原理
- 同步内容：客户端仅同步玩家的操作输入，而非游戏状态本身
- 运行逻辑：客户端基于相同初始状态和输入序列，通过一致的逻辑计算得到相同的游戏状态
- 关键机制：依赖“锁补”（Lockstep）技术，即所有客户端按固定帧率推进，必须等待其他玩家的输入到达后才执行下一帧逻辑
技术特点
- 确定性模拟：必须保证所有客户端的逻辑、随机数、浮点运算等完全一致，避免因计算差异导致状态不同步。
- 数据量小：每帧仅传输操作指令（如 “玩家 A 按下攻击键”），带宽占用低，适合大规模单位对战（如 MOBA、RTS）。
- 延迟敏感：高延迟会导致所有客户端等待，造成卡顿。通常需要结合预测和回滚（如 GGPO 算法）优化体验。
- 断线重连：需记录完整的输入历史，新客户端加入时重放所有操作以恢复当前状态。
适用场景
- 强调即时操作和精确同步的游戏：如《英雄联盟》（MOBA）、《星际争霸》（RTS）、《街霸》（格斗游戏）。
- 单位数量多但逻辑简单的场景，如大量小兵对战的游戏。
优缺点
- 优点：
- 带宽占用低，适合移动网络。
- 客户端计算压力分散，适合大规模单位同步。
- 天然支持录像和回放（仅需记录输入序列）。
- 缺点：
- 开发难度高：需严格保证逻辑的确定性，避免浮点数误差、随机数差异等。
- 高延迟影响所有玩家，需额外优化（如预测回滚）。
- 反作弊困难：客户端可篡改本地逻辑，需额外校验机制。
状态同步
核心原理
- 同步内容：服务器作为权威状态源，直接向客户端同步游戏对象的完整状态（如位置、血量、速度等）。
- 运行逻辑：客户端仅负责渲染和表现，核心逻辑（如伤害计算、碰撞检测）由服务器执行并下发结果。
技术特点
- 服务器权威：客户端仅显示状态，无法修改核心逻辑，外挂难以篡改关键数据。
- 数据量大：需频繁同步对象状态变化，尤其是高频更新的游戏（如 FPS 中玩家位置）。
- 容错性高：客户端丢包可通过后续状态更新自动纠正，短暂不一致可通过插值平滑过渡。
- 延迟补偿：客户端可预测移动并插值渲染，服务器可通过延迟补偿算法（如《CS:GO》的 Lag Compensation）减少延迟影响。
适用场景
- 强调复杂状态和服务器控制的游戏：如《魔兽世界》（MMORPG）、《绝地求生》（FPS）、《原神》（开放世界 RPG）。
- 需要严格反作弊或逻辑复杂的场景，如经济系统、技能判定等。
优缺点
- 优点：
- 开发相对简单：客户端无需处理复杂逻辑，只需表现状态。
- 反作弊能力强：关键逻辑在服务器运行，客户端无法篡改。
- 容错性高：短暂网络波动可通过后续状态更新修复。
- 缺点：
- 带宽占用高：需频繁同步大量状态数据，可能限制玩家数量或单位规模。
- 服务器压力大：所有逻辑由服务器处理，可能成为性能瓶颈。
- 断线恢复复杂：需传输完整快照或增量状态，可能增加延迟。
核心区别对比
| 维度 | 帧同步 | 状态同步 |
|---|---|---|
| 同步内容 | 操作输入（如按键指令） | 游戏对象状态（如位置、血量） |
| 计算位置 | 客户端本地计算 | 服务器计算后下发结果 |
| 带宽消耗 | 低（传输指令） | 高（传输状态） |
| 延迟敏感性 | 高（需等待所有玩家输入） | 较低（可预测和插值） |
| 开发难度 | 高（需保证逻辑完全确定性） | 较低（客户端仅处理表现） |
| 反作弊能力 | 弱（客户端可篡改逻辑） | 强（逻辑在服务器运行） |
| 适用场景 | MOBA、RTS、格斗游戏 | MMO、FPS、开放世界游戏 |
总结
- 选择帧同步：若需低带宽、大规模单位同步，且能接受高开发成本和延迟优化挑战。
- 选择状态同步：若需严格反作弊、复杂逻辑控制，且能承担更高的服务器和带宽成本。