一个MMORPG的常规技能系统
转载自：http://www.gameres.com/729192.html
广义的的说，和战斗结算相关的内容都算技能系统，包括技能信息管理、技能调用接口、技能目标查找、技能表现、技能结算、技能创生体（buff/法术场/弹道）管理，此外还涉及的模块包括：AI模块（技能调用者）、动作模块、寻路/移动模块以及人物属性和伤害数值结算等。
先说下技能模块每个部分的职责和原理：
- 技能信息管理：管理unit所拥有的技能以及技能的等级、cd等。在我们游戏中，这里还需要负责管理符文，符文会对技能信息进行修改。
- 技能调用接口：AI或者UI操作触发技能，触发技能时可能选择了一个目标（AI），也可能并没有目标。
- 技能流程管理：一个技能可能由多个子技能以移动的执行模式组合而成，而每一个最终执行的技能执行过程也存在一个流程，一般包括：前摇过程-结算点-后摇过程。技能在前摇结束时进入技能真正的结算流程，结算流程可能创建子弹，也可能触发buf或者创建法术场。
- 技能目标查找：若技能触发时已经设置了技能目标unit(如怪物AI释放技能)，则直接将其作为目标unit，否则需要根据一定的策略选择一个目标。此外，技能释放的时候还需要释放方向和释放位置等信息，也通过这个模块获取。
- 技能表现：技能释放过程中，需要创建相应的特效以及执行相应的动作。
- 技能创生体（buf/弹道/法术场）管理：buf挂在unit身上，可能影响unit的一些行为和状态；法术场一般由场景管理，影响场景中某范围内的unit；弹道就是技能创建的一个子弹，这个子弹可能以不同的路线移动（直线／抛物线／直接命中等）
1、技能表
首先说下实现技能的基本思路。实现技能的基本思路就是通过策划填写表格，来配制成某些技能，在执行某个技能的时候，分别去根据这些表格中的内容，确定技能如何表现。基本的逻辑是：
- if skillTable.get("技能动作"):
- paly 动作
- if skillTable.get("特效"):
- 播放特效
- if skillTable.get("法术场"):
- 创建法术场
- ....
2、技能信息管理
unit创建时，此模块管理unit可使用哪些技能，比如游戏中玩家可以选择使用哪些技能。
游戏中技能的升级、技能加点、技能池管理都在这个模块。
此模块还需要管理技能等级／符文／装备等外部模块对技能参数的修改。
3、技能调用接口
提供技能调用的接口供AI或玩家操作调用，调用时可以提供一个目标unit，也可以不提供让技能自己查找。
提供三个接口：
- 技能开始skill_enter：开始执行技能，若技能不循环进行，则技能可以自动结束。
- 技能结束skill_exit：有的技能不能自己结束，比如某些循环技能，对于循环技能玩家可以按住按钮一直释放。当玩家松开按钮，调用技能结束接口，告诉当前技能使其结束，此时技能到达后摇点时，技能不再继续执行。
- 技能停止skill_stop：当技能被强制打断时，如被攻击、晕眩、蓝不足等，技能会被强制停止。
此外，当前一个技能正在执行时新的技能调用启动，此时新的技能调用信息会被保存。一般来说，并不会把所有新的技能调用信息保存下来，那样就成了一个技能执行的序列。我们游戏仅保存一个新的技能调用信息。
总的来说，技能模块提供尽量少的接口供AI/UI等上层逻辑使用，这样可以有效的与AI和UI进行解耦。
4、技能流程管理
技能流程这里分两点讨论：
（1）一个技能可能由多个子技能以一定的模式组合起来。
一个技能常常由多个子技能以一定的模式组合而成，比如三段击、比如冲锋斩（先冲锋、后斩）等，甚至还存在根据不同的环境选择执行不同的子技能。分析策划需求发现，技能可以分成一个树形结构，这个树形结构非常类似行为树，同样可以将节点分为控制节点和执行节点，甚至可以包括condition节点。为此，我们项目引入一个技能树概念来描述这种数据结构。
（2）一个具体的技能（技能树执行节点）也有一个固定的执行流程。这个流程一般为：前摇过程、前摇过程结束=技能结算时间点、后摇时间点。
4.1 技能树
技能树参考传统行为树的设计，使用树形结构控制技能的执行流程。
技能树和行为树在结构上比较类似，但是在运行逻辑上有很大的不同。
首先，技能树的重点并不是根据上下文选择一个合适的节点执行，而是以一定的策略将技能树从头到尾遍历执行一遍。
其次，技能树没有tick的概念，而是基于回调的，比如一个顺序节点，顺序节点中一个子节点执行完毕后，马上通知顺序节点，顺序节点执行下一个子节点，直至顺序节点的最后一个子节点执行完毕，顺序节点就会通知父节点（如果有）它已经执行完毕。
此外，为了完成技能的一些需求，控制节点往往存储更多的控制信息来控制子节点的执行流程。具体的信息根据策划需求设置，比如顺序结点包括原子属性和循环属性。如果一个顺序节点具有原子属性，则这个顺树节点在执行的过程中并不会被end，只有全部子节点执行结束才可以end。
以我们游戏中战士普攻三段击为例：
三段击本身是一个顺序节点，当技能开始时，此节点顺序执行三个子节点。对于第一个子节点，它依然是一个顺序节点，首先冲锋至目标单位身前，然后对目标单位进行挥砍。但是冲锋节点还包括了一个condition，若和目标的距离很近，则跳过冲锋节点，直接挥砍。
普攻是一个循环技能，这个技能只要玩家点着按钮不放开，技能就会一直执行，因此根节点（普攻）是一个具有循环属性的顺序节点。而对于子技能1（控制节点），他是一个具有原子属性的顺序技能，即当单位正在冲锋时，玩家松开按钮，单位也会执行完挥砍后才会推出技能。
！关于技能树的使用和思考
技能树开始的设计思路是，有些技能的执行流程和行为树类似，比如以一定的顺序执行一系列子技能，比如根据不同的上下文确定技能的执行流程。简单的说，技能树的引入有以下好处：1.使技能模块可以获得部分AI的能力，从而将和技能强相关的AI逻辑放在技能模块使技能模块和AI模块降低耦合，2.可以清晰的描述技能流程，3.使用树增加拓展性，策划可以设计出各种各样复杂的技能。
关于好处1，举个例子：屠夫boss的勾子技能可以将玩家拉过来，若成功的拉过来，boss会执行一个攻击子技能，否则不执行。通过这样可以将勾人和攻击作为两个子技能构成技能树，攻击子技能有一个condition过程，即判断上一个子技能是否成功。
技能树在使用后慢慢发现一些问题，首先，技能树的同步要求每个树节点都进行同步，增加同步负担，其次，技能本身并不会有太复杂的控制结构。
为此，后来我们对技能树进行了优化：
- 简化同步信息，不再同步所有节点的enter/exit信息（具体参考文章《技能模块的同步》）。
- 取消并行节点，通过拓展表头实现一个技能同时执行多件事情。
最终的技能树基本上是只有顺序／随机两种控制类型节点，节点拥有较轻度的condition功能。
4.2 执行节点的技能流程
一般来说，技能的执行流程包括：
前摇时间：技能开始，但是技能真正的结算流程还没开始。技能开始以后，机能相关的特效和动作就开始播放。
前摇时间结束：技能前摇结束时技能开始真正的释放以及结算，等技能前摇结束以后，技能真正的释放并结算。释放包括创建相应的弹道／法术场和buff。
技能后摇点：技能播放到后摇点时间时，技能真正的结束。这时，技能对应的特效以及人物动作可能还会继续播放，但是技能流程已经正式结束了。也就是说，下一个技能可以执行。
5、技能目标查找
技能释放时，目标可能已经由AI传给了技能模块，也有可能没有一个目标，如玩家控制单位。
技能在释放法术场、弹道的时候，重要的是技能的方向而不是技能目标一般来说，技能获得一个目标对象以后，技能的方向就是释法者到目标的方向。
此外，技能方向可能需要一些配置，如前摇锁定（前摇过程中目标移动，技能方向不变），UI可控制（技能释放过程中，玩家可以通过控制UI控制技能的释放方向）。
6、技能表现
技能的表现包括动作、特效、shader、音效等。其中，特效比较复杂，需要配置的内容也比较多。比如，有些特效挂在模型上，有的特效挂在场景里。对于法术场的特效，分别可以分为法术场开始、结算、结束特效，分别在法术场开始时、结算时、结束时显示。对于buff也类似。
7、弹道、法术场和buff等技能创生体
狭义的来说，技能只是负责技能的执行流程（技能树管理以及技能流程管理），而技能真正的结算主要是由其创生体结算的。当技能前摇结束开始生效时，技能创建相应的弹道和法术场，法术场弹道击中敌人时又有可能产生相应的buff。
一般来说，法术场是一个场景的某块检测区域，每隔一段时间法术场检测此区域的敌人，并对其攻击结算。
弹道是一类子弹移动路径的抽象，创建一个弹道就表示一个子弹特效沿这个弹道移动并检测路径上的敌人。
buff就是挂在单位身上的一个具有持续时间的状态，状态对单位产生一些正面或者负面的影响，并且在此段时间内，每隔一段时间进行一次伤害结算 。
对于技能、法术场、buff之间的功能界定并不是很固定，比如技能能否直接对单位造成伤害，法术场能否对单位造成伤害，甚至技能只能创建法术场，法术场只能检测目标不能造成伤害，只能挂buff，而所有的伤害都是通过buff来结算。当然，这样并不一定好，一般来说，技能和法术场都可以对单位造成伤害。
总之，创生体功能的界定需要根据策划需求、效率考虑等因素调整。
7.1 Buff状态
Buff就是挂在单位身上持续一定时间的有益或者有害的状态，这里状态＝buff。
Buff模块有个需要注意的是Buff之间的相互关系，如排斥（A状态在，B状态挂不上去），清除（A状态挂上去同时导致B状态消失）等。
为了实现以上功能，最简单的方式是在状态A中直接填写状态关系状态字段，如状态A排斥状态B/C/D/E...，A状态清除状态X/Y/Z...。
以上的实现方式有个问题，等游戏做到后期，我们有成千上万个buff状态，那么一个魔法免疫状态，策划需要填表的排斥状态可能成千上万。
为了解决这个问题，可以使用分类的思想解决。定义某类状态和另一类状态之间的规则。
基于以上思想，引入一个叫buff原子状态的概念，原子状态表示一类状态，如减速、禁魔、魔免、悬空、晕眩、变羊等等等。
在给单位挂一个新的buff的之前，查询此buff持有的原子状态和单位身上已经有的原子状态之间的关系，根据单位身上已有的原子状态判定新的原子状态应该使用何种行为处理。
此处的何种行为，代表的就是原子状态之间的规则，如排斥等。这些规则可以让策划填一个名字叫“原子状态关系”的表，此表是一个n*n的二维数组，n为游戏中所有的原子状态的数量。
原子状态的数量远远小于buff的数量，所以可以很容易的定义这些规则。
7.2 法术场
法术场描述对一块区域的影响，这块区域可以每隔一段时间进行一次检测，检测这块区域内的单位并且对单位进行结算。
法术场需要注意一个问题，就是一个法术场每次结算可能使用不同的参数进行结算，比如一个技能，第一次结算对每个单位进行晕眩，第二次结算对单位进行伤害。
解决这种问题比较直接的方式是技能直接创建两个法术场，每个法术场结算一次，第二个法术场创建具有延迟时间。但是这种方式有个问题，有可能策划需求做一个结算十次而且每次结算的参数都不同的法术场。那么，一个技能以一定的时间间隔创建是个法术场，同时法术场的管理具有一定的成本，从而导致效率的降低。
为解决这个问题，我们优化了法术场结算的实现机制，增加了一种新的法术场：序列法术场。这类法术场策划可以配置法术场每次结算之间的时间间隔以及每次结算所使用的法术场参数。
