角色的能力系统可能是游戏中最苛刻的灵活性要求。 在设计阶段无法预测哪些咒语会出现在最终版本或后续更新中。 这篇文章将讲述我如何抽象能力的过程。
能力本身无非是一系列行动。 该功能的最小接口包括一种方法：“应用”，但对于割下的困难并不那么简单。
每项能力都始于一系列检查，以查看是否可以应用。 其中包括普通物品，例如检查补给，法力可用性，检查距离等。 在这里已经很明显，并非所有能力都需要所有检查。 例如，可以在任意距离应用能力。 也就是说，不同的能力在执行之前需要不同的检查集。 但是，很明显，许多检查将被重复，并且许多能力通常需要同一组检查。
总而言之，部分检查将在逻辑上重复进行，这意味着必须按照协议进行更改，即立即在所有地方进行更改。 此外，一般情况下支票的组成部分将有所不同。
如果将支票的一部分选择到实现一个接口的单独对象中，并构建到单个链接列表中，则我们将获得一个责任模板链。
如果该链接检查成功，则将开始下一个链接的检查，如果没有下一个链接，则整个检查都可以视为成功。 除了检查本身之外，链接还可以包含错误处理程序。 例如，如果在检查法力值时发现这还不够，那么该链接可以将这件事通知玩家。
使用职责链，对于[强力射击]能力，我们可以轻松地插入一个附加链接来检查角色是否戴着弓箭，或者插入一个链接来检查角色的健康度是否低于[第二风]的30％。
让我们回滚并记住，对于许多能力而言，检查链都是相同的。 让我们强调能力实现请求的本质，并用其类描述每种测试链的类型。
仅当玩家发出适当的命令时，才需要草拟职责链，启动任务并取消请求。
我们已经在查询实现中建立了链。
目前，我们已经学习了如何对执行能力进行灵活的测试。 现在，如果测试成功，您仍然需要满足该能力。
我更愿意在不更改界面的情况下执行此操作，而是添加该功能作为副作用执行的最后一个始终成功的链接。 这是它的示例实现：
public class TerminalChecker: ICastChecker { CastChecker next { get; set; } ISkill skill; public TerminalChecker(ISkill skill) { this.skill = skill; } public bool check() { skill.cast(); return true; } }
此实现使我们可以使请求异步。 当我们需要用户提供其他信息时，这很有用。 例如，必须将一种能力应用于玩家用鼠标选择的某个区域。 当然，您目前无法停止游戏。
现在，我们需要将请求与能力进行匹配。 当然，我们将通过向功能接口添加属性来使用多态来做到这一点。 在这个阶段，我们扩展了此接口的功能：
完成所有工作后，让我们考虑一下什么是能力。 在当前的实现中，这是一系列操作，然后进行一系列检查。 请注意，从总体上讲，我们绝不依赖于特定的游戏逻辑。 有了描述用于咒语的能力系统的最初思想，我们得到了一个根据某些规则提供或不允许我们执行任意动作的系统。
由于此属性，该系统可以描述游戏世界的任何修改。 例如，销售交易或建筑施工团队。
让我们再来看一遍一般情况
在此示例中，Sprint功能是没有目标的普通功能；实现此类功能请求的类是NontargetCastRequest，该类又形成了来自ManaChecker，CooldownChecker和TerminalChecker的检查链。
调用代码不依赖于此系统的实现细节，也就是说，我们不会通过添加或更改功能来破坏游戏逻辑。
这是最小形式的角色能力系统。 该模型缺乏警告调用代码，将功能转移到用户界面以及其他生活细节的方法。 您可以自己想到它们。