打击感增强 《QQ封神记》同步验证机制详解

发表于2015-04-30
评论1 977浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏程序行业精英群

711501594

QQ封神记是一款偏动作的2D横版MMOG。为了游戏有一个比较好的打击感,我们对同步和验证的机制进行了研究,最后采用了下面介绍的方案

一、 同步策略以及方案

1.1主机职责

 

首先我们引进了主机的概念。在一个副本中选择一个客户端作为副本的主机,其他客户端作为从机。该副本中的怪物的AI、碰撞检测等都在主机上进行,这些信息通过服务器转发到达从机,从机进行表现。当主机退出副本或者掉线后,自动切换其他机器为主机。

1.2同步内容

游戏中需要同步和验证的主要分为两块:

1.      系统成长面同步:

1) 装备系统

2) 道具系统

3) 聊天系统

4) 组队系统等方面的内容

2.      过程体验面同步:

1) 移动

2) 战斗

3) 怪物AI

4) 关卡和其它方面内容。

在系统面成长同步,采用传统C/S模式,服务器通过视野和操作结果的转发进行。这一块内容已经非常成熟,本文不在进行详细阐述。

对于过程体验面的同步,因为传统Server控制,Client表现的方式不能满足战斗及时性和打击感的需求,所以我们必须寻求其他同步方式。这一块的内容也是本阐述的重点。

过程体验面的验证细化为以下几点:

1) 玩家移动

2) 玩家动作

3) 怪物AI(移动和动作)

4) 战斗结果等

1.3同步机制

同步机制有两种选择分为输入同步和结果同步

最开始我们选择输入同步,实验之后发现在A客户端输入两条相同的指令,因为网络延迟当到达B客户端的时间间隔可能会有波动,会造成B客户端做出不同解析,进而表现的效果会与A客户端不一致。当然严格的帧同步可以解决时间延迟带来的指令解析不一致问题。但是严格的帧同步在面对网络环境复杂的玩家,会造成玩家输入延迟明显、手感不佳等问题,这些对于我们偏动作的MMOG来说是不能接受的。

最后我们选用结果同步的方式,保证本机的体验和对端的结果正确性。

 

具体来说,结果同步的方式我们会以“命令(CMD)”的 方式进行,比如战斗同步,我们会把和战斗相关的结果抽象为各项CMD,如位置变化MoveTo、动作执行DoAction、伤害结果包HitPack等等。

1.4同步优化

上述的同步机制只能保证在不同的客户端,最终表现出一致的结果。并不能保证其表现一定是流畅和圆滑的。在保证结果正确的基础上,我们还需要通过一系列的优化来达到流畅的同步。

1.4.1参考时间体系

与角色移动相关的因素有时间,速度,方向等,为了保证各时刻在不同客户端角色都能有大致的位置,需要选择一个参考时间体系,在每个客户端维护一个相对参考时间体系的时间,我们选择以Server时间为参考时间体系。通过两端通信最小延迟的方法来进行客户端与Server的对时。

1.4.2移动同步的动态调整

在网络游戏中,网络的延迟与抖动是不可避免的,当玩家在Client1在A点开始行走,到B点后转向,消息经过网络到达Client2,可能由于网络抖动,在Client2上玩家收到转向消息时候,玩家才处于D点。

这时我们根据D与B的距离差不同采取不同策略:

1) 距离差<60像素 则玩家在Client2上直接跑到B,然后再执行玩家在Client1上在B点的运动。

2) 距离差>=60像素 则在Client2上玩家直接拉扯到B,然后再执行玩家在Client1上在B点的运动。

1.4.3怪物所属分摊以及有策略的动态调整

如果可以对怪物所属进行多主机分摊。比如3只怪物,可以个给3个Client每一个分配一只怪物,在游戏过程中再有针对性的对怪物的主机进行动态调整,那么可以带来同步面上的一些更平滑的效果,对校验策略也有一些帮助。

二、验证策略方案

2.1验证内容

封神记游戏中需要验证的地方包含两大类。

一、系统成长面的验证:这一块的内容主要是传统MMOG中数值成长面的系统,比如

1) 装备系统

2) 道具系统

3) 玩家交流

4) 组队信息

5) 其他不一一列举

等方面的内容。

二、过程体验面的验证:这一块的内容主要则是在游戏过程中,比如

1) 关卡解谜

2) 移动

3) 战斗

4) 其他不一一列举

等方面的内容。

2.2 验证基本原则

对于系统成长面的验证,采用传统C/S模式的服务器强校验的方式进行,所有的消息都在服务器判断后再进行表现。这一块的内容已经比较成熟,不再进行详细阐述。

对于过程体验面的同步,不再采用先服务器判断,再客户端表现的方式进行。为了战斗过程和手感的考虑,过程体验面的验证,采用客户端先表现,再发送消息到服务器,服务器如果判断不能执行也不对客户端进行打断或者拉扯操作,只进行信用扣分,信用会累计到关卡最后的收益阶段,信用度的下降会导致最后收益的降低、甚至没有收益。最后,对于过程中信用度非常低的玩家,也可以采用直接踢下线的方式进行惩罚。比如:

信用满分100分

得到全部奖励

大于80分

得到95%的奖励

大于60分

得到80%的奖励

大于40分

得到20%的奖励

大于20分

无奖励

小于20分

直接踢下线

 

2.3 过程体验面的验证规则

2.3.1基础

客户端和服务器进行时间对齐,后续的所有C/S消息均带上服务器的时间戳,目的在于服务器可以据此准确的验证有时间变量的消息事件。因为动作的表现都基于帧为单位,因为我们的时间粒度也以帧为单位进行对齐。

