状态同步梳理
MMO 状态同步
后端场景主循环 30帧/秒，根据客户端输入（可能有），将场景中的变化状态信息，广播给场景内客户端（也可以是 AOI 内）
FPS 状态同步
首先需要明确 FPS 游戏为啥会选择状态同步而不是帧同步：
- FPS 玩法人数规模在小于 100 人，而帧同步一般小于 10 人。所以没法用帧同步
其次，FPS 人数又远小于 MMO ，帧同步游戏技术的一些特性就可以拿来用了
MMO 、 FPS 、 MOBA 区别
| 游戏类型 | cmd 发送时机 | 后端下发时间 | 后端下发内容 | 战斗代码所属 | 是否有帧号 | 算法一致性要求 |
|---|---|---|---|---|---|---|
| MMO | 玩家操作时 | 场景游戏对象状态有变化时 | 场景游戏对象状态 | 后端 | 无 | 无 |
| FPS | 玩家操作时 | 收到 cmd 时、场景游戏对象状态有变化时 | 该帧 cmd 集合、场景游戏对象状态 | 前后端 | 有 | 有 |
| MOBA | 每帧发送 | 每帧下发 | 该帧 cmd 集合 | 前后端 | 有 | 有 |
可以看到 FPS 正好相对奇葩，介于 MMO 与 MOBA 之间。因此也具备以下独特功能：
- 前端有战斗代码，因此自己也可以先算（官方术语叫预测先行）
- 后端也有战斗代码，且后端只认自己算的（官方术语叫服务器仲裁）
- 前端接收到后端发下的第 N 帧，把场景游戏对象状态作用于第 N -1 帧快照后，发现和自己算的结果不一致，需要把 N-1 帧用后端的第 N 帧 cmd 重新算（官方术语叫回滚）
- 后端在时延，不一定把当前帧 cmd 用最新的场景游戏对象状态下算（官方术语叫延迟补偿）
基于 FPS 技术的单人本状态同步
一般的用 MMO 方式的状态同步即可
但是假如，项目有 FPS 技术基础，单人本状态同步的流畅性就可以发挥到极致了
即使网络时延几秒（甚至更长），玩家也可以有流畅的体验
原因如下：
- 前端可以预测先行
- 后端仲裁必定与前端一致
- 前端没有回滚的机会。（因此后端可以省去下发网络流量）
- 后端不需要延迟补偿功能
玩法发现卡顿的时机：
- 杀了很多怪，没掉落时
- 重进当前单人本，发现不少怪还在没死时
- 切副本转菊花
这种方式的状态同步优点：
- 流量更少，前端只要上次玩家操作时的 cmd 。后端不需要下发场景游戏对象状态
- 极致弱网体验，可以是秒级别、乃至分级别
- 强校验，这就区别于帧同步单人无法检验的尴尬问题了
缺点：
- 存在掉落延迟体验
- 存在副本推进进度丢失体验
基于 FPS 技术的多人本大乱斗状态同步
一般都用 MMO 状态同步方式，但是如果已经是 FPS 技术栈了呢
首先，延迟补偿应该不需要，这是射击类独有的处理
预测先行、回滚待考察，先假设也关闭
那么就退化为 MMO 同步方式了
如果开启，这个需要实践，按范围攻击，带来的回滚概率是否符合预期
这种方式的状态同步优点：
- 战斗代码前端直接按单人本方式维护，开发效率提高
缺点：
- 增加算法一致性的包袱