Skill System

1 分钟读完

img

从架构上说,主动技能都可以拆分为释放条件检测->释放->目标选择->产生效果 但是里面很多细节,比如子弹初始位置设置,做成什么样子组合出更多的设计形式,同时可以兼容更多的有效需求 比如一个回合制卡牌游戏,要啥飞行子弹,区域只要相对和绝对位置2大类,然后直接填坐标就好了

示例1: 玩家释放技能1->释放子弹1对自身加免疫buff,释放子弹2在1秒后对身前范围最近1个友方击中->命中后对自身释放子弹->命令自身对目标释放技能2 释放技能1后选择对身前最近一个友方追加释放技能2

示例2: 被动技能->获得buff->buff触发器每2秒在自身位置释放单体子弹1清除buff1,aoe子弹击中敌人->每命中一个敌人对自身叠加1层buff1 实际效果:周围敌人越多自身获得越多层buff1

示例3: 玩家释放技能1->释放子弹1对自身周围友方和敌方击中->对命中的目标释放3个子弹:子弹1筛选敌人产生伤害,子弹2筛选友方30%血以上造成治疗,子弹3筛选敌人血量大于80%命中后产生子弹4对自身添加buff 实际效果:对周围友方残血造成治疗,对敌人造成伤害,如果击中的敌人血量较高,自身获得增益

示例4 玩家有被动技能获得buff1->buff触发器效果为暴击击中时若双方距离>300则对目标发射子弹1和子弹2->子弹1对自身添加buff,子弹2筛选有buff2的敌人 技能效果:暴击击中距离自身较远的敌人使自身获得增益,触发时若敌人有buff2,则造成额外效果

示例5 玩家释放主动技能->发射子弹使自身获得6层buff1 buff1附带3个触发器 触发器1->释放技能清除所有层数buff1 触发器2->受到攻击失去1层 触发器3->buff1消失时自身获得buff2 buff2->触发器每1秒对自身附近发射子弹筛选1个敌人->令目标对自身发射子弹添加增益 技能效果:主动隐身,受到攻击失去1层,释放技能后解除隐身,隐身结束后一段时间内受到伤害转移给附近一个敌人

基础内容有这么几个部分: 1、Actor,这个是角色本身,它不属于技能系统,但是它要给技能系统开放足够的接口,比如播放动画、播放声音、控制位移、造成伤害、添加buff等等 2、Skill,这个就是技能本身,它在合适的时机调用脚本中的相应函数,脚本中可以在OnCreate OnHit OnDeath OnHeroDeath OnSoldierDeath等事件中写相应代码。由于是脚本,所以代码非常灵活,而由于限定了只处理技能相关功能,所以代码也不会很复杂,有经验的策划绝对搞的定。 3、Buff,这个是技能效果的核心。它可以是有时限的,也可以是被动无时限的。在它对应的脚本中,定义了这个Buff会影响哪些角色属性(如血量、暴击、攻击力等等)或者角色状态(如眩晕、隐身、沉默等等),同样,buff脚本也支持事件机制,在脚本的相应事件处理其逻辑功能,可以实现非常丰富的效果。 4、Modifier,这个是一个技能修改器。技能修改器可以修改技能的流程和效果(比如技能伤害增加、火球击中人会爆炸等等),具体可以参考风暴英雄中的技能天赋系统。技能修改器并没有脚本与之对应,一个技能如果支持某个修改器,需要在脚本中处理相应功能。

技能的基类是RoleSkill,然后分近战和远程两个大类,记得不要根据职业来分,而是根据功能来抽象,近战的技能是通过武器来产生伤害,而远程技能是通过发射物来伤害。近战技能可以继续分为:近距离接触攻击单人,近距离范围内接触攻击多人等;远程技能可以分为:单发射物攻击单人,远距离范围内非接触攻击多人等。

img

广义的的说,和战斗结算相关的内容都算技能系统,包括技能信息管理、技能调用接口、技能目标查找、技能表现、技能结算、技能创生体(buff/法术场/弹道)管理,此外还涉及的模块包括:AI模块(技能调用者)、动作模块、寻路/移动模块以及人物属性和伤害数值结算等。

