写一个ECS框架＋行为树，实现格斗游戏 AI

引言：实现游戏 AI 的方式有很多，目前最为常用的主要有有限状态机和行为树。和有限状态机相比，行为树有更好的可扩展性和灵活性，能实现更复杂的 AI 需求。开发者honmono在 Cocos Creator 中用一个ECS + BehaviorTree 框架实现了一个格斗 AI Demo，一起来看看他的方案。

写一个 ECS 框架

ECS 全称 Entity - Component - System（实体-组件-系统）。组件只有属性没有行为，系统只有行为没有属性。

什么是 ECS 呢？网上已经有很多介绍 ECS 的文章了，这里不再赘述，直接贴几篇我个人觉得写的好的，谈一谈我的理解：

《浅谈中的 ECS 架构》

https://blog.codingnow.com/2017/06/overwatch_ecs.html

这篇文章应该是最早一批介绍 ECS 架构的文章了，不仅全面地介绍了 ECS 架构，还对比了 ECS 和传统游戏开发架构的区别，以及在网络同步时的处理。

《游戏开发中的 ECS 架构概述》

https://zhuanlan.zhihu.com/p/30538626

这篇文章比较接地气，文中提到：

ECS 的模式遵循组合优于继承原则，游戏内的每一个基本单元都是一个实体，每个实体又由一个或多个组件构成，每个组件仅仅包含代表其特性的数据（即在组件中没有任何方法），例如：移动相关的组件 MoveComponent 包含速度、位置、朝向等属性，一旦一个实体拥有了 MoveComponent 组件便可以认为它拥有了移动的能力，系统便是来处理拥有一个或多个相同组件的实体集合的工具，其只拥有行为（即在系统中没有任何数据），在这个例子中，处理移动的系统仅仅关心拥有移动能力的实体，它会遍历所有拥有 MoveComponent 组件的实体，并根据相关的数据（速度、位置、朝向等），更新实体的位置。

实体与组件是一个一对多的关系，实体拥有怎样的能力，完全是取决于其拥有哪些组件，通过动态添加或删除组件，可以在（游戏）运行时改变实体的行为。

这段话对于 ECS 的关系也是我设计的框架遵守的规则，即 Component 只包含属性，System 只包含行为。

这个 ECS 框架做了什么

World-Entity-Component-System 的关系图

World 每帧根据顺序调用所有的 System，System 中会处理对应的 Component。在这个过程中，使用者可以动态创建或销毁 Entity，给 Entity 添加或移除 Component。

为了更高效地维护 Entity-Component-System 的关系，我采取了一些办法。

1、所有的 Component 都通过其对应的 ComponentPool 维护。

例如 MoveComponent 会生成一个 MoveComponentPool 进行维护，方便实现复用。 外面不直接持有 Component，而是通过 component 在 pool 中的 index 索引便可以在对应的 pool 中获取到对应的 Component。

2、Entity 使用自增 Idx 标识。当有 entity 被销毁时，会回收 idx。

外部不需要持有 Entity 对象，或者说没有 Entity 对象，所有的 Entity 都是一个 Idx， 通过这个 Idx 在 world 内进行操作。

3、System 通过 Filter 类管理关注的 Entity。

上文中提到 System 为了处理其关心的 ComponentA，会遍历所有拥有该 ComponentA 的 Entity。但是怎么判断哪下 Entity 有这个 ComponentA 呢? 传统的方法会遍历所有的 Entity，判断其是否有 ComponentA，这种方案明显是不够高效的。 所以这里引入了 Filter 类， 其方法的核心是空间换时间并有一套判断规则（接收某些类型的组件， 拒接某些类型的组件）， 当每次进行 AddComponent 和 RemoveComponent 或者 RemoveEntity 等会影响实体的操作时，会通知所有的 Filter 有实体进行了修改，Filter 会判断该实体是否还符合条件（也就是判断是否有 ComponentA），选择是否在 Filter 中保留该实体。那么当 System 需要遍历某些特定的 Entity 时，就可以直接通过对应的 Filter 就可以获得了。

4、Entity 和 Component 的关系可以用一张二维表维护。

如上述表格中 Component 数字的意思是其在 Pool 中的 index 索引，-1表示没有。所以 Entity1 有组件 ComponentB，ComponentD。Entity1 有组件 ComponentB， ComponentC。

还有最后一个问题就是 如何将 Entity 和 Component 转换成 0~N 的整数以方便构建二维数组呢？

对于 Entity 可以通过 id 的自增实现，每创建一个 Entity，id++。而 Component 可以根据类型的枚举值得到唯一标识。如下面的枚举值。

这样就可以构建出上面的二维表了。

