技能

如何设计一个易扩展的游戏技能系统?

  参与过几个游戏技能系统的设计,最近也在自己的习作中沉淀这个东西,后续会发github上。

  结论上,可以考虑用某种脚本语言来做行为流程,这样,在流程扩展性方面,自由度可谓近于无限。

  但是这不就是“每个游戏新做一套技能系统”吗?也不是,这个的重点在于,(抽象的)概念结构本身的稳固性,以及针对概念结构、所提供的工具箱和模板的丰富程度。简言之,所有现有的技能模式,通过你的系统都搞过一遍,积累了大量的模块,那么接下来新的游戏,大凡也只需要处理简单的模块耦合即可。

  在流程制作过程中调度数据配表(ini、csv、db),铺量过程中使用配表,方便性可以得到兼顾。

  个人建议,不要试图在一套配表中解决所有问题,即便你可以解决所有已知问题,未知的未来也还在等着你。而且,什么都能做本身也就意味着配表会极其复杂,可能远超当前参与项目的实际需求,需要终端维护者付出更多更大不必要的心力和成本。

  我之前也追求大一统无所不包的设计,但是后来发现,这样的设计最终导向“做一个新语言吧”这样的思路。当一个配表无所不包的时候,认真想想,这个配表跟一套脚本语言还有多大的区别呢?

  现在更加注重针对目标系统本身的特质,利用积累的模板和工具箱,做一套不那么统一但是却足够调和的专门系统。个人理解,当积累的模板和工具箱足够多的时候,这个专门系统的开发代价可以小很多。

  表格+流程:表格不能自我进化,无所不包的表格已经差不多是个脚本了。脚本提供运动性、表格提供静止性,动与静,辨证统一。

  ## 目前:Skill本身的概念再分割:数值部分 和 Sequence部分,同步性的再探讨

  数值部分:技能本身的保有、学习环节。带有技能的道具。以及技能本身的可使用性验证和前置目标需求。

  技能过程Sequence部分特指 行为Graph,是指一个技能经过验证而开始后,所有动作和行为逐一展开、直到全部执行完毕这一过程。

  如何在脚本过程中简化同步性,用更好理解的方式,隐藏各种同步需求带来的复杂度?

  * 可操控的游戏单元,在玩家操控下,通过此单元的行为(动作和飞行道具),用以打击其它游戏对象或者获取自身数值影响。 *

  - - 作为技能主体,其状态对于技能有影响,比如,可能在死亡时强制打断技能流程。

  - - 游戏单元的Sub Parts分解:上下半身视为不同的Sub unit。简单点理解,坦克炮的技能、和坦克本身技能。上下半身分解后,“移动中同时进行技能”就很方便了。

  - 玩家操作User Interaction:这里特指技能过程中的玩家交互

  - - 特殊的单元行为:非技能过程处理的、游戏特色的、脑洞大开的特殊单元行为,比如吹散周围的烟雾、截个屏、退出游戏、重启电脑、格式化硬盘之类的

  - - 游戏数值和状态服务,与表现过程分离设计(装作自己在C-S模式下)。

  - - 整体流程同步,还是将特定状态单独同步。(技能过程只在服务器跑,还是在C-S都跑?)

  - - 表现力考量下,客户端预播的必要性,以及后续的多种可能性。Local预播-Server广播,之后Local和Remote Clients可能不同的表现力。

  此外,虽然Skill过程与游戏单元有关联,但是可以考虑把Skill过程专门交由一个管理器来管理,这样游戏单元本身的动作结束后(甚至其代码级别的对象生命期结束),其施放的飞行道具也可以有地方做统一的管理和调度。

  技能过程,这个概念更多聚焦于技能运行过程中,单元自身Action、发射飞行道具、同步过程的管理,也是技能最千姿百态的地方。

  作为技能(物品)的概念:可以将技能理解为某种广义Item,从属于游戏单元的技能背包,需要经过学习进入背包,通过遗忘移出背包。其他系统可以通过背包获知某个或者某些技能是否存在,乃至其当前属性。

  作为技能(单元行为)的概念:使用行为前需要有预判定,以及目标的选择。同时,作为单元行为,可以入队(War3的Shift+施放,将其记录进单元的行为队列,延后执行)。

  具体的系统设计,基本上都是按照上面列举的概念来做分解,请容全部做完后结合实例来详细分析。

  技能系统核心功能有两个,一个是定义表现流程,一个是处理逻辑效果。所谓表现流程就是角色在什么时候播放什么动画、特效、音效,什么时候判定伤害,什么时候发射抛射物。 所谓逻辑效果就是技能给目标造成多少伤害,附加什么buff/debuff效果。

  在我设计的技能系统中,核心基础是lua脚本,通过lua脚本处理复杂的技能逻辑。

  1、Actor,这个是角色本身,它不属于技能系统,但是它要给技能系统开放足够的接口,比如播放动画、播放声音、控制位移、造成伤害、添加buff等等

  2、Skill,这个就是技能本身,它在合适的时机调用脚本中的相应函数,脚本中可以在OnCreate OnHit OnDeath OnHeroDeath OnSoldierDeath等事件中写相应代码。由于是脚本,所以代码非常灵活,而由于限定了只处理技能相关功能,所以代码也不会很复杂,有经验的策划绝对搞的定。

  3、Buff,这个是技能效果的核心。它可以是有时限的,也可以是被动无时限的。在它对应的脚本中,定义了这个Buff会影响哪些角色属性(如血量、暴击、攻击力等等)或者角色状态(如眩晕、隐身、沉默等等),同样,buff脚本也支持事件机制,在脚本的相应事件处理其逻辑功能,可以实现非常丰富的效果。

  4、Modifier,这个是一个技能修改器。技能修改器可以修改技能的流程和效果(比如技能伤害增加、火球击中人会爆炸等等),具体可以参考风暴英雄中的技能天赋系统。技能修改器并没有脚本与之对应,一个技能如果支持某个修改器,需要在脚本中处理相应功能。

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

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

  ## 0技能表首先说下实现技能的基本思路。实现技能的基本思路就是通过策划填写表格,来配制成某些技能,在执行某个技能的时候,分别去根据这些表格中的内容,确定技能如何表现。基本的逻辑是:```if skillTable.get(技能动作):paly 动作if skillTable.get(特效):播放特效if skillTable.get(法术场):创建法术场....```##1 技能信息管理unit创建时,此模块管理unit可使用哪些技能,比如游戏中玩家可以选择使用哪些技能。

  ##2 技能调用接口提供技能调用的接口供AI调用,调用时可以提供一个目标unit,也可以不提供让技能自己查找。

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

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

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

  2. 一个具体的技能(技能树执行节点)也有一个固定的执行流程。这个流程一般为:前摇过程、前摇过程结束=技能结算时间点、后摇时间点。

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

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

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

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

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

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

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

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

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

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

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

  我个人对这个问题非常感兴趣,因为我花了至少5年在设计和实践(我自己经历了大小7个项目,虽然大多最后因为其他原因都没上)这样一套机制并且可以说

  我并不想藏着他,我也和很多朋友分享了,同时也感谢他们提出了很多意见,包括细节和优化等方面,正因为互相之间的借鉴和交流,我到今天已经把这套机制归纳的非常好了,还是想把它分享给更多想做好游戏的人,

  希望大家能进一步交流,把它更完善化,以形成一种规范,这套机制适用于任何类型的游戏开发

  你并不知道策划下一个设计的是什么,但是你需要在尽可能不改动核心代码的基础上去把它实现了,并且在调试的时候(甚至是上线之后要做调整的时候),你可以并不伤筋动骨的去修改它。

  最早开始想这套机制的动力是因为我在起凡工作,看了代码之后我感觉是完全无扩展性的,当我想要设计一个新的英雄的时候,要去修改代码已经几乎是不可能的了,于是我便思考,如果我要做一套WoW的技能、buff系统,应该是怎样的呢?于是我总结、归纳、抽象了这样一套东西,并且最早在三国争霸2项目中投入实际使用。

  实际上,好的策划的脑洞是非常大的,你真不知道他会设计出什么样的技能,但你并不能说一些设计因为无法实现就理所应当被埋没了,(我对策划设计Dota类游戏的思路要求是开放的,发挥想象力的:[设计思想] 游戏系统设计思路的牢笼 一味追求实用性)因此我想了这样一个机制,他们的核心在于:

  1,明确区别了AOE\Buff和技能3块,策划应该从这个角度出发思考问题。

  2,这既然是一套机制,你可以把它用在任何游戏的框架当中。比如我要做一个Dota传奇的卡牌游戏,一样可以用这套机制,但是核心在于——你的策划要有能力归纳出游戏中的回调点。

  ,尤其是当我们的战斗在服务器上一瞬间完成了,但是要把结果告诉客户端吗,并且有客户端重新验算一遍的时候,因此我在之后有总结了一套作法,来完成这个事情:

  这个解决的是,当你有各种有趣的buff,但是又想不大改客户端的时候,你应该这样去建立这个框架。你可以想象如果你做一个MT类型的游戏,战斗是服务器一瞬间的,但你又要客户端重演,我们举个例子:

  比如我门设计了在MT类型游戏中加入地形因素:可以有火海,火海每回合开始的时候对所有场上敌我英雄造成火焰伤害。

  2,战斗中第一次死亡可以复活,回复最大生命值50%,如果在火海中则回复100%。

  这样一个英雄和地形,我们如何实现呢?如果你看了我上面的几套机制,并且理解了,那基本没有难度,你根本不需要硬编码。但这里有个问题,我如何让客户端重现?这就是上面这篇说的关键了。

  ——————————2015 08 15 更新一条 ——————————————

  看来感兴趣的人还是不少的,于是我发了一些关于这套机制的实际运用方式在GameRes上,主要是想说——

  推荐看一下Dota2的技能系统,完全的数据驱动,可以捆绑lua脚本进行复杂的逻辑操作。

  主动技能:特定情况下可用-执行表现,在特定时间在对特定区域对特定敌人-产生特定效果-一段时间内产生效果/瞬间产生效果

  ps:buff之所拆分为独立的模块主要是buff有很多有的特性,比如buff叠加层数,buff标记用于驱散,目标筛选,表现等等

  而子弹集本身可以调用到包括子弹在内的3个模块(入口统一可以监控各种效果)

  如此,通过各种事件调用子弹,使得技能系统可以在各种情况下让指定的目标产生指定的效果

  扩展时,主要看新东西加在哪一块(小功能,子模块等),或者在新的事件中调用子弹组

  比如把子弹集的每个子弹扩展为子弹组,一次可以调用多个按特定规则排布的子弹

  又或者增加一个触发器类型,增加一直即时效果,本质都是在原有架构内增加小内容

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

  被动技能-获得buff-buff触发器每2秒在自身位置释放单体子弹1清除buff1,aoe子弹击中敌人-每命中一个敌人对自身叠加1层buff1

  玩家释放技能1-释放子弹1对自身周围友方和敌方击中-对命中的目标释放3个子弹:子弹1筛选敌人产生伤害,子弹2筛选友方30%血以上造成治疗,子弹3筛选敌人血量大于80%命中后产生子弹4对自身添加buff

  实际效果:对周围友方残血造成治疗,对敌人造成伤害,如果击中的敌人血量较高,自身获得增益

  玩家有被动技能获得buff1-buff触发器效果为暴击击中时若双方距离300则对目标发射子弹1和子弹2-子弹1对自身添加buff,子弹2筛选有buff2的敌人

  技能效果:暴击击中距离自身较远的敌人使自身获得增益,触发时若敌人有buff2,则造成额外效果

  buff2-触发器每1秒对自身附近发射子弹筛选1个敌人-令目标对自身发射子弹添加增益

  技能效果:主动隐身,受到攻击失去1层,释放技能后解除隐身,隐身结束后一段时间内受到伤害转移给附近一个敌人

  从架构上说,主动技能都可以拆分为释放条件检测-释放-目标选择-产生效果

  但是里面很多细节,比如子弹初始位置设置,做成什么样子组合出更多的设计形式,同时可以兼容更多的有效需求

  比如一个回合制卡牌游戏,要啥飞行子弹,区域只要相对和绝对位置2大类,然后直接填坐标就好了

  被动技能和buffer是由于一些事件触发的技能,通常是加buffer或执行一些指令,也有对应的被动技能和buffer编辑器如下

  其实你问的主要还是Moba类的,和MMO是有一定区别的,MMO如果在大世界放技能,那么涉及到分布式数据的同步,显然对性能要求高一些,对代码复杂度也高一些。但是MMO的技能其实很多实时性又没那么高(例如锁定机制,也就是目标位移不影响索敌判定),这种又比Moba类技能简单一大截。所以设计前 先搞清楚你想做什么类型的游戏比较重要,没有策划说咱们做一MMO的Moba吧,什么东西都要,你给我全实现了,你就算实现了他表也配不明白。

  第二步,拿Moba举例子吧,技能系统本身并没多复杂,复杂的确实是如果应对极其变态的各种乱七八糟的特殊需求,这些需求你很难用一种统一的规则去描述,不如锁圈,打扇形这种。这时候如果希望对代码量改动小,你的抽象系统就需要做的非常完善,将技能可以完整的拆分出来,只是组合出新技能的配置、调试功能都是巨大的。

  Entity、Space、Creature,我们分别管他叫实体系统,场景系统和创生体系统。 这些东西之间的交互构成了技能的基本要素

  索敌系统,释放前,释放时,以及生效时(可能多次引导生效)的命中对象选择(例如打血少的,打血多的,这个东西可能被技能被动选择),也涉及到你的技能是否能释放等问题,这是个很复杂的系统,可能很多和模型、位置信息相关联。

  技能阶段划分,释放前,前摇,吟唱时,释放时,引导时,生效时,后摇,释放结束。 每个可能持续一段时间,也可能是某帧执行的一次行为,总之阶段决定了技能的各个时机(也包含了离开条件、进入条件等), 注意到打断行为和这个系统息息相关,如果做到打断规则的注入是一门学问,例如前摇打断,前摇刚体不被打断,后摇打断(某些格斗向技能包含取消系统)

  效果系统,技能想产生作用,一般用效果系统去实现,效果是针对目标的(或者目标点,目标范围等),可能有延迟生效,但一般生效就是一刹那,也就是产生结算行为。 结算的流程更加复杂,但更多设计向内容,按照流程图去实现代码即可。当然需要处理好结算的各种顺序、注入、免疫规则等,还包含例如真实伤害、魔法伤害、闪避、暴击、吸血、抗性、韧性、硬直、护盾等内容,相当的复杂。

  Buff系统,效果如果延迟生效,一般考虑用Buff机制实现,同时Buff也可以做到相当多的例如护盾、状态改变、属性改变等属性向的影响,也包含了对技能本身能力的修正和加强。一般技能系统中Buff是最复杂,最灵活也最能实现特殊的技能效果。因此对Buff系统的设计强关联到你一个技能系统的扩展性。

  创生体系统,技能想放火球咋办,火球飘的过程中动态结算,则必须以创生体的方式处理,有自身的tick行为、位置信息甚至属性、状态。特殊的, 召唤物系统可以是复杂的创生体。但召唤物如果很复杂,通常用Entity实体系统去实现(依照组合、继承等方式,因为和实体太像了),创生体提供了简化的Entity行为(极大的优化了场景内实体运行效率)

  场景组织系统,乍一看和技能本身没关联,但是对技能索敌关系重大,每个Entity、创生体的移动都对可攻击目标造成改变,一个大场景大量实体跑来跑去,没有精确高效的场景管理,你整套系统的性能和效率破败不堪。通常大平面场景下用十字链表系统管理是相当高效的。

  有了场景组织,我们就可以实现触发器系统,触发器可以想象成地雷,玩家踩过去就爆炸。触发器挂载技能,但是也会侦测进入的玩家。触发器做的事远不止这些,例如改变场景行为(例如下雨,那么火球术都失效)。

  另外还要考虑一些周边简单的小系统,例如阵营、仇恨、生存机制(结算和插入结算,例如不死技能)

  抽象出具体的系统来,推荐使用ECS系统去实现整套方案,它具有比较好的解耦合性,可以为不同的模块单独定制,你希望增加索敌策略,或者添加一个天赋系统来修改技能效果,都可以扩展的方式去编写,而无需用纯代码的方式去硬编码技能效果。

  拆分的越细致,耦合性越低,你的系统越原子,扩展性就越强。实现完一看,什么特殊技能都没有,但是策划拥有配置任意技能的能力,这样会让你的代码纠错、调试难度都降低很多。

  谢邀,不过这块好像也没啥可说的,这几年主要的改变就是 “表格化” 了。以前一个新技能或者一个新buf都需要编写相应的代码,规模上去以后,修改频繁,这样的方法经常造成开发效率底下以及bug多的问题。虽然有些游戏引入了局部表格化的方式,但是还是不够彻底,更多的游戏使用了完全 “表格化” 配置。一共三张表:技能表,buf表和道具表。程序只实现字段,修改和扩充都由策划完成。程序做一个配置检查工具,检查策划的 excel写的对不对。每个字段不但可以写一些具体数值,还可以写一些小的公式和脚本,比如:DF += 3。程序读取表格的时候,将表格转换为 python 或者 lua 脚本,运行时 import 即可,或者每次运行载入时再翻译也没啥。

  限于知识产权,具体表格的字段,不方便直接提供。但其实也没啥,自己归纳总结一下,不断扩充即可。一般情况,一个表格有100个字段很正常,一个技能表格上千行也很正常。不当技能表格化,道具表格化,包括任务系统,新手教学,同样可以表格化。程序要做的就是一个强大的表格解析系统,需要扩充时扩充字段即可,剩下的事情,让策划来做吧,策划写错了,QC自然会给策划提 BUG,你时不时还可以问一下策划,你的bug到底改好没有?

  影响BA的数据有很多,比如移动速度 攻击力 基础属性 等等,影响的入口也有很多

  首先我们先谈区别,对于这些数值影响,其实区别只有入口或者说是作用的方式

  技能是BA(castor)对BA(target)释放造成的瞬间数值影响

  buff是castor对BA(target)安装后造成的持续数值影响,分为按时触发瞬发和持续修改数值

  class PropChangeEffect implements Effect{ public void cast(BattleAgent target){ target.atk = 0; target.def = 0; target.speed = 50; } }

  然后把这个TriggerBuffEffect加到技能能上就ok了,就完成了一个可以变羊3秒的技能

  @王敬哲在他的答案里提到个有趣的问题,就skill和buff的边界问题,恰好新的项目里里面我进行了一个比较新的尝试,就是抹除这个边界。

  在这次的项目中,因为技能需求足够复杂,所以采用了以前一直只想没实践的想法,就是取消技能在逻辑中的的概念,或者说在基础逻辑中没有技能的设计,技能只在数据层和讨论的概念中出现。

  具体的描述也很简单,所谓的技能我们都理解为 施法者一组行为和数据的组合,它包含了技能的icon,类型,动作等一系列和战斗逻辑有直接关系但没有本质关系的概念与数据的总和,用来在游戏概念中定义一个技能的所有特征。

  但是在战斗中,真正发挥作用的是buff,在新的设计中,所有的参与战斗逻辑的实体都是buff。

  比如 如果要实现一个火球,那么实现方式是技能数据告诉我会播放什么样的施法动画,同时丢出一个弹道,而这个弹道上附着一个buff,叫做燃烧,该buff附带特效火焰和200点的碰撞伤害(在弹道命中敌人时候)。

  而这个一整个流程,在概念里,被定义为 施法者释放了一个技能,映射到现实逻辑,就是某人拿起一个石头,点燃,然后把石头丢出去砸到了某人。

  至此,核心的技能结算逻辑里,彻底干掉了skill这个类,技能变成了只在概念讨论里才出现的词汇。战斗结算中,不再存在skill的概念。

  目前该设计运行良好,在策划一段时间适应后,变得相当容易理解。不存在任何所谓 skill和buff边界问题

  编辑器对策划要求比较高,如果策划素质堪忧,尽量写死,给一些简单的参数配置就好。此为前言。

  说了前面,那么一个技能,基本上就和AI差的不多了。有很多成熟的行为树编辑可以作为参考,但是还是那句话,这个东西对你们策划要求和程序要求都要高一些,如果能力不足会容易长期填坑。

  高低级上下限距离尽量拉开点,多跃进,少渐进,注意多少和有无的差别。低级破上限或者高级破下限,意味着禁招和废渣。

  MTG里,一张好像有点强但实际没什么卵用,加一张莫名其妙,可能等于一个超强组合。两张的bug级combo基本上都死在设计阶段,但是三张、四张的组合呢?隐蔽性就大多了。想想电压钥匙,别忘了备忘夹。

  D&D三版,5级是个坎,因为LV5开始施法者就有3级法术了。3级法术最典型的两个例子,火球术是AOE的起点,飞行术让战场进入立体。单体到群杀,平面到3D,这就是维度变化。

  提升相关性和维度,会让游戏复杂程度急剧上升。参考某卡牌游戏“一个武将技多了个子系统”。

  再举个例子:一张同时涉及相关性和维度的牌,《武装飞腾》,2WW,生物结界,每操控一个平原就+1/+1带飞行,关键时刻一脚踹爆。当然被《送终刀锋》就是一换二,顺带一提《送终刀锋》也可以算维度攻击。

  还有怪物,是否跟英雄共用一套计算流程。英雄攻击单个怪物的次数有限,怪物攻击英雄的累计次数无限。英雄打个暴击秒了怪物皆大欢喜,怪物暴击秒英雄事情就大条了。

  好像以前有款Sid Meier出的星际slg游戏,大概03年就有了,就是有星际会议,根据民主投票结果改变规则。

  易扩展指开发扩展还是玩家扩展?我觉得lua的那种数组结构比C容易扩展多了。用了LUA都不想用C。

  最近挺流行行为树不是吗,那种结构就是一个可行案例。实际上也完全可以直接用来实现技能系统,虽然不专业(或者说过于泛用导致臃余数据过多,用起来比较繁琐)

  我的案例其实是抄袭的几个国外游戏(扒配置数据)总结出来的,他们的结构其实很类似。

  中国做卡牌,做回合制的人太多,这种简单的需求下,自然怎么做都行。但是遇上稍微复杂的需求瞬间就会瞎。(举个例子,弹幕)

  行为树那种模式完全可以,就是太自由了,操作起来效率有点低,一个简单的技能可能会铺出一个很大的树,可读性也很差。

  我这个本质是试图将buff,技能,单位抽象化为一种东西(因为他们有生命周期),然后利用事件和行为在不同实体间通信。比起行为树起码更加面相对象一点(而且内部也会用行为树来处理ai)

  本质上,一个所谓的技能系统,是试图用数据来重新描述代码。所以行为树完全符合要求。但是直接用行为树又太自由了,和写代码实现难度也差不多了(还更麻烦),所以需要一定的限制和约束。

  优点:批量处理大量技能,维护方便(前提是策划不要脑洞太大,想出一些某名奇妙的技能).

  缺点:字段多,亢余字段多.增加新的奇怪技能时候,心智压力大,需要考虑与整个框架的耦合.

  技能的特殊功能只读取info字段,根据info的内容进行解析.甚至可以把一个树形结构体存在info字段,程序解析info就是了.

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

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

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

  总结,没有标准答案,纯读表方案,只要字段够多,根据排列组合,理论上也能实现无穷无尽的技能,但是字段那么多,对于策划和程序都是巨大的心智负担.但是好处明显,数据驱动,只要改表,不需要改代码,就能制作新的技能.纯脚本,实现demo原型验证的效率实在够快,比如制作独立游戏,在做玩法验证的时候,纯脚本方案,可以直接开始撸,而不用考虑对框架的耦合限制.混合型,字段不多,脚本也不是那么多,但是修改技能.单单改表不行,还要改脚本.

  所以如果策划牛逼,纯读表好.策划菜比,纯脚本好.其它情况?策划说的算...

浏览过本文章的用户还浏览过
  • 开封:深入开展职业技能提升行动

    磨炼技能展风采 ,生活就业更美好。12月12日,记者从市人社局获悉,广受社会关注的开封市职业技能提升行动,目前正如火如荼地进行着。未来3年,开封市将精准发力,推动职业技能 [详细]

  • 面试技巧都有什么?

    面试开始时,应试者不善破冰,而等待面试官打开话匣。面试中,应试者又出于种种顾虑,不愿主动说话,结果使面试出现冷场。 即便能勉强打破沉默,语音语调亦极其生硬,使场面更 [详细]

  • 简历个人能力怎么写

    在写个人能力的时候要把能力具体化,达到了那种程度,字数尽量要多,要详细结合到你平日的兴趣爱好,学习,实习中,才不会让用人单位看着你写的能力有种虚无缥缈的感受。且在 [详细]

  • 梦幻西游大唐学什么剧情技能最好

    可选中1个或多个下面的关键词,搜索相关资料。也可直接点搜索资料搜索整个问题。 梦幻的剧情技能只有2个是最有用的,一个是丹元济会、一个是变化之术,这两个技能不仅是大唐最 [详细]