随着王者荣耀的成功,越来越多的游戏厂商开始关注网络游戏的同步问题。
本文主要介绍常用的两种同步方式,即状态同步和帧同步,以及在帧同步在王者荣耀中的应用。
状态同步
MMORPG、回合制游戏常用的同步方式。
顾名思义,是一种同步玩家状态的方式。角色行为、战斗逻辑等计算均在服务端进行,服务端将状态(计算结果)推给各客户端,客户端只需根据服务端发过来的状态来刷新显示。
延迟特点
高延迟的情况下会出现瞬移,回位等情况,参照梦幻西游(Ps:当初火爆的时候基本走两步退一步)
延迟处理
对于一般的卡牌游戏,基本无需做延迟处理。例如炉石传说,一个回合时间很长,能容忍非常高的延迟,对战双方无需高度同步,只要最后的结果一致即可。
对于MMORPG而言,需要对延迟做一些处理,例如玩家行走,客户端按照自身逻辑指定速度行走,服务端定时同步状态,根据差异来动态调整速度,平滑行走动画,此处可参照:导航推测(Dead Reckoning)算法。
优点
安全,服务端同步状态,能有效的防止外挂。
缺点
单位越多同步的数据量越大,RST游戏动则上百个单位(因此不适合于RST游戏。
网络延迟处理比较麻烦,需要客户端与服务端不断调整来达到较好的效果。
帧同步
MOBA、RTS游戏常用的同步方式
帧同步所有计算和逻辑均在客户端进行,不同步状态,只同步操作指令。
帧同步的帧,并不是指游戏渲染帧率,而是指服务器定义的一个固定时间间隔,服务器收集所有客户端发来的指令,每个固定时间(如100ms)执行派发。客户端收到服务器发来的指令,按顺序执行。
延迟特点
高延迟的情况下战斗会停止,恢复后逻辑快速执行赶上进度,参照王者荣耀
延迟处理
如果在某一个帧客户端没有收到服务端的包,就会导致客户端无指令可执行,那么逻辑层就暂停下来了(UI层可以做预测)。等到网络正常时,一次性收到多个帧的包,快速执行这些帧来赶上进度。
如果服务端收到一个非当前帧的包时,设定一个timeout,如果是多久之前的包则忽略,即默认该玩家什么都没干,或者塞入之后的队列,下一帧派发,即仅仅是该玩家的操作卡顿(延迟)了。
优点
由于只同步操作,数据量不受游戏内单位多少的影响。
天生自带战斗回放,服务端只需把开局所有操作记录下来就行。
缺点
由于计算在客户端,较难防外挂,特别是全图外挂。
调试难度大,某一帧不同步之后会产生蝴蝶效应毁掉整场战斗。
王者荣耀中的帧同步
上面关于帧同步的介绍仅仅只是一个最基本的过程,事实上要做的事情还有很多。
降低延迟
像王者荣耀这样需要快速反应的即时对战游戏,延迟是非常难以忍受的,像TCP这种三次握手的协议,在网络正常的情况下,一个空包的来回少说也要50 ~ 100ms,在移动网络下就更久了。
所以王者荣耀采用了UDP协议。
TCP | UDP | |
---|---|---|
协议 | 面向连接,三次握手 | 无连接协议 |
可靠性 | 可靠,有序 | 不可靠,无序 |
速度 | 慢 | 快 |
使用UDP随之而来的问题是不可靠和无序,这是一个老生常谈的问题,大体上是每个发送的包带有一个时间戳和编号,在上层将包拼接以及重排序,笔者能力有限,请原谅这里无法详细的给大家介绍。
断线重连
如果需要实现断线重连的功能,需要服务端下发从游戏开局到当前的所有包,客户端快速运行这些指令来达到和当前其他客户端状态的同步。
同步问题
采用统一的随机种子,保证所有客户端的随机操作都能得到同样的值。
禁止使用浮点数,不同平台间浮点数计算一定有差异,即使同一平台也可能因为编辑器或者编译参数不同而导致差异,这个差异会在帧同步期间被不断的放大从而导致不可挽回的错误。
开发时需要将显示和逻辑层分离,最好可以让逻辑部分与服务端公用。
防作弊
帧同步的作弊是一个非常严峻的问题,因为所有操作都在客户端进行,如果一个客户端声称自己击杀了大龙,消息被发送给了服务端,此时就需要服务端有个判断功能,也就是服务端要充当裁判,较好的做法是同时在服务端也运行一个游戏逻辑(也就是上面提到的最好有一份客户端与服务端公用的逻辑),从而对客户端发过来的指令做出判断。
对于不影响消息包的外挂,如开全图外挂,这个笔者尚未想到较好的方式,难道判定玩家选中或操作了一个迷雾中的单位就判定为作弊么。欢迎各位大佬指教。
网友评论