游戏帧同步和状态同步

        在网络游戏中，服务器和客户端的同步技术是一个绕不开的话题，也是在技术选型时，首先需要确定的方案。网游中的同步技术主要有两个技术方向，帧同步和状态同步。本文简单讨论了帧同步和状态同步，整理并对比了他们的优缺点。

一．帧同步和状态同步的介绍

        帧同步：同步的是各个客户端的操作。一般的流程是客户端上传操作到服务器， 服务器收到后并不计算游戏行为，而是负责转发客户端的操作，每个客户端在固定的逻辑帧执行该帧所有客户端的操作命令，通过在严格一致的时间轴上执行同样的命令序列得到同样的结果。这里最重要的概念就是：相同的输入 + 相同的时机 = 相同的输出。

        帧同步实现成本相对较低，开发比较快速，服务器性能和带宽开销很低，有点去中心化的意思。帧同步多用于游戏单位比较多的及时策略游戏，比如有很多个子弹的飞机类游戏、塔防类游戏等。

        帧同步的流程

        1.同步随机种子：游戏中设计随机数的使用，通过同步随机数种子可以保持随机数的一致性

        2.客户端上传操作指令给服务器，操作指令包含游戏操作和当前帧索引

        3.服务器广播所有客户端的操作，如果没有操作也要广播空指令来驱动游戏帧前进

        状态同步：同步的是游戏中的各种状态。一般的流程是客户端上传操作到服务器，服务器收到后计算游戏行为的结果，然后以广播的方式下发游戏中各种状态，客户端收到状态后再根据状态显示内容。

        状态同步其实是一种不严谨的同步。它的思想中，不同玩家屏幕上的表现的一致性并不是重要指标， 只要每次操作的结果相同即可。所以状态同步对网络延迟的要求并不高。状态同步最广泛的应用应该是在回合制游戏中。

        状态同步的流程：

        1.客户端上传操作到服务器

        2.服务器收到后计算游戏行为的结果（如技能逻辑、战斗计算等）

        3.服务器以广播的方式下发游戏中各种状态

        4.客户端收到状态后更新本地状态（如动作状态、Buff状态、位置等）

二．帧同步和状态同步的对比

使用场景

        帧同步：游戏单位比较多的及时策略游戏，比如有很多个子弹的飞机类游戏、塔防类游戏。

        状态同步：玩家比较多的大型MMOARPG游戏，所有游戏内容服务器控制，安全性高。

流量

        状态同步比帧同步流量消耗大，例如一个复杂游戏的英雄属性可能有100多条，每次改变都要同步一次属性，这个消耗是巨大的，而帧同步不需要同步属性；例如释放一个技能，服务端需要通知客户端很多条消息（必须是分步的，不然功能做不了），而帧同步就只需要转发一次操作就行了。

战斗回放

        帧同步的回放比状态同步好做得多，因为只需要保存每局所有人的操作就好了，而状态同步的回放，需要有一个回放&观战服务器，当一局战斗打响，战斗服务器在给客户端发送消息的同时，还需要把这些消息发给回放服务器，回放服务器做储存，如果有其他客户端请求回放，则回放服务器把储存起来的消息按时间发给客户端。

安全性

        状态同步的安全性比帧同步高很多，因为状态同步的所有逻辑和数值都是在服务端的，如果想作弊，就必须攻击服务器，而攻击服务器的难度比更改自己客户端数据的难度高得多，而且更容易被追踪，被追踪到了还会有极高的法律风险。而帧同步因为所有数据全部在客户端，所以解析客户端的数据之后，就可以轻松达到自己想要的效果，例如moba类游戏的全图挂，吃鸡游戏的透视挂，都是没办法防止的，而更改数据达到胜利的作弊方式（例如更改自己的英雄攻击力）可以通过服务器比对同局其他人的战斗结果来预防。

服务器压力

        显而易见，状态同步服务器压力要大很多。在状态同步的技术方案下，几乎所有的运算，都是放在服务器完成的。

总结一下：

帧同步

优点:

1.只接收和发送动作消息, 流量小

2.即时性好, 动作判定在本地

3.服务端只转发, 相对而言工作量小很多

缺点:

1.恶意攻击难防, 比如劫持攻击消息, 将攻击力加大十倍

2.客户端的性能需要能够处理大量数据

3.断线重连时需要计算此时刻前所有动作的最终状态

4.各个客户端的计算需要保证结果一致

状态同步

优点：

1.断线重连简单, 直接恢复状态

2.恶意攻击需要攻击服务器

3.客户端只展示状态和生产动作, 相对而言性能要求不是很高

4.客户端逻辑比较简单, 发动作, 同步状态

缺点：

1.流量消耗大, 因为接受的是全局状态

2.反馈比较看网络状态, 因为需要等待服务器发送反馈状态

3.服务端性能要求较高, 因为每一个动作, 都可能会在全局修改一些状态, 服务端需要将所有动作的影响计算出来