先说下技能模块每个部分的职责和原理:

  • 技能信息管理:管理unit所拥有的技能以及技能的等级、cd等。在我们游戏中,这里还需要负责管理符文,符文会对技能信息进行修改。
  • 技能调用接口:AI或者UI操作触发技能,触发技能时可能选择了一个目标(AI),也可能并没有目标。
  • 技能流程管理:一个技能可能由多个子技能以移动的执行模式组合而成,而每一个最终执行的技能执行过程也存在一个流程,一般包括:前摇过程-结算点-后摇过程。技能在前摇结束时进入技能真正的结算流程,结算流程可能创建子弹,也可能触发buf或者创建法术场。
  • 技能目标查找:若技能触发时已经设置了技能目标unit(如怪物AI释放技能),则直接将其作为目标unit,否则需要根据一定的策略选择一个目标。此外,技能释放的时候还需要释放方向和释放位置等信息,也通过这个模块获取。
  • 技能表现:技能释放过程中,需要创建相应的特效以及执行相应的动作。
  • 技能创生体(buf/弹道/法术场)管理:buf挂在unit身上,可能影响unit的一些行为和状态;法术场一般由场景管理,影响场景中某范围内的unit;弹道就是技能创建的一个子弹,这个子弹可能以不同的路线移动(直线/抛物线/直接命中等)

0技能表

首先说下实现技能的基本思路。实现技能的基本思路就是通过策划填写表格,来配制成某些技能,在执行某个技能的时候,分别去根据这些表格中的内容,确定技能如何表现。基本的逻辑是:

if skillTable.get("技能动作"):
     paly 动作
if skillTable.get("特效"):
     播放特效
if skillTable.get("法术场"):
    创建法术场
....

1 技能信息管理

unit创建时,此模块管理unit可使用哪些技能,比如游戏中玩家可以选择使用哪些技能。

游戏中技能的升级、技能加点、技能池管理都在这个模块。

此模块还需要管理技能等级/符文/装备等外部模块对技能参数的修改。

2 技能调用接口

提供技能调用的接口供AI或玩家操作调用,调用时可以提供一个目标unit,也可以不提供让技能自己查找。

提供三个接口:

  • 技能开始skill_enter:开始执行技能,若技能不循环进行,则技能可以自动结束。
  • 技能结束skill_exit:有的技能不能自己结束,比如某些循环技能,对于循环技能玩家可以按住按钮一直释放。当玩家松开按钮,调用技能结束接口,告诉当前技能使其结束,此时技能到达后摇点时,技能不再继续执行。
  • 技能停止skill_stop:当技能被强制打断时,如被攻击、晕眩、蓝不足等,技能会被强制停止。

此外,当前一个技能正在执行时新的技能调用启动,此时新的技能调用信息会被保存。一般来说,并不会把所有新的技能调用信息保存下来,那样就成了一个技能执行的序列。我们游戏仅保存一个新的技能调用信息。

总的来说,技能模块提供尽量少的接口供AI/UI等上层逻辑使用,这样可以有效的与AI和UI进行解耦。

3 技能流程管理

技能流程这里分两点讨论:

  1. 一个技能可能由多个子技能以一定的模式组合起来。 一个技能常常由多个子技能以一定的模式组合而成,比如三段击、比如冲锋斩(先冲锋、后斩)等,甚至还存在根据不同的环境选择执行不同的子技能。分析策划需求发现,技能可以分成一个树形结构,这个树形结构非常类似行为树,同样可以将节点分为控制节点和执行节点,甚至可以包括condition节点。为此,我们项目引入一个技能树概念来描述这种数据结构。
  2. 一个具体的技能(技能树执行节点)也有一个固定的执行流程。这个流程一般为:前摇过程、前摇过程结束=技能结算时间点、后摇时间点。

3.1 技能树

技能树参考传统行为树的设计,使用树形结构控制技能的执行流程。

技能树和行为树在结构上比较类似,但是在运行逻辑上有很大的不同。

首先,技能树的重点并不是根据上下文选择一个合适的节点执行,而是以一定的策略将技能树从头到尾遍历执行一遍。

其次,技能树没有tick的概念,而是基于回调的,比如一个顺序节点,顺序节点中一个子节点执行完毕后,马上通知顺序节点,顺序节点执行下一个子节点,直至顺序节点的最后一个子节点执行完毕,顺序节点就会通知父节点(如果有)它已经执行完毕。