最后还可以通过 ts 的注解，将 ComType 注入到对应的 Component 类中。将 type 和 component 一一对应起来。

到这一步就已经完成框架部分了。再展示一下 ComMovable 对应的 SysMovable。这个 System 会每帧根据 ComMovable 的当前状态，计算出下一帧的 ComMovable 状态。

这里插入一下对于 Filter 的更详细的介绍。Filter 的判断规则是通过参数判断接收某些类型的组件，拒接某些类型的组件。比如这个参数 [ComMovable， ComTransform， ComCocosNode] 表示这个 Filter 保存的是同时含有 ComMovable，ComTransform，ComCocosNode 组件的实体。

ECS 框架和 Cocos Creator 结合

ECS 框架本身的实现不难，核心代码只有几百行的样子，但是如何将这个框架和 Cocos Creator 结合起来，或者说怎么展示一个 Node，并可以通过 ECS 的方式操控 Node 呢？

以上面的 ComMovable 和 SysMovable 为例，ECS 本身更多的是数据上的逻辑处理，Entity 添加了 ComMovable 组件就获得了 SysMovable 的能力，那么给 Entity 添加一个显示 Node 的组件(ComCocosNode)，再通过一个处理 ComCocosNode 的 System(SysCocosView) 是不是就实现了展示 node 的能力呢。

1、设计结合 Cocos 中 Node 的组件

基于这个想法我设计了 ComCocosNode。

ComCocosNode 中有 node 属性。通过 Entity 获取到 ComCocosNode 组件就可以修改 node 的属性了，而 events 是因为对于 node 我们不仅有同步的处理，也有一些异步的处理，比如播放一系列动画，这种可以通过添加事件的方式，即在 system 不直接调用 node 的组件方法，而是让组件自己读取 event，自己去处理。

这个时候 node 还没有赋值，所以我又设计了一个组件 ComNodeConfig。

这里可能会有人有疑问，为什么不把这两个组件的属性合并到一起，这个其实是为了方便配置，ComNodeConfig 的属性都是可以直接配置在表上的，这样的话就方便配置同学了。

2、设计处理 ComNodeConfig 的 System

最后通过一个 SysCocosView 系统，这个系统处理的实体是有 ComNodeConfig 组件， 但是没有 ComCocosNode 组件的实体。每次遍历时根据 ComNodeConfig 组件的 prefabUrl 加载 prefab 生成 node，根据 layer 层级将 node 添加到指定位置，然后给这个实体添加 ComCocosNode 组件，将 node 值赋上。这样下一次就不会处理这个实体了。下面的代码是 Demo 已经完成后的代码了，我就不还原到刚开始时候的样子了。

写一个 BehaviorTree

对 BehaviroTree（行为树）的介绍网上也有很多文章可以参考，感兴趣的可以深入了解一下：

《游戏 AI 之决策结构——行为树》

https://www.cnblogs.com/KillerAery/p/10007887.html

《AI 行为树的工作原理》

https://indienova.com/indie-game-development/ai-behavior-trees-how-they-work/

行为树的名字很好地解释了它是什么。不像有限状态机（Finite State Machine）或其他用于 AI 编程的系统，行为树是一棵用于控制 AI 决策行为的、包含了层级节点的树结构。树的最末端——叶子，就是这些 AI 实际上去做事情的命令；连接树叶的树枝，就是各种类型的节点，这些节点决定了 AI 如何从树的顶端根据不同的情况，来沿着不同的路径来到最终的叶子这一过程。

行为树可以非常地“深”，层层节点向下延伸。凭借调用实现具体功能的子行为树，开发者可以建立相互连接的行为树库来做出非常让人信服的 AI 行为。并且，行为树的开发是高度迭代的，你可以从一个很简单的行为开始，然后做一些分支来应对不同的情境或是实现不同的目标，让 AI 的诉求来驱动行为，或是允许 AI 在行为树没有覆盖到的情境下使用备用方案等等。

树的最末端叶子是 AI 实际上做的事的命令，可以称为行为，行为是需要用户编写的具体的动作，比如移动到某位置、攻击、闪避等。联系根到叶子的节点的中间节点可以称为决策节点，决策节点并没有实际的行为，而是决定是否可以向下执行到叶子节点。

那么它是如何决定的呢?

工作原理

每一个节点执行后都会返回一个状态，状态有三种：Success、Fail 和 Running。

Success 和 Fail 很好理解，比如一个监视节点，看到了敌人返回 Success，没看到返回 Fail。

但是对于一个需要执行一段时间的节点，比如 1s 内移动五步，在不到 1s 时去看节点的状态，这个时候返回成功或者失败都是不合理的，所以这种情况应该返回 Running 表示这个节点还在执行中，等下一帧在继续判断。