2.3.2移动验证

移动验证主要分为速度和阻挡的验证。

 

1.        速度

1)        牛顿运动验证

对于牛顿运动来说,客户端把包含方向的运动消息发送给服务器,因为服务器有主角或者怪物的速度信息,两次运动之间的时间信息,加之上一次的位置,根据S = VT+1/2aT^2,一定是可以验证出一个合理的结束位置的。这里我们会做一个大致范围的判定,只要在误差内都可以接受,超出误差后我们不进行拉扯,会对用户信用进行扣分。

 

 

2)        轨迹运动验证

轨迹运动主要是指预先编辑在动作档上的,由动作带来的位置变化,比如冲锋这个动作,除了技能效果外,就会带来主角或者怪物位置的变化。这一块的验证思路是服务器端也会维护动作档,每一帧(时间间隔)固定的对玩家或者怪物的位置进行更新。

 

2.        阻挡

静态阻挡的验证方式是通过在服务器端加载地图栅格的方式进行。因为是静态阻挡,所以同一副本的各个实例的栅格阻挡信息是相同的,所以这里不需要为每个实例维护一份信息,直接使用静态的数据档,这样解决了老封神上因副本栅格带来的内存吃紧的问题。同速度的方式一样,对于进入阻挡的客户端,会进行账号的信用扣分。因为进入阻挡可能会带来较大的作弊收益,比如快速通过开卡,远程职业躲在阻挡里面打怪等等,因此进入阻挡的信用扣分幅度也会比较大。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

阻挡

阻挡

阻挡

 

 

 

 

 

 

 

 

 

阻挡

阻挡

 

 

 

 

 

 

 

 

 

阻挡

阻挡

 

2.3.3怪物AI验证

因为怪物的AI是放在主机上的,因为为了避免玩家作弊,需要对怪物的AI进行验证。

  

 

封神的怪物AI是通过行为树进行控制的,左图是一个简单的AI实例,我们可以通过把行为树转化为右边的二叉树,当怪物执行一次动作时,把它AI这次经过的路径发送到服务器,比如怪物选择的是行为3,路径就是0à1à2à3,服务器判断这条路径上的条件是否满足,就能确定怪物的这次AI选择是否是合法的。

当然还有一种可能是怪物站立在那里不动,不发任何AI,我们通过现在怪物每隔2秒钟必须发一条AI来避免作弊客户端不发怪物AI的情况。

2.3.4战斗验证

1.        数值判定

战斗过程中数值面的判定,比如技能的CD时间,施法时间,耗蓝,技能伤害数值等等。这些数值面的判断Server端都可以通过战斗消息驱动。

2.        攻击命中判定

 

命中判定主要是指碰撞盒的检测,这一块的计算主要在客户端进行,因为计算量和性能的原因,Server端不进行碰撞检测,我们通过选择验证客户端对碰撞检测进行校验。比如B、C在副本中进行战斗,当发生碰撞检测时,主机把碰撞检测消息发给服务器,服务器进行伤害计算后,把碰撞检测的消息发给验证客户端,验证客户端根据消息,判断攻击方和受击方是否能够产生碰撞,最后讲结果发送给服务器,服务器根据验证客户端判断B、C是否作弊。

验证客户端功能:

Ø         验证客户端只接收其他客户端发送的同步消息,其本身不发送消息

Ø         验证客户端只渲染场景,只做后台计算

Ø         验证客户端对于验证的结果不做出自己的解释,只负责把收集的结果发送给Server

验证客户端选择:

Ø         出于性能方面的考虑,验证客户端一般从在主城中的玩家中选择

Ø         验证客户端如果进入其他副本,或者掉线,下线等等,则终止对于副本的验证

3.        受击验证

上面的攻击命中判定只能检测到玩家发送了碰撞检测的情况,如果玩家受击后不发送碰撞检测,玩家也会获得收益。为了检测这种情况,我们采用的方式是,当敌方使用了一个技能后,服务器就缓存这之后玩家的所有动作消息,当地方技能结束后,把缓存的玩家动作信息发送给验证客户端,验证客户端还原副本中客户端的场景,判断是否会产生碰撞,如果有碰撞,则副本中的客户端作弊。

2.3.5策略验证

除了以上几个具体的验证规则外,我们还有基于策略的范围验证。所谓基于策略的验证是指Server从宏观面对客户端行为的检测,检测结果以一个范围值为标准,在认可的范围内的行为都属于合理的行为。

 

1.        DPS检查

伤害输出这个数值,服务器可以根据玩家的等级、职业、装备、技能等可以取到的参数中计算出一个平均每秒输出上限,如果玩家通过一个副本后的DPS大于了上限值,那么一定是有问题的。初期可以以一个副本为单位进行DPS检查,后期还可以细化到以副本中的某段为单位进行更细致的检查。

 

段落1

段落2

段落3

段落4

副本1

 

 

 

 

副本2

 

 

 

 

副本3

 

 

 

 

 

2.        通关时间检查

封神记的过程体验以副本为单位进行,副本内的核心要素主要包含战斗和关卡两块,因为有这两块的限制,因此,每一个副本我们都可以评估出一个通关时间下限,小于这个时间是设计上绝对不可能通关的。因此,如果有玩家的通关时间小于我们设置的通关下线,那么就可以判断出他使用了外挂等作弊行为。

 

通过时间下限

关卡1

 

关卡2

 

 

通过以上的一些同步机制,我们保证了多个客户端操作的同步性,再加上验证的规则,把客户端能作弊的范围限制在了一个很小的区间内,对游戏的影响已经相当有限。

 

 

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台