从《王者荣耀》看网络游戏的同步问题

96
ookcode
0.3 2017.09.08 19:47* 字数 1648

随着王者荣耀的成功,越来越多的游戏厂商开始关注网络游戏的同步问题。
本文主要介绍常用的两种同步方式,即状态同步和帧同步,以及在帧同步在王者荣耀中的应用。

状态同步

MMORPG回合制游戏常用的同步方式。
  顾名思义,是一种同步玩家状态的方式。角色行为、战斗逻辑等计算均在服务端进行,服务端将状态(计算结果)推给各客户端,客户端只需根据服务端发过来的状态来刷新显示。

延迟特点

  高延迟的情况下会出现瞬移,回位等情况,参照梦幻西游(Ps:当初火爆的时候基本走两步退一步)

延迟处理

  对于一般的卡牌游戏,基本无需做延迟处理。例如炉石传说,一个回合时间很长,能容忍非常高的延迟,对战双方无需高度同步,只要最后的结果一致即可。

  对于MMORPG而言,需要对延迟做一些处理,例如玩家行走,客户端按照自身逻辑指定速度行走,服务端定时同步状态,根据差异来动态调整速度,平滑行走动画,此处可参照:导航推测(Dead Reckoning)算法

优点

  安全,服务端同步状态,能有效的防止外挂。

缺点

  单位越多同步的数据量越大,RST游戏动则上百个单位(因此不适合于RST游戏。
  网络延迟处理比较麻烦,需要客户端与服务端不断调整来达到较好的效果。

帧同步

MOBARTS游戏常用的同步方式
  帧同步所有计算和逻辑均在客户端进行,不同步状态,只同步操作指令
  帧同步的帧,并不是指游戏渲染帧率,而是指服务器定义的一个固定时间间隔,服务器收集所有客户端发来的指令,每个固定时间(如100ms)执行派发。客户端收到服务器发来的指令,按顺序执行。

延迟特点

  高延迟的情况下战斗会停止,恢复后逻辑快速执行赶上进度,参照王者荣耀

延迟处理

  如果在某一个帧客户端没有收到服务端的包,就会导致客户端无指令可执行,那么逻辑层就暂停下来了(UI层可以做预测)。等到网络正常时,一次性收到多个帧的包,快速执行这些帧来赶上进度。

  如果服务端收到一个非当前帧的包时,设定一个timeout,如果是多久之前的包则忽略,即默认该玩家什么都没干,或者塞入之后的队列,下一帧派发,即仅仅是该玩家的操作卡顿(延迟)了。

优点

  由于只同步操作,数据量不受游戏内单位多少的影响。
  天生自带战斗回放,服务端只需把开局所有操作记录下来就行。

缺点

  由于计算在客户端,较难防外挂,特别是全图外挂。
  调试难度大,某一帧不同步之后会产生蝴蝶效应毁掉整场战斗。

王者荣耀中的帧同步

  上面关于帧同步的介绍仅仅只是一个最基本的过程,事实上要做的事情还有很多。

降低延迟

  像王者荣耀这样需要快速反应的即时对战游戏,延迟是非常难以忍受的,像TCP这种三次握手的协议,在网络正常的情况下,一个空包的来回少说也要50 ~ 100ms,在移动网络下就更久了。
  所以王者荣耀采用了UDP协议。

TCP UDP
协议 面向连接,三次握手 无连接协议
可靠性 可靠,有序 不可靠,无序
速度

  使用UDP随之而来的问题是不可靠和无序,这是一个老生常谈的问题,大体上是每个发送的包带有一个时间戳和编号,在上层将包拼接以及重排序,笔者能力有限,请原谅这里无法详细的给大家介绍。

断线重连

  如果需要实现断线重连的功能,需要服务端下发从游戏开局到当前的所有包,客户端快速运行这些指令来达到和当前其他客户端状态的同步。

同步问题

  采用统一的随机种子,保证所有客户端的随机操作都能得到同样的值。
  禁止使用浮点数,不同平台间浮点数计算一定有差异,即使同一平台也可能因为编辑器或者编译参数不同而导致差异,这个差异会在帧同步期间被不断的放大从而导致不可挽回的错误。
  开发时需要将显示和逻辑层分离,最好可以让逻辑部分与服务端公用。

防作弊

  帧同步的作弊是一个非常严峻的问题,因为所有操作都在客户端进行,如果一个客户端声称自己击杀了大龙,消息被发送给了服务端,此时就需要服务端有个判断功能,也就是服务端要充当裁判,较好的做法是同时在服务端也运行一个游戏逻辑(也就是上面提到的最好有一份客户端与服务端公用的逻辑),从而对客户端发过来的指令做出判断。
  对于不影响消息包的外挂,如开全图外挂,这个笔者尚未想到较好的方式,难道判定玩家选中或操作了一个迷雾中的单位就判定为作弊么。欢迎各位大佬指教。


原创文章,仅发布于我的简书我的博客中,禁止转载!

游戏开发
Web note ad 1