技能系统的同步机制

这里所说的技能系统包括：技能流程和技能创生体（法术场、弹道和buff）

首先介绍authority和proxy的概念，这两个概念是基于单位unit的基础上进行的区分。

authority表示单位的主控端，即此单位是由客户端和仍是服务端控制。对于玩家avatar，玩家本地的客户端就是主控端。而对于怪物，他们的行为由服务端控制，主控端就是服务端。

proxy表示代理端，表示被主控端控制。如对于怪物来讲，全部的客户端都是proxy；对于玩家A来讲，服务端和其余玩家的客户端都是proxy。

0 技能同步的原则 

1.客户端先行 

对于玩家控制的单位来讲，玩家点击按钮释放一个技能，客户端首先响应，单位播放动做以及相应的技能特效。

据了解，有的已上线游戏并无作客户端先行，而是全部的技能执行请求都发给服务端，而后由服务端发起。

这种模式技能流程控制会比较简单，可是在网络环境差的状况下，体验可能差一些。可是，目测也是能够接受的。

2.技能流程以authority为发起端 

玩家单位技能发起是由她的客户端，怪物的技能发起是由AI也就是服务端。

3.技能结算在服务端发起。 

技能真正的结算，好比法术场检测、buff结算、伤害计算以及扣血等，统一在服务端处理。

1 技能执行流程的同步 

这里所说的技能执行流程指的是技能树的一个执行节点的流程。

技能流程负责动做、特效以及技能结算，其中技能结算包括：释放法术场、弹道或buff。

一个技能执行节点的执行流程中，须要同步的有两个时间点：

• 技能开始：技能开始播放动做

• 技能结算：前摇结束，即能进入结算逻辑。这类同步消息每每并非由技能自己去同步，而是技能生成了法术场、弹道等，他们去作相应的同步。

以玩家点击技能按钮开始释放技能为例介绍技能同步流程，如图所示：

 

1. 主控端点击技能按钮，技能开始播放动做，主控端告诉服务端技能开始。

2. 服务端广播给全部的客户端(多玩家场景)，告知其余全部的客户端此玩家开始执行技能。其余客户端收到指令后但是播放技能表现。

3. 服务端延迟一段时间后，服务端开始进行技能结算，而且将结算结果通知客户端。

延迟时间=技能前摇时间-上行-下行，下行一半不能肯定，因此默认为上行=下行

另外一种中庸的计算方式是：延迟时间=技能前摇时间-上行，防止要求技能前摇时间过长

使用此同步流程的表现为：

1. 要求技能前摇时间>2*网络延迟，若前摇时间短，则延迟时间=0，效果可能差一些

2. authority客户端表现完美。

3. proxy client表现通常，即玩家A看玩家B的效果为：玩家B刚开始执行技能动做，没到前摇时间就进行了技能结算。可是由于玩家通常也不会过度关注其余玩家的动做，因此是能够接受的。

2 技能树的同步 

咱们游戏使用的是技能树来管理技能流程。那么就面临一个问题，技能树如何同步。

最简单最暴力的方式，是客户端和服务端同时管理技能树，而且将其状态同步。这样，客户端和服务端的技能树状态统1、完备。

后来发现，对于proxy端，并不须要完备的技能树信息，最节省的方式是proxy根本不接受技能树同步信息，只是接受播放动做、技能结算等信息。但这样须要告诉其余proxy播放什么动做、特效等。

在咱们系统中，技能同步包括三类同步消息:

• 技能根节点enter (root_enter): 表示一个大技能的进入

• 技能叶子节点enter(action_enter): 表示一个技能树的执行节点的进入。

• 根节点exit(root_exit) ：表示大技能结束

根节点保存一个完整技能的信息，须要和技能模块外部交互，所以须要知道技能的开始和结束。

叶子节点的执行表明着技能真正的执行逻辑，也须要同步。

而对于其余节点，做为流程控制节点，只须要在主端确保技能流程无误便可

后来这里进行了进一步的优化，对于纯根节点，主控端（玩家控制的客户端）将信息同步给服务端，服务端再也不同步给其余客户端。有的技能树只有一个节点，那么按照叶子节点的策略，主控端同步给服务端，服务端广播给全部的其余客户端。

3 技能结算的同步 

技能结算包括建立法术场、buff、弹道、技能直接伤害等。

法术场、弹道的同步 

法术场、弹道的同步比较相似，他们都做为一个entity（网络同步单元）在服务端建立，建立之后使用entity管理机制服务端通知客户端他们的建立和销毁。

以法术场为例，法术场的执行和同步流程：

1. 服务端发起建立一个法术场，而且通知客户端

2. 法术场每隔一段时间结算一次，注意，法术场结算并不须要同步，每隔一段时间服务端执行检测逻辑，客户端播放结算特效等。两个逻辑互不依赖，也不要求时间一致。

3. 当法术场结算时检测到攻击目标时，服务端计算攻击伤害等信息，并将攻击信息发给客户端。

4. 客户端收到伤害信息，客户端播放相应的表现，如法术场受击特效等。此处还包括属于通用模块的跳字等。

5. 当服务端的法术场时间到了进行destroy时，使用entity的管理机制通知全部客户端destroy法术场。

弹道的同步相似，惟一的区别就是法术场在某一位置使用攻击盒检测目标，而弹道是一个移动的子弹，客户端表现是一个特效在飞，而服务端每隔一段时间根据飞行速度等使用胶囊攻击盒去检测目标碰撞。

由以上能够发现，法术场做为一个entity他的管理成本是比较高的，因此若策划想出一些需求须要使用多个法术场实现，通常经过拓展法术场功能使用一个法术场来实现。

好比，策划要作一个冰火两重天法术场，即法术场在每次结算时使用不一样的参数，第一次结算使用火焰，第二次结算是冰霜。若这种需求较少，可使用两个法术场，可是若是要冰火雷毒水电风魔奥术神圣*N重天，则代价太大。通常可让法术场支持每次使用不一样的结算参数来结算便可。

buff同步 

buff是附加在unit身上的东西（没有unit就没有buff，可是没有unit可能有法术场），因此不须要使用entity来同步。

1. 服务端肯定buff是否能够挂在unit上面。

2. 客户端和服务端都维护一个buff管理器，挂buff的消息通知全部客户端，客户端负责表现，服务端负责结算便可。

4 伤害、属性的同步 

主要介绍下伤害的同步，顺便附带介绍下属性同步。

对于伤害结算来讲，技能、buff、法术场和弹道均可能形成伤害，当服务端发现形成伤害时，服务端首先根据技能信息计算伤害值，计算之后将伤害信息发送给全部客户端，全部客户端接到信息后首先播放技能伤害相关的表现，如受击特效等，而后播放跳字等通用伤害客户端表现。

也就是说，伤害值的同步其实就是简单的rpc消息。

buff可能修改单位属性，如攻击力、攻击速度等。这些属性值的同步通常使用属性同步，属性同步的意思是当一个值改变了，底层自动把这个值同步给客户端。

血量等信息值都是用属性同步方式。

伤害计算和属性模块是一个重要且比较复杂的模块（固然，若游戏数值很是简单也能够很简单）