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

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模式的服务器强校验的方式进行，所有的消息都在服务器判断后再进行表现。这一块的内容已经比较成熟，不再进行详细阐述。

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

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检查，后期还可以细化到以副本中的某段为单位进行更细致的检查。

2.        通关时间检查

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

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