游戏机制设计3：技能系统的设计思考过程

侬去斯

写在前面

正式复工之后工作繁重，平日里几乎没精力考虑工作以外的东西，只能抓紧周末的时间来写文章、做视频。
印象中已经有一段时间没有写游戏策划内容的文章了，我原打算写一篇关于“随机生成算法”相关的关卡设计文章。可惜涉及到的知识点颇多，有点儿难产。
翻阅之前的文章，发现我去年写过两篇讲述设计思考过程的文章：
这个系列还是很有意思的，恰巧我这段时间正在研究Unreal的GameplayAbilitySystem插件（官方提供的一套技能系统插件），所以这篇文章就和小伙伴们一起聊一聊关于游戏技能系统的设计思考过程吧。
行业现状

在正是讲解技能系统之前，我们先聊聊我所知的行业现状，完全是我主观的理解，可能有说的不对的，欢迎指正。
在过去几年，手游被清一色的卡牌、MMO充斥，同质化十分严重。在这种情况下，从无到有设计一款游戏的技能系统是几乎不可能的，没有必要、大部分情况是在已有的技能系统下进行扩展、微调。而游戏中的技能设计、则更多是由数值策划完成的。
但近年来因为手机市场基本饱和，智能手机新用户明显减少，手机游戏的营销策略也逐渐从换皮买量变为走精品路线。市场上也开始涌现一些以技能设计、战斗系统作为卖点的ACT游戏和MOBA游戏。就如同PC网络游戏所经历的过程一样。
很多大型团队，特别是动作作为核心卖点的游戏，则会增设“战斗策划”这个职位来满足日益繁重的核心战斗系统工作量。通常，战斗策划由数值策划进化而来。因为要设计好的战斗体验，通常要足够了解各种属性的含义、伤害公式的差异等等。可以说，不懂数值的战斗策划路子一定走不远。
关于战斗策划的职能，之后我们会专门用一篇文章来做介绍，这里就不展开来讲了。
之所以在正是讲解文章前，我们会介绍一下行业现状，也是跟大家（特别是一些经验尚欠的小伙伴）分享一下。类似技能系统这种涉及到游戏核心玩法、又十分底层、独立的系统，通常是没机会重新设计的。而我们更多要做的就是总结一套技能系统的通用规则，举一反三，在之后的项目中知道哪些是优秀的设计，还缺少什么。然后在现有系统的基础上去优化调整。
数据驱动

也许我本人是数值策划的原因，所以在设计一个功能的时候，优先想到的就是“数据驱动”。
所谓数据驱动，就是将可能变化的因素全部抽象为可通过数据表修改的配置项。这样做的好处显而易见，
就是在之后的业务扩展中，可以在尽可能不折腾程序员的前提下，通过配表实现更多的技能效果。
但是我这里也要特别说明一下，特别是对于一些系统设计者来说，千万不能“迷信”数据驱动。
对于系统设计者来说，将关键信息设计为“可配置项”似乎并不困难。难点在于怎样判断一些关键数值的价值。换句话说，不清楚系统的设计目的，在系统设计过程中缺乏主见，一味地要求数据驱动，系统的可扩展。反而会造成系统的开发更困难，BUG更多。而这种问题则更容易被开发者忽略。
回到技能系统的数据表结构设计上来说，首先就是考虑将逻辑和表现分离。
首先就是对于技能Ability和技能效果Effect的分离。
一个技能Ability应该是若干效果的集合。
通常，技能还包括技能消耗、CD时间、前后摇动作（技能生效时刻的前后动作）等
此外，技能通常会选择一个目标，这个目标可以是游戏中“单位”（自身角色、敌方角色、友方角色，可以设根据游戏设计一个枚举系统）、某个点或者是以某个点为中心的一个形状（扇形、圆形或者方形）范围内。
最后，在RPG游戏中技能通常是有等级的、等级伴随着属性成长。
而效果effect顾名思义就是真正产生的各种游戏效果。这种效果包含属性和状态两方面的修改。
为什么说一个技能是由多个效果组合而成的，为了技能系统更加的灵活可拓展，通常一些我们耳熟能详的技能效果其实是多种效果的组合，比如：

眩晕：限制移动、限制释放技能、播放眩晕动画、播放眩晕特效

对于属性的修改则更为简单、直观，比如：

生命值-20