这个时候我们可以设计这样一个节点，它的状态是和子节点状态挂钩的，按顺序执行子节点，如果遇到了执行失败的节点则返回失败，如果全部执行成功则返回成功。这种节点可以称为Sequence。

类似的节点还有Selector，这个节点的状态是按顺序执行子节点，如果全部执行失败则返回失败，如果遇到执行成功则返回成功。

下面举一个实际项目 Sequence 的实现例子。

这两个节点的组合就可以实现 if else 的效果，假设当角色在门前，如果有钥匙就开门，如果没有就砸门：

如果有钥匙，Sequence 的第一个子节点（检查是否有钥匙）执行成功，那么就会去执行第二个子节点（钥匙开门）。Sequence 执行成功即不会执行后面的斧头砸门节点。

如果没有钥匙，Sequence 执行失败，那么就执行后面的斧头砸门节点。

决策的时效性

根据我看的一些文档，对于行为树的决策是每一帧都要更新的，比如现在有一个场景，用户可以输入文本，输入 move 让方块 A 向前移动10格子，输入 stop 方块 A 停止移动。那么对于行为树来说，每一帧都要判断当前用户输入的是 move，还是 stop，从而下达是移动还是停止的行为。

对于移动，行为是 sequence([用户输入move， 移动])，用 ActionA 代替；

对于停止，行为是 sequence([用户输入stop， 停止])，用 ActionB 代替；

最终行为是 select([ActionA， ActionB])。

sequence 表示按顺序执行子行为，如果遇到子行为执行失败，那么立刻停止，并返回失败，如果全部执行成功，那么返回成功。

select 表示按顺序执行子行为，如果遇到子行为执行成功，那么立即停止，并返回成功。如果全部执行失败，那么返回失败。

假设现在用户点击一下，那么每帧都需要从头一层层向下判断执行，直到判断到移动再执行——当然这是有必要的，对于行为来说确定自己能否应该执行是十分重要的。

但是这对执行一个持续性的行为很不友好。假设还是上面的场景，用户输入 sleep，方块停止移动 2s。就是 sequence([用户输入sleep，停止移动2s])，这个时候行为树是 select([ActionA，ActionB，ActionC])；

那么当我输入 sleep，方块停止移动的时间内，输入 move，那么下一帧的决策就进入了 ActionA，导致方块移动。停止移动 2s 的行为被打断了。

这个问题我称为行为树决策的时效性，也就是行为得到的决策并不能维持一定时间。这个决策其实目前只是 Sequence 和 Select 才拥有的。

如何解决？

因为我是自己想的， 所以解决方案可能不是最优的。

首先我加入了具有时效性的 LockedSequence，LockedSelect，也就是当前行为的决策一旦做出，就必须在当前行为完全结束后才能被修改。

引入一丢丢代码，在 onEnter 时，将当前行为的状态置为 running，在 onUpdate 时判断，如果当前状态不是 running 就 return。所以一旦状态确定，就不会onUpdate 中被修改，直到下一次进入 onEnter。

这个时候在带入上述的场景就没问题了，当用户输入 sleep 时，方块停止移动 2s，在 2s 内输入 move，并不会导致 ActionC 的决策更改，直到停止移动 2s 的行为结束，进入下一个周期后才会进入 ActionA。

但是这个同样也导致了另一个问题，就是并行的行为。比如假设一个场景，士兵一边巡逻，一边观察是否有敌人，如果有敌人，那么停止巡逻，去追击敌人。

行为树如下：

ActionA = 巡逻

ActionB = sequence([观察是否有敌人, 追击敌人]);

repeat(sequence([ActionB, ActionA]))

因为上面的方法在行为结束前不会修改决策，那么就会出现士兵先观察是否有敌人，没有就去巡逻，巡逻完了，再去观察是否有敌人，这就太蠢了。

我的解决方案是添加一个新的决策 Node，这个 Node 就是处理并行行为的。

parallel 的能力是顺序处理子节点，但是并不需要等待前一个节点执行完毕后才能执行后一个。当有行为返回失败时，立即退出返回失败，当所有行为返回成功时，停止返回成功。

行为树如下：

repeat(selector([parallel([Inverter(观察是否有敌人)， 巡逻])， 追击敌人]))

注：Inverter 表示取反。

当前没有发现有敌人，那么行为在巡逻，parallel 还在 running 阶段，因为巡逻不会失败，所以最后一种情况是如果发现敌人，那么 parallel 立即返回失败，那么行为就到了追击敌人了。

最后展示一下 Demo 中的完整行为树：

Demo 下载

https://github.com/kirikayakazuto/CocosCreator_ECS