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

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

状态同步

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

延迟特点

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

延迟处理

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

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

优点

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

缺点

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

帧同步

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

延迟特点

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

延迟处理

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

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

优点

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

缺点

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

王者荣耀中的帧同步

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

降低延迟

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

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

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

断线重连

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

同步问题

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

防作弊

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

---

原创文章，仅发布于我的与我的博客中，禁止转载!