但是咱们上文中说道，技能通常是有等级的，而这个等级会被效果继承。并对效果的数值产生影响，同样的一个技能，因为等级不同威力也有所不同：
等级效果1生命值-202生命值-303生命值-40
一些技能系统会将效果中这种对数值的修改抽象出来，比如我上文中提到的unreal的GAS插件，就有modifier。
所谓修改器，就是对游戏中的数值进行修改的时候可以读取一个和等级相关的数据表。
而一个效果Effect则可以包含多个修改器Modifier。
至此，一个最简单的技能系统的分表结构就梳理清楚了。
但是，我们似乎忘记了游戏中最常见的一类技能效果——BUFF
我见过一些极端一点儿的技能系统会将所有的Effect看作是BUFF，换句话说，当我对敌人造成伤害时，我其实是给对方释放了一个获取瞬间就会释放的BUFF。
如果这么说不太好理解的话，其实我们可以换一种思路。考虑一下Effect的触发时机。
上文中我们其实是默认Effect是在技能释放的一瞬间就触发的。但其实我们完全可以添加一段逻辑来左右Effect的触发时机。
最常见的触发时机就是根据时间：立刻、周期执行、计时结束时执行。
此外，一些和玩法紧密相关的触发机制也很常见：目标死亡时执行、目标被攻击时执行等等
触发时机通常是在项目开发过程中逐渐丰富的，在设计系统是不需要（也不可能）想出全部的可能性。
主要搞清楚触发时机这个概念，其实我们的Effect就可以作为Buff使用了。
当然，除此以外，Buff还包括覆盖关系、显示图标等其他逻辑，本文也不展开说了。
标签系统

在一些以技能系统作为核心玩法的游戏中，比如MOBA类游戏中，技能之间相互影响、干涉，比如：

造成20点伤害，对于被眩晕的目标，伤害+20

这种技能效果，不同的技能系统给出了不同的解决方案。而对于GAS而言，则是通过标签系统来解决类似问题。
标签系统是Unreal引擎提供的另一个十分实用的系统，旨在通过标签筛选出我们感兴趣的目标。这种思想有些类似ECS中的Component，只包含数据不包含逻辑。而标签更纯粹的只是描述某种状态。
技能效果通常可以给目标或释放技能的单位添加某个标签或者移除某个标签，并且在技能效果生效前根据标签进行相应的筛选。
回到上文中举例的技能效果，在加入标签系统之后就很简单了，只需要在释放眩晕效果的技能时，顺便给目标贴上“眩晕标签”。然后，这个技能只需要包括两个效果，其中一个效果就是常规的生命值-20的修改器，而另一个效果则是判断当目标有“眩晕标签”时才生效的生命值-20的修改器。
脚本扩展

正如我上文中说的，不要过分痴迷于“数据驱动”。当一些通过配置难以实现的技能效果确实存在时，如果过分要求数据配置的可能性，可能导致的结果就是代码和表结构的易用性都变差。这是得不偿失的。因此我们可以在配置表中留出一列，供给程序回调表格中向的代码（通常是使用Lua编写）
一些小伙伴可能会纠结游戏策划究竟需不要会编程语言。事实上思想比具体实现更重要，上文中的这套技能系统其实已经需要一定的编程思想才能驾驭。但如果你的工作内容是战斗策划，那么你通常需要掌握一门脚本语言。如果你的项目是使用Unreal的话，那么你大概率也需要掌握Blueprint。
但是对于脚本的使用应该相当克制。作为设计者我们应该清楚其中的原因。
在一个技能需求确立之后，我们首先考虑使用现有数据表结构能否配置完成需求。
如果不能，则要考虑这种需求的通用性，对于通用性较高的技能效果，应该向程序员提出需求，及时的拓展枚举或改变表结构。
只有在以上条件排除的前提下，才需要我们策划自己动手编写一些扩展效果的代码，并且在编写的过程中也要注意逻辑和数据的分离，尽量不要讲数值藏在脚本中，这样在后期的维护中会很可怕。
最后

《游戏机制设计》这个系列，我会尽量将游戏中一些偏底层的、独立的模块的设计思考过程整理成文章和大家分享。
之所以只是介绍思考过程，一方面是因为正如我上文中说的，这些底层系统通常没什么游戏策划可发挥的，更重要的是，我们在加入一个项目时可以更快的适应项目的工作流，所以讲述思想比具体实现更可贵，毕竟：

授人以鱼不如授人以渔

我是老李，一个游戏人
除了游戏不会别的
我们下篇文章再见！