技能模块的防外挂机制和同步机制优化.docVIP

技能模块的防外挂机制和同步机制优化 游戏在真实的环境中，有些特殊情况需要处理，本文介绍技能模块是如何处理人为作弊和现实中的网络导致的一些问题。　　主要介绍三个功能：　　1.防外挂　　2.网络延迟问题解决　　3.网络卡顿和抖动　　4.流量优化　　注意，本文默认介绍的是玩家的技能处理，也就是技能的控制端在玩家的客户端。对于控制端在服务器的小怪，基本没有以上问题。　　1.防外挂　　由于技能是客户端先行，因此技能模块很多逻辑是放在客户端的，有客户端控制技能流程并且通知服务器执行相应的功能。由此可见，技能是由客户端发起的，服务端必须对收到的既能执行命令进行验证以保证技能确实是可用的，防止玩家通过外挂重复发送技能释放消息无限次释放技能。　　每个游戏技能系统实现不同，可能对应的逻辑也不太一样。基本原则是：　　1.服务端保存技能释放可用性的相关信息，比如技能CD、技能蓝量等。　　2.技能真正的释放写在服务端，客户端只是提前播放技能的表现（动作、特效）。　　3.服务端每次真正的释放技能之前，对技能进行判断是否可用。　　4.对于收到的技能执行消息，根据实现系统的规则进行相应验证。　　下面，以我们的技能系统为例，介绍我们是如何实现防外挂的。　　在我们系统中，技能同步包括三类同步消息: 技能根节点enter (root_enter): 表示一个大技能的进入 技能叶子节点enter(action_enter): 表示一个技能树的执行节点的进入。 根节点exit(root_exit) ：表示大技能结束 　　服务端会接受到客户端发来的这三种技能消息，root_enter表示一个大技能的开始，action_enter表示一个技能执行节点的开始执行。root_exit和防外挂没有关系。　　由于技能的信息都是以root_enter来控制的，比如技能CD、技能耗蓝和沉默/晕眩等导致的技能是否可用，因此，当服务端收到root_enter的时候，首先要判断这个技能是否真的可以释放，判断后进入相关逻辑。　　action_enter是技能真正的执行消息，技能模块并没有方法判断一个执行节点（技能树叶子节点）是否可用，因此，当收到action_enter的消息时，只能根据root节点的信息进行判断。我们进行了两种判断： 判断一：在root_enter和root_exit执行期间，表示正在执行这个大技能，收到action_enter后，判断这个action是否属于正在执行的大技能叶子节点，若不属于，不能执行。 判断二：我们还判断了action_enter消息对应的执行节点的顺序，保证执行节点是按照合法的顺序执行的，而不能一直执行某一个特别牛逼的叶子节点。 此外，服务端执行action节点的时候，不能同时执行多个，每次只能执行一个action节点，并且需要持续相应的时间（action节点的后摇时间），上一个action节点执行结束后才能执行下一个节点。 　　基于以上机制，可以保证服务端收到的技能消息只有合法的消息才可以执行。　　2.网络延迟　　在真实的网络环境中，网络延迟是难免的。造成的结果是，服务端一直晚于客户端。为了解决着这个问题，一般采取的方式是基于网络延迟时间让服务端加快执行速度，去追赶客户端。　　以技能apply为例，当server端收到action_enter消息后，根据当前时间和客户端开始时间可以计算出网络延迟，将服务端的前摇时间减少两个网络延迟，当客户端收到apply消息时，正好是客户端的apply时间。 　 　　3.网络波动和卡顿　　对于手机游戏来说，网络波动和卡顿也是难免的，这种情况造成的结果就是，原本按一定的顺序以一定的时间间隔到达服务器/客户端的消息，可能同时到达了服务器/客户端，或者时间间隔忽大忽小。　　一般来说，当服务器由于网络卡顿同时接收到多个技能开始执行的消息时，可以通过两种方式进行处理。　　1.接到技能执行消息后马上执行，这样导致的问题时可能在同一帧收到多条技能执行消息，并且在同一帧执行多个技能。这个策略的好处是处理方式比较简单，而且能让服务器尽快的跟客户端同步。但是为了防止玩家使用外挂同时发送多个技能执行请求，这个策略是不可行的。　　2.当接收到多条技能执行消息时，按序依次执行技能，每个技能的执行时间结束后，才执行下一条技能。这种策略的问题是，服务器的延迟与客户端较大，如果玩家一直在不停的放技能，会导致服务器与客户端的延迟越来越大。　　客户端和服务端采取不同的处理方式。　　3.1 proxy服务端（主控端是玩家控制的客户端）　　服务器是技能真正执行的地方，因此需要保证技能正确的执行。因此，服务端基于第二种方式解决网络卡顿，同时增加