动作类网游技术难点分析

1 背景

动作类游戏(ACT)在百度百科上的定义是:由玩家所控制的人物根据周围环境的变化,利用键盘或者手柄、鼠标的按键做出一定的动作,如移动、跳跃、攻击、躲避、防守等,来达到游戏要求的相应目标。单机代表作有:《波斯王子》、《鬼泣》、《真三国无双》、《战神》等,而网游代表作有:《DNF》、《龙之谷》、《怪物猎人OL》等。

从技术层面来说,与传统MMORPG不同的是,动作类网游对于操作响应的网络时延要求极高,要保证较好的体验效果的话,一般要求时延小于150ms。如果网络时延较大的话,会带来对战双方(或多方)数据不一致的问题,即所谓的数据同步问题。因此,数据同步问题是动作类网游的首要问题,也是最大的问题。

下面将先描述数据同步问题的具体表现,再尝试分析目前业界常用的解决办法,最后简要讲述公司两个自研项目的实施方案。

2 问题聚焦

下面列举的这些同步问题,也是大部分网络游戏共有的一些典型问题,如果处理不好,又会在动作类网游中进一步放大,从而极大的影响玩家体验。

2.1 位置不同步

比如在T1时间,第三世界的玩家B看第一世界的玩家A在射程内并发起攻击,但此时玩家A正在跑出射程,当服务器收到玩家B的攻击请求,会判断玩家A已经在射程外了,如果服务器拒绝B的攻击,则会让B觉得很困惑,为什么明明在攻击范围内,却攻击不到呢?

 

2.2 动态阻挡

所谓动态阻挡是指角色、怪物和建筑这些实体不可重叠。动态阻挡让玩家感觉更具有真实性,并且在多人PK中,可以利用动态阻挡进行卡位,制造人墙,丰富游戏的玩法。

动态阻挡本身就会有很多碰撞问题,再加上网络延迟,会有各种各样的问题产生。

碰撞情形1:玩家A在P1点请求要去P2点时,玩家B也有可能在P3点请求要到P2点,但最终只能有一个人到P2的位置,如何避免拉扯呢。

 

碰撞情形2:玩家A在P1点请求要去P2点,玩家B在P3点请求要去P4点,路径有交叉,要让他们碰还是不碰呢?

 

 

 

碰撞情形3:玩家A在P1点请求要去P2点,玩家B在P3点要去P4点,这种情形也会有碰撞发生。

 

 

碰撞情形4:玩家A要通过一个只能容纳一个人的关隘,玩家B要阻止玩家A通过,但是由于网络延迟,当A通过时,并没有发现B已经在卡住关隘,服务器是相信A,允许通过呢,还是相信服务器自己,要拖拽A呢?

 

 

碰撞情形5:玩家A要通过城门,但是由于网络延迟,当A通过时,并没有发现城门已经关闭了,服务器是相信A,允许通过呢,还是要拖拽A呢?

2.3 技能事件

考虑冰冻情形,在T1时间,玩家A对玩家B施放冰冻,在T2时间,服务器收到报文,并下发冰冻确认,玩家B在T3时刻才收到自己被冰冻的消息,

如果在T3时间前,B没有收到被冰冻消息,进行移动,而移动报文又在T2时刻到达服务器,如果按照逻辑,服务器拒绝处理B的移动请求,那么就会产生B在第一视角的位置和服务器的位置不一致的现象,就会产生拖拽,如何避免拖拽呢?

 

其他诸如击晕,减速,恐惧,死亡等等,都类似冰冻情形,不再赘述

3解决方案

3.1 帧同步

  • 原理

玩家在发起战斗后,每隔一定时间在玩家的战斗动作序列中设置一个逻辑关键帧,在关键帧这个点,本机必须收到来自所有参与者反馈后才可继续执行其余的动作序列,否则,就进行锁帧、等待。这样就通过频繁对时(即在每一个关键帧节点上对齐),便可以像编写串行单机指令一样来进行多个客户端的事件指令同步了。

如下图所示:

 

  • 优点

简单易实现,不会出现任何的不一致性。在延迟小(< 100ms)且稳定的环境下非常合适。此外,在实时性要求不高的玩法(比如回合制玩法)中也非常合适。

  • 缺点

游戏节奏受最慢的那个玩家客户端影响巨大。一人卡机,所有人受影响。恶意玩家可以用伪造大延迟的方式来获得好处,从而破坏游戏公平性。

 

3.2 客户端承担消耗运算

  • 原理

游戏比较消耗CPU的运算均放在玩家本地客户端执行,如:角色移动物理判定、战斗物理判定、AI逻辑判定等等。服务器只对影响玩家利益的关键信息作验证。

  • 优点

保证了游戏操作手感,避免了本机操作延时。

  • 缺点

运算逻辑存放在客户端,会带来较大的外挂风险。

 

3.3 游戏策划上的优化

  • 原理

在游戏设计层面,来隐藏玩家的延迟感。比如:延长出招/收招动作时间、降低动作判定精度、给技能加公共CD、避免战斗受击时发生位移等等。

  • 优点

无任何技术风险,绿色、环保、安全,代价最小。

  • 缺点

可能会影响战斗的爽快感。

 

4 公司内项目的一些做法

《QQ堂》和《炫斗之王》都是公司自研的动作休闲类游戏,在与其相关负责同事作了一些简要交流后,将他们的做法小结如下:

  • 客户端之间采用P2P通信

这对于在同一局域网内(如:网吧)的玩家,网络延迟很小。只有当两个Peer连结不同时,消息包才通过服务器中转;

  • 客户端先表现,服务器后检验

玩家角色在移动、战斗出招等操作时,客户端在发出请求包的同时,先自行在本机表现,继续后面的游戏逻辑,而无需等到服务器验证通过后才开始。

  • 客户端的校验逻辑同时在服务器再运行一遍

这也是惯用做法,即所谓的服务器强校验。

  • 做好客户端反外挂

由于采用P2P通信,有些逻辑难免会放在客户端,这与上述的一些解决方案的做法也是类似的。附上QQ堂对于反外挂处理的一个分享文档

5 小结

综上所述,动作类网游在技术实施层面上,较传统MMORPG主要是在数据同步(多个Peer间、C/S间)上要求更加苛刻,当然,这目前在客户端平台上,也已经有了较为成熟的技术解决方案。但具体到页游平台,虽然从Flash10和Adobe AIR1.5开始,已经支持P2P通信,Adobe也在官方提供相应 的P2P服务,即代号为Cirrus,但目前尚未看到其在商业运营的页游项目里有成熟的应用。因此,在页游平台的P2P应用,还需要更进一步的探索和挖掘。