此外,为了完成技能的一些需求,控制节点往往存储更多的控制信息来控制子节点的执行流程。具体的信息根据策划需求设置,比如顺序结点包括原子属性和循环属性。如果一个顺序节点具有原子属性,则这个顺树节点在执行的过程中并不会被end,只有全部子节点执行结束才可以end。

以我们游戏中战士普攻三段击为例:

![img](https:////upload-images.jianshu.io/upload_images/36361-5ec18bbce4b863ea.png?imageMogr2/auto-orient/strip imageView2/2/w/544/format/webp)

Paste_Image.png

三段击本身是一个顺序节点,当技能开始时,此节点顺序执行三个子节点。对于第一个子节点,它依然是一个顺序节点,首先冲锋至目标单位身前,然后对目标单位进行挥砍。但是冲锋节点还包括了一个condition,若和目标的距离很近,则跳过冲锋节点,直接挥砍。

普攻是一个循环技能,这个技能只要玩家点着按钮不放开,技能就会一直执行,因此根节点(普攻)是一个具有循环属性的顺序节点。而对于子技能1(控制节点),他是一个具有原子属性的顺序技能,即当单位正在冲锋时,玩家松开按钮,单位也会执行完挥砍后才会推出技能。


!关于技能树的使用和思考

技能树开始的设计思路是,有些技能的执行流程和行为树类似,比如以一定的顺序执行一系列子技能,比如根据不同的上下文确定技能的执行流程。简单的说,技能树的引入有以下好处:1.使技能模块可以获得部分AI的能力,从而将和技能强相关的AI逻辑放在技能模块使技能模块和AI模块降低耦合,2.可以清晰的描述技能流程,3.使用树增加拓展性,策划可以设计出各种各样复杂的技能。

关于好处1,举个例子:屠夫boss的勾子技能可以将玩家拉过来,若成功的拉过来,boss会执行一个攻击子技能,否则不执行。通过这样可以将勾人和攻击作为两个子技能构成技能树,攻击子技能有一个condition过程,即判断上一个子技能是否成功。

技能树在使用后慢慢发现一些问题,首先,技能树的同步要求每个树节点都进行同步,增加同步负担,其次,技能本身并不会有太复杂的控制结构。

为此,后来我们对技能树进行了优化: 1.简化同步信息,不再同步所有节点的enter/exit信息(具体参考文章《技能模块的同步》)。 2.取消并行节点,通过拓展表头实现一个技能同时执行多件事情。

最终的技能树基本上是只有顺序/随机两种控制类型节点,节点拥有较轻度的condition功能。


3.2 执行节点的技能流程

一般来说,技能的执行流程包括:

  • 前摇时间:技能开始,但是技能真正的结算流程还没开始。技能开始以后,机能相关的特效和动作就开始播放。
  • 前摇时间结束:技能前摇结束时技能开始真正的释放以及结算,等技能前摇结束以后,技能真正的释放并结算。释放包括创建相应的弹道/法术场和buff。
  • 技能后摇点:技能播放到后摇点时间时,技能真正的结束。这时,技能对应的特效以及人物动作可能还会继续播放,但是技能流程已经正式结束了。也就是说,下一个技能可以执行。

4 技能目标查找

技能释放时,目标可能已经由AI传给了技能模块,也有可能没有一个目标,如玩家控制单位。

技能在释放法术场、弹道的时候,重要的是技能的方向而不是技能目标一般来说,技能获得一个目标对象以后,技能的方向就是释法者到目标的方向。

此外,技能方向可能需要一些配置,如前摇锁定(前摇过程中目标移动,技能方向不变),UI可控制(技能释放过程中,玩家可以通过控制UI控制技能的释放方向)。

5技能表现

技能的表现包括动作、特效、shader、音效等。其中,特效比较复杂,需要配置的内容也比较多。比如,有些特效挂在模型上,有的特效挂在场景里。对于法术场的特效,分别可以分为法术场开始、结算、结束特效,分别在法术场开始时、结算时、结束时显示。对于buff也类似。

6 弹道、法术场和buff等技能创生体

狭义的来说,技能只是负责技能的执行流程(技能树管理以及技能流程管理),而技能真正的结算主要是由其创生体结算的。当技能前摇结束开始生效时,技能创建相应的弹道和法术场,法术场弹道击中敌人时又有可能产生相应的buff。

一般来说,法术场是一个场景的某块检测区域,每隔一段时间法术场检测此区域的敌人,并对其攻击结算。 弹道是一类子弹移动路径的抽象,创建一个弹道就表示一个子弹特效沿这个弹道移动并检测路径上的敌人。 buff就是挂在单位身上的一个具有持续时间的状态,状态对单位产生一些正面或者负面的影响,并且在此段时间内,每隔一段时间进行一次伤害结算 。

对于技能、法术场、buff之间的功能界定并不是很固定,比如技能能否直接对单位造成伤害,法术场能否对单位造成伤害,甚至技能只能创建法术场,法术场只能检测目标不能造成伤害,只能挂buff,而所有的伤害都是通过buff来结算。当然,这样并不一定好,一般来说,技能和法术场都可以对单位造成伤害。

总之,创生体功能的界定需要根据策划需求、效率考虑等因素调整。

6.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的数量,所以可以很容易的定义这些规则。

6.2 法术场

法术场描述对一块区域的影响,这块区域可以每隔一段时间进行一次检测,检测这块区域内的单位并且对单位进行结算。

法术场需要注意一个问题,就是一个法术场每次结算可能使用不同的参数进行结算,比如一个技能,第一次结算对每个单位进行晕眩,第二次结算对单位进行伤害。

解决这种问题比较直接的方式是技能直接创建两个法术场,每个法术场结算一次,第二个法术场创建具有延迟时间。但是这种方式有个问题,有可能策划需求做一个结算十次而且每次结算的参数都不同的法术场。那么,一个技能以一定的时间间隔创建是个法术场,同时法术场的管理具有一定的成本,从而导致效率的降低。

为解决这个问题,我们优化了法术场结算的实现机制,增加了一种新的法术场:序列法术场。这类法术场策划可以配置法术场每次结算之间的时间间隔以及每次结算所使用的法术场参数。

这里所说的技能模块包括:技能流程、法术场、弹道和buff。

首先介绍authority和proxy的概念,这两个概念是基于单位unit的基础上进行的区分。 authority表示单位的主控端,即此单位是由客户端和还是服务端控制。对于玩家avatar,玩家本地的客户端就是主控端。而对于怪物,他们的行为由服务端控制,主控端就是服务端。 proxy表示代理端,表示被主控端控制。如对于怪物来说,所有的客户端都是proxy;对于玩家A来说,服务端和其他玩家的客户端都是proxy。

0 技能同步的原则

1.客户端先行 对于玩家控制的单位来说,玩家点击按钮释放一个技能,客户端首先响应,单位播放动作以及相应的技能特效。

据我了解,有的已上线游戏并没有做客户端先行,而是所有的技能执行请求都发给服务端,然后由服务端发起。
这种模式技能流程控制会比较简单,但是在网络环境差的情况下,体验可能差一些。但是,目测也是可以接受的。

2.技能流程以authority为发起端 玩家单位技能发起是由她的客户端,怪物的技能发起是由AI也就是服务端。 3.技能结算在服务端发起。 技能真正的结算,比如法术场检测、buff结算、伤害结算等,统一在服务端处理。

1 技能执行流程的同步

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

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

一个技能执行节点的执行流程中,需要同步的有两个时间点:

  • 技能开始:技能开始播放动作
  • 技能结算:前摇结束,即能进入结算逻辑。这类同步消息往往并不是由技能本身去同步,而是技能生成了法术场、弹道等,他们去做相应的同步。

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

![img](https:////upload-images.jianshu.io/upload_images/36361-392299771fc34192.png?imageMogr2/auto-orient/strip imageView2/2/w/492/format/webp)

Paste_Image.png

1.主控端点击技能按钮,技能开始播放动作,主控端告诉服务端技能开始。 2.服务端广播给所有的客户端(多玩家场景),告知其他所有的客户端此玩家开始执行技能。其他客户端收到指令后可是播放技能表现。 3.服务端延迟一段时间后,服务端开始进行技能结算,并且将结算结果通知客户端。

延迟时间=技能前摇时间-上行-下行,下行一半不能确定,所以默认为上行=下行

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

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

1.要求技能前摇时间>2*网络延迟,若前摇时间短,则延迟时间=0,效果可能差一些 2.authority客户端表现完美。 3.proxy client表现一般,即玩家A看玩家B的效果为:玩家B刚开始执行技能动作,没到前摇时间就进行了技能结算。但是因为玩家一般也不会过分关注其他玩家的动作,所以是可以接受的。

2 技能树的同步

我上篇文章技能系统已经介绍,我们游戏使用的是技能树来管理技能流程。那么就面临一个问题,技能树如何同步。

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

后来发现,对于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、法术场和弹道都可能造成伤害,当服务端发现造成伤害时,服务端首先根据技能信息计算伤害值,计算以后将信息通过技能模块发送给所有客户端,所有客户端接到信息后首先播放技能伤害相关的表现,如受击特效等,然后播放跳字等通用伤害客户端表现。

buff可能修改单位属性,如攻击力、攻击速度等。单位的属性由基础成长属性+装备属性+buff属性构成,前两个属性为面板属性,属于玩家信息。而buff属性只在战斗中有效,在面板中并没有表现。 因此装备属性的同步需要通知逻辑服务器(真正的服务器),而buff并不需要通知逻辑服务器。

作者:水风 链接:https://www.jianshu.com/p/7abea2f0f755 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

技能,说穿了只是一个流程,而不该是一个实体

1、表的作用实际不是定义流程,而是提供流程中需要的数据。因此不管流程需要数据的是前端还是后端,他们都应该从一个表中调用。 2、并不是因为把技能作为实体才导致它的混乱,真正导致混乱是的技能实体的范围扩大化了(从这个意义上说,把技能做为一个流程也没什么错,技能的承载内容应该仅仅是这个流程本身),把后续效果剥离出来会好很多。

我个人的经验,不评价好坏,大概是这样的:技能的表象数据必须要有,技能效果相应的数据应该仅限于这个技能释放条件和它的直接效果(这个与表象共享技能id,所以最好也放在一起);直接效果之外的触发效果,单独建立BUFF表,为此建立一套单独的流程,供技能调用(也就是技能效果应该是触发了某个buff)

就skill和buff的边界问题,

恰好新的项目里里面我进行了一个比较新的尝试,就是抹除这个边界。 在这次的项目中,因为技能需求足够复杂,所以采用了以前一直只想没实践的想法,就是取消技能在逻辑中的的概念,或者说在基础逻辑中没有技能的设计,技能只在数据层和讨论的概念中出现。 具体的描述也很简单,所谓的技能我们都理解为 施法者一组行为和数据的组合,它包含了技能的icon,类型,动作等一系列和战斗逻辑有直接关系但没有本质关系的概念与数据的总和,用来在游戏概念中定义一个技能的所有特征。 但是在战斗中,真正发挥作用的是buff,在新的设计中,所有的参与战斗逻辑的实体都是buff。 比如 如果要实现一个火球,那么实现方式是技能数据告诉我会播放什么样的施法动画,同时丢出一个弹道,而这个弹道上附着一个buff,叫做燃烧,该buff附带特效火焰和200点的碰撞伤害(在弹道命中敌人时候)。 而这个一整个流程,在概念里,被定义为 施法者释放了一个技能,映射到现实逻辑,就是某人拿起一个石头,点燃,然后把石头丢出去砸到了某人。 至此,核心的技能结算逻辑里,彻底干掉了skill这个类,技能变成了只在概念讨论里才出现的词汇。战斗结算中,不再存在skill的概念。

表与脚本混合.

又有两种分支,

分支一:主表副脚本,脚本作为字段绑定于表里.表的某个字段就是技能的脚本路径.技能的主流程,框架逻辑有表的字段来决定.

分支二:主脚本副表,主逻辑,流程都是有脚本实现.技能的主流程由脚本实现.脚本读表获取数据,进行技能的操作.

优点:增加奇怪技能,很方便,直接写脚本就可以了.

缺点:批量处理工作量大,既要改表,又要改技能.每个技能对应独立的脚本,技能越多,脚本越多.批量处理的时候,工作量大.

分类:

更新时间:

留下评论