当我们开始构建《Breach》时，我们都知道成功的关键在于需要有一个深度系统工具箱，让我们的团队能够表现出集思广益所得出的广泛技能。即使在早期的讨论和原型构建阶段，我们所设想的不同技能和角色职业组合也要求我们构建灵活的数据驱动方法来创建技能。
（本视频转载自YouTube：视频原址）
燃烧吧！地狱之火终极技能。
我们将一套连锁系统合并起来，让QC Games的设计师和美术的都能创作技能，从简单的混战到职业特有的最终技能等等。地狱之火是即将推出的一种职业的终极技能，拥有这项技能的玩家会喷射一团火，将火团另一端不幸的敌人点着。这是令人惊叹的终极技能，尽管它看起来非常霸气，但地狱之火和《Breach》中的所有技能都一样，使用相同的基础构建块，首先是技能数据资源。
全面适用的Gameline
技能数据不仅定义《Breach》中技能的“具体含义”，还指出技能的“用法”。回到我们对地狱之火的描述，我们看到“喷射”一词，它暗示着《Breach》中编写技能的一个核心系统：Gameline。Gameline表示游戏事件的时间线，包括播放动画、更改角色身上的材质效果、造成伤害或产生效果等。
除了编辑器，Gameline还有一些重要的数字技巧，让《Breach》能够实现快节奏的多玩家战斗模式。如果在多人模式中使用了一个技能，会在游戏服务器和客户端之间同步关联的Gameline。这包括允许游戏客户端预测技能是否能有效执行以及开始播放对应的Gameline，然后服务器才有机会验证技能是否应该播放。在极少数遭到服务器拒绝的情况下，客户端会更正其状态以与服务器的权威场景视图相匹配。但是，大多数时候，玩家获得的都是即时响应体验，而设计师在编写技能时，也不必担心网络问题。使用Gameline让《Breach》的多玩家模式能够让大多数玩家获得令人称赞的无缝和显著无延迟。
提出正确的问题
地狱之火是《Breach》中能够在空中使用、也能站在地上使用的众多技能之一。虽然这两种情况下地狱之火基本相同，但表现方式（需要考虑玩家开始站在地面上和降落的动画效果）和功能有所不同（角色在发射时应该悬挂于空中）。我们可以为空中和站立技能构建一些细节，但我们知道，其他技能可能需要了解角色的生命值，或者“增益”（我们在内部叫做修饰符）有没有激活。
感受烈焰
有了Gameline工具，我们就能安排部分技能执行的顺序，有了条件系统，我们就能播放正确的动画和效果。那么地狱之火技能的火焰部分该怎么办呢？为此，我们在《Breach》战斗系统中开发了另一个工具：AOE（效果范围的简称）Actor。效果范围技能在动作RPG中十分常见，《Breach》也不例外。我们的AOE Actor（在虚幻用法里，任何可以放在关卡中的东西都是某种类型的Actor）支持多种用于实现以下技能的有用功能：用于定义AOE区域的一系列形状（箱体之类的Primitive类型以及导入网格体之类的自定义类型）；设计师在确定哪些角色会受到AOE影响时可以选择的条件；用于定义AOE可以“触发”以应用效果的方式、条件和速度的选项；随着时间的推移变换AOE形状的方式。
虽然《Breach》系统设计师操纵的大多数对象是Gameplay系统的数据，我们仍怀疑某些区域需要的控制和灵活性要超过我们实际能用数据建模的程度。
对于伤害计算，我们的设计师接受了用原生代码工作的挑战，久而久之，他们使用了一个系统向简单值添加功能，我们将这个系统称作“委托”。委托是对我们设计师编写的原生代码的标注，让设计师能够将整个Gameplay系统中的简单整数或浮点值替换为小函数。委托之所以十分关键，是因为能让我们在框架结构内保持灵活性，而又不必在核心系统代码中存储不断增长的特例。它们会考虑方方面面的事情，例如类似地狱之火等技能的持续时间、发射物移动的速度、燃烧减益最终造成的伤害程度。
