网络同步(帧同步和状态同步)

网络同步有3种：帧同步、状态同步、实时广播同步，开发过程中可以混合使用。

网络同步的目标就是时刻保证多台机器的游戏表现完全一致。

网络同步 = 实时的多端数据同步 + 实时的多端表现同步

一、帧同步

帧同步适用于对网络延迟要求较高的游戏，例如：FPS游戏(射击游戏)、RTS游戏(即时战略游戏)。

1.原理

 让每个客户端在相同的时刻发送游戏数据到服务端，服务端广播分发所有客户端的数据，然后客户端根据服务端发来的数据做出相应的逻辑处理，保证每个客户端在同一时刻所有的数据都是一致同步的。帧同步最大的特点是游戏逻辑在客户端中处理。

核心思想: 相同的输入＋相同的时机 = 相同的表现

2.流程

（1）同步随机数种子(一般游戏中都设计随机数的使用，通过同步随机数种子，可以保持随机数一致性)。

（2）客户端上传当前逻辑帧的操作(帧索引+游戏操作)。

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

 3.优点

• 单次同步数据很小，传输速率快，因为数据的逻辑处理主要是在客户端，服务器只起到分发同步的作用。
• 服务端压力小，因为数据的逻辑处理主要是在客户端。
• 更容易实现回放和观战功能，因为是帧同步，每一个时刻的帧序列都有记录，可以很好的还原游戏过程。
• 开发效率高，可以部分当作单机游戏来开发。
• 流量消耗小，因为传输的数据量更少。大部分逻辑处理都在客户端处理好了。
• 游戏精准度更高，能呈现出更好的打击感、音效、特效等反馈。

4.缺陷

• 由于帧同步战斗逻辑都在客户端，服务器没有验证，带来的问题就是外挂的产生(加速、透视、自动瞄准、数据修改等)。
• 网络条件较差的客户端会影响其他玩家的游戏体验。(优化方案：乐观帧锁定、渲染与逻辑帧分离、客户端预执行、指令流水线化、操作回滚等)。
• 不同机器浮点数精度问题、容器排序不确定性、RPC时序、随机数值计算不统一。
• 断线重连难度很大，因为一旦掉线，本地数据丢失了，需要从服务器逐帧来读取游戏进度，直到与当前游戏进度一致。如果直接从当前游戏进度开始进行同步，很容易会出现数据错误。

二、状态同步

 状态同步适用于对网络延迟要求不高的游戏，例如：RPG游戏(角色扮演游戏)、回合制游戏。

 1.原理

客户端将数据发送到服务端，服务端根据每个客户端发来的数据做出处理，再将处理完的数据广播发送到所有客户端，客户端根据数据进行数据表现。状态同步最大的特点是游戏逻辑在服务端中处理。

2.流程

（1）客户端上传操作到服务器。

（2）服务器收到后计算游戏行为的结果，然后以广播的方式下发游戏中各种状态。

（3）客户端收到状态后再根据状态显示内容。

3.优点

• 反外挂能力强，因为大部分数据处理都是在服务端。
• 网络要求不高。
• 玩家可以随时加入到一个开始的战局，只需要同步当前战局内的所有玩家当前的状态即可。

4.缺点

• 状态同步做回放和观战系统困难。
• 延迟过大、客户端性能浪费、服务端压力大。
• 对带宽的浪费。对于对象少的游戏，可以用快照保存整个游戏的状态发送，但一旦数量多起来，数量的占用就会直线上升。(优化：增量快照同步，协议同步指定数据)
• 传输数据大，传输速度慢。因为客户端会将大量数据传输给服务端，再由服务端进行逻辑处理，再分发给所有客户端。

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

1. 最大的区别就是战斗核心逻辑的位置，帧同步的战斗逻辑在客户端，状态同步的战斗逻辑在服务端。
2. 状态同步比帧同步流量消耗大，例如一个复杂游戏的英雄属性可能有100多条，每次改变都要同步一次属性，这个消耗是巨大的，而帧同步不需要同步属性。
3. 帧同步的回放&观战比状态同步好做得多，因为只需要保存每局所有人的操作就好了，而状态同步的回放&观战，需要有一个回放&观战服务器，当一局战斗打响，战斗服务器在给客户端发送消息的同时，还需要把这些消息发给放&观战服务器，回放&观战服务器做储存，如果有其他客户端请求回放或者观战，则回放&观战服务器把储存起来的消息按时间发给客户端。
4. 状态同步的安全性比帧同步高很多，因为状态同步的所有逻辑和数值都是在服务端的，如果想作弊，就必须攻击服务器，而攻击服务器的难度比更改自己客户端数据的难度高得多，而且更容易被追踪，被追踪到了还会有极高的法律风险。而帧同步因为所有数据全部在客户端，所以解析客户端的数据之后，就可以轻松达到自己想要的效果。

同步方式	帧同步	状态同步
确定性	严格确定	允许小误差，定时纠正误差数据
表现与响应速度	传统严格帧锁定要等其他客户端消息全部到达，响应比较慢；乐观帧锁定可以做到本地立刻响应，但是需要回滚的时候，体验就没那么好了。	一般会做预测，可以做到立刻响应。不做预测的话，响应时间是一个往返时间(RTT)
带宽与流量	相对低，王者荣耀采用帧同步，流量30分钟8M。带宽随人数增加而增加，不适合MMO。	相对高，全民超神采用状态同步，流量30分钟20M。需要发送各种状态数据，带宽占用比较高。可以通过压缩、裁剪、增量等方式优化。
网络延迟适应性	要求较低的延迟。如果延迟较高，所有玩家体验都不好。即使采用乐观帧锁定优化，高延迟下也容易产生卡顿。	适应性较高，方便做各种插值优化。当然高延迟下，也容易产生位置突变。
开发难度	初期开发减法，框架容易实现，但是后期解决bug和完善系统很困难。比如浮点数、随机数、执行顺序导致计算结果不一致，问题很难排查。	框架比较复杂，客户端服务端一套代码，每个功能都需要客户端服务端联调。问题定位比较容易。但也会出现时序问题。
玩家数量	适合少量的玩家，比如：ACT、MOBA。	可多可少
跨平台	不适合跨平台，会有浮点数问题，可以用定点数来将误差控制在一个可接受范围，同时可以定时纠正结果。	适合。有权威服务器。
反外挂	P2P架构不适合反外挂，如果引入战斗服务器来校验各个客户端结果，可以解决常见外挂，但是透视和全图视野防不了。	与服务器加入校验机制，可以起到比较好的反外挂效果。但是一样防不了透视外挂。
中途加入和断线重连	比较复杂。可以在断线的时候，通过快捷播放服务器同步的帧数据来快速跟上游戏。	容易。由于实时记录了各个对象的状态信息，所以重连的时候，直接创建这些对象，并同步信息即可。
性能(客户端)	客户端要跑完整逻辑，还要执行渲染逻辑，开销比较大。	可以灵活优化，客户端跑较少逻辑。
回放(离线)	本身收集了所有玩家的输入信息进行逻辑推进，天然支持回放，且回放文件比较小。	可以支持回放，但是逻辑比较复杂，需要不断记录状态信息，同时回放时候需要读取合适的时间。回放文件大。
回放(实时)	比较复杂，客户端需要本地对全场状态进行序列化，才能回到目标时间。播完回放后还需要加速追上实时游戏状态。	相对容易，可以方便的记录快照信息，并按照录制内容随时播放。