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

网络同步有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架构不适合反外挂,如果引入战斗服务器来校验各个客户端结果,可以解决常见外挂,但是透视和全图视野防不了。 与服务器加入校验机制,可以起到比较好的反外挂效果。但是一样防不了透视外挂。
中途加入和断线重连 比较复杂。可以在断线的时候,通过快捷播放服务器同步的帧数据来快速跟上游戏。 容易。由于实时记录了各个对象的状态信息,所以重连的时候,直接创建这些对象,并同步信息即可。
性能(客户端) 客户端要跑完整逻辑,还要执行渲染逻辑,开销比较大。 可以灵活优化,客户端跑较少逻辑。
回放(离线) 本身收集了所有玩家的输入信息进行逻辑推进,天然支持回放,且回放文件比较小。 可以支持回放,但是逻辑比较复杂,需要不断记录状态信息,同时回放时候需要读取合适的时间。回放文件大。
回放(实时) 比较复杂,客户端需要本地对全场状态进行序列化,才能回到目标时间。播完回放后还需要加速追上实时游戏状态。 相对容易,可以方便的记录快照信息,并按照录制内容随时播放。

你可能感兴趣的:(游戏开发—网络编程,网络)