GAS 是什么？

在续上一张序章表明为什么我想写这个文章之后，我发现我还没介绍什么是GAS呢。

GAS的全名为 Gameplay Ability System，是Unreal Engine提供的一个框架。

我目前的理解是：GAS 不是单纯用来做一个技能，而是用来管理一整套角色能力系统。它可以帮助我们处理技能、属性、状态、Buff、Debuff、冷却、消耗，以及特效触发这些内容。

也就是说，当游戏里面的技能和状态开始变多时，GAS 可以让这些东西用比较统一的方式被管理起来。

Ability是什么？

Ability 可以先简单理解成「角色可以执行的一种能力」。

比如玩家按下一个按键，角色就会根据这个输入执行对应的动作。这个动作可能会播放动画、消耗资源、进入冷却、生成特效，并且对游戏世界造成某种影响。

以 Dota 为例，当我按下 R 释放大招时，从玩家角度来看，这只是「按下 R，然后放出大招」。

但从系统角度来看，里面其实有很多问题需要处理：

• 这个技能现在能不能释放？
• 角色有没有足够资源？
• 技能有没有进入冷却？
• 角色是不是被沉默或眩晕？
• 技能命中后造成多少伤害？
• 要不要播放动画、特效和音效？

GAS 想解决的，就是当这些规则越来越多时，系统该如何保持清楚。

那么没有GAS，跟有GAS的区别在哪里？

如果没有GAS，比如我要做一个火球术，可以直接在 Blueprint 或 C++ 里写：按下按键、检查 Mana、检查冷却、播放动画、生成火球、命中敌人、扣血、播放爆炸特效。

但问题是，当技能数量越来越多时，每个技能都可能开始有自己的判断逻辑。一个技能要判断冷却，一个技能要判断资源，一个技能要判断角色有没有被沉默，另一个技能又要处理 Buff 或 Debuff。这些逻辑当然也可以通过 Base Class、Interface 或 Component 来复用，但这些复用规则都需要我们自己设计和维护。

有 GAS 的情况下，我们可以把这些常见的部分拆成几个比较固定的概念——用火球术来举例：

这样一来，我在做技能时，就不是每次都从零开始写一套完整逻辑，而是可以思考：

• 这个技能的行为和流程，应该写进 Ability。
• 数值变化（伤害、回血、资源消耗），应该定义成 Effect。
• 角色的基础数值，应该放进 Attribute。
• 状态的判断和分类，应该用 Tag 来描述。
• 视觉和听觉反馈，应该交给 Cue 处理。

这也是我目前觉得 GAS 有价值的地方——它不只是帮我做一个技能，而是提供了一种整理技能系统的方式。

所以可以看得出来，这就是一个框架，只要跟着这个框架，我们就可以更清楚地知道我们要如何增加技能，当技能有问题的时候可以往什么方向去寻找。

我目前对GAS的理解

GAS对我而言就是一个比较长期的投资，由于我现在的这个RPG prototype项目，我是一边设计一边开发的，所以我会比较担心这个项目后期会让我很难维护，所以才会想着有没有一个框架就是让我有一个固定的pipeline来增加技能。

所以GAS对我而言就是有效控制以后的技能不容易失控。

当然我知道这个学习成本就是会比较高，但是我不觉得我做完这个项目之后就不碰RPG类型的游戏了，相反，未来的很多游戏都会依赖GAS来开发，谁知道呢，未来也许会有更强大的框架，或者现在的框架其实埋着我不知道的隐患。不过现在花时间搞懂 GAS，对我而言还是很值得的。

下一篇，我们就会开始设置环境（哎呀，还没开始呀XD）