行为树（Behavior-Tree）知识点

行为树（Behavior-Tree）

一、基本概念

这是我们为一个士兵定义的一颗行为树（可以先不管这些绿圈和红圈是做什么的），首先，可以看到这是一个树形结构的图，有根节点，有分支，而且子节点个数可以任意，然后有三个分支，分别是巡逻（Patrol），攻击（Attack），逃跑（Retreat），这个三个分支可以看成是我们为这个士兵定义的三个大的行为（Behavior），当然，如果有更多的行为，我们可以继续在根节点中添加新的分支。当我们要决策当前这个士兵要做什么样的行为的时候，我们就会自顶向下的，通过一些条件来搜索这颗树，最终确定需要做的行为（叶节点），并且执行它，这就是行为树的基本原理。

值得注意的是，我们标识的三大行为其实并不是真正的决策的结果，它只是一个类型，来帮助我们了解这个分支的一些行为是属于这类的，真正的行为树的行为都是在叶节点上，一般称之为行为节点（Action Node），如下图红圈表示的

这些叶节点才是我们真正通过行为树决策出来的结果，如果用我以前提到的那个层次化的AI结构来描述的话，这些行为结果，相当于就是一个个定义好的“请求”（Request），比如移动（Move），无所事事（Idle），射击（Shoot）等等。所以行为树是一种决策树，来帮助我们搜寻到我们想要的某个行为。

行为节点是游戏相关的，因不同的游戏，我们需要定义不同的行为节点，但对于某个游戏来说，在行为树上行为节点是可以复用的，比如移动，在巡逻的分支上，需要用到，在逃跑分支上，也会用到，这种情况下，我们就可以复用这个节点。行为节点一般分为两种运行状态：

1. 运行中（Executing）：该行为还在处理中
2. 完成（Completed）：该行为处理完成，成功或者失败

除了行为节点，其余一般称之为控制节点（Control Node），用树的“学名”的话，就是那些父节点，如下图绿圈表示

控制节点其实是行为树的精髓所在，我们要搜索一个行为，如何搜索？其实就是通过这些控制节点来定义的，从控制节点上，我们就可以看出整个行为树的逻辑走向，所以，行为树的特点之一就是其逻辑的可见性。

我们可以为行为树定义各种各样的控制节点（这也是行为树有意思的地方之一），一般来说，常用的控制节点有以下三种

1. 选择（Selector）：选择其子节点的某一个执行
2. 序列（Sequence）：将其所有子节点依次执行，也就是说当前一个返回“完成”状态后，再运行先一个子节点
3. 并行（Parallel）：将其所有子节点都运行一遍

用图来表示的话，就是这样，依次为选择，序列和并行

可以看到，控制节点其实就是“控制”其子节点（子节点可以是叶节点，也可以是控制节点，所谓“执行控制节点”，就是执行其定义的控制逻辑）如何被执行，所以，我们可以扩展出很多其他的控制节点，比如循环（Loop）等，与行为节点不同的是，控制节点是与游戏无关的，因为他只负责行为树逻辑的控制，而不牵涉到任何的游戏代码。如果是作为一个行为树的库的话，其中就一定会包含定义好的控制节点库。

如果我们继续考察选择节点，会产生一个问题，如何从子节点中选择呢？选择的依据是什么呢？这里就要引入另一个概念，一般称之为前提（Precondition），每一个节点，不管是行为节点还是控制节点，都会包含一个前提的部分，如下图

前提就提供了“选择”的依据，它包含了进入，或者说选择这个节点的条件，当我们用到选择节点的时候，它就是去依次测试每一个子节点的前提，如果满足，则选择此节点。由于我们最终返回的是某个行为节点（叶节点），所以，当前行为的“总”前提就可以看成是：

当前行为节点的前提 And 父节点的前提 And 父节点的父节点的前提 And….And 根节点的前提（一般是不设，直接返回 True）

行为树就是通过行为节点，控制节点，以及每个节点上的前提，把整个 AI 的决策逻辑描述了出来，对于每次的 Tick，可以用如下的流程来描述：

action = root.FindNextAction(input);
if action is not empty then
action.Execute(request, input) // request是输出的请求
else
print “no action is available”

从概念上来说，行为树还是比较简单的，但对 AI 程序员来说，却是充满了吸引力，它的一些特性，比如可视化的决策逻辑，可复用的控制节点，逻辑和实现的低耦合等，较之传统的状态机，都是可以大大帮助我们迅速而便捷的组织我们的行为决策。最后，对这个士兵的巡逻分支画了一个示意图，供大家参考：

二、节点

2.1、关于选择节点的讨论

我们说过选择节点的定义是通过判断子节点的前提条件来选择一个节点执行，这就牵涉到判断顺序的问题，是自左向右，还是随机选择，或者其他的一些规则等等，这样就延伸出各种各样的选择节点。

1、带优先级的选择节点（Priority Selector）

这种选择节点每次都是自左向右依次选择，当发现找到一个可执行的子节点后就停止搜索后续子节点。这样的选择方式，就存在一个优先级的问题，也就是说最左边的节点优先级最高，因为它是被最先判断的。对于这种选择节点来说，它的子节点的前提设定，必须是“从窄到宽”的方式，否则后续节点都会发生“饿死”的情况，也就是说永远不会被执行到，为了更清楚的说明，看下面第一张图，这三个子节点在一个带优先级的选择节点下，它们的前提会被依次判断，可以看到这个三个子节点的前提从左向右，一个比一个更严格，如果我们现在 a 为 9，按照下图的定义会执行第一个子节点，如果 a 为 7，则会执行第二个子节点，如果 a=11，则会执行第三个子节点。下面的第二张图演示了一种节点“饿死”（Starvation）的情况，我们看到第一个子节点的前提，比第二个子节点更宽泛，只要 a<10，那自左向右判断的话，永远会进第一个节点，所以，如果要用到带优先级的选择节点，则必须检查每一个子节点的前提，以防止节点饿死的情况。

2、不带优先级的选择节点（Non-priority Selector）

这种选择节点的选择顺序是从上一个执行过的子节点开始选择，如果前提满足，则继续执行此节点，如果条件不满足，则从此节点开始，依次判断每一个子节点的前提，当找到一个满足条件的子节点后，则执行该节点。这种方式，是基于一种称之为“持续性”的假设，因为在游戏中，一个行为一般不会在一帧里结束，而是会持续一段时间，所以有时为了优化的目的，我们可以优先判断上一个执行的节点，当其条件不满足时，再寻找下一个可执行的节点。这种寻找方式不存在哪个节点优先判断的问题，所以对于前提的设置的要求，就是要保证“互斥”（Exclusion）。用上面第一张图来说明，如果我们把控制节点换成不带优先级的选择节点，可以看到，当 a=3 时，第二个子节点会被执行，下一次当 a 变成 9 时，由于不是从头依次判断前提的，所以，我们还是会选择第二个节点，而不是我们可能期望的第一个节点。正确的做法见下图，注意每一个子节点的前提是“互斥的”。所以对于不带优先级的选择节点，它子节点的排列顺序就不是那么重要了，可以任意排列。

3、带权值的选择节点（Weighted Selector）

对于这种选择节点，我们会预先为每一个分支标注一个“权值”（Weight Value），然后当我们选择的时候，采用随机选择的方式来选，随机时会参考权值，并且保证已经被测试过的节点不会再被测试，直到有一个节点的前提被满足，或者测试完所有的节点。带权值的选择节点对于子节点前提由于随机的存在，所以子节点的前提可以任意，而不会发生“饿死”的情况，一般来说，我们通常会把所有子节点的前提设为相同，以更好的表现出权值带来的概率上的效果。当所有子节点的权值一样时，这种选择节点就成为了随机选择节点（Random Selector），带权值的选择节点对于需要丰富 AI 行为的地方，非常适用，比如养成类游戏中，小狗表示开心的时候，可能会有各种各样的表现，我们就可以用这种选择节点，添加各种子节点行为来实现。

这些就是常用的选择节点类型，我们可以根据需要，定义更多的选择节点的选择行为，其实我们可以看到，不同的选择行为对于子节点前提的要求会有略微的不同，这是在搭建行为树的时候需要注意的地方。

2.2、关于并行节点结束条件的讨论

我们每个节点都会有一个运行状态，来表示当前行为是否结束。对于控制节点来说，它的运行状态就是其子节点的运行状态，选择节点和序列节点比较好处理，因为对于这两种控制节点来说，每时刻，只会有一个子节点在运行，只要返回在运行的这个子节点的状态即可。但对于并行节点来说，它同时刻会有多个子节点运行，那我们如何来处理并行节点的运行状态问题呢？一般有两种：

• 与：只有所有的子节点都运行结束，才返回结束。
• 或：只要有一个子节点运行结束，就返回结束。

为什么要需要有节点的运行状态呢？

• 序列控制节点中，需要用运行状态来控制序列的执行
• 外部世界需要了解行为的运行状态，来决定是否要更新决策（如果行为树在决策层）/ 请求（如果行为树在行为层）

对于第二点，可以举个例子，比如我们有一个行为是“走到 A 点”，假设这个行为是不可被打断的，那当我们在走向 A 点的过程中，行为树的运行状态就是“正在执行”，当到达 A 点时，行为树就返回“已完成”，这样，对外部来说，当我们看到行为树是“正在执行”的时候，我们就不需要做任何新的行为（为了优化，或者为了行为抖动等等），当看到“已完成”的时候，我们就可以做新的决策或者行为了。这样一个运行状态还有助于我们检测行为树的状态，帮助调试。

2.3、关于具体实现的讨论

行为树的实现可以有多种多样，一般来说，行为树每个节点需要有进入（Enter），离开（Exit），运行（Execute）等部分，需要有行为节点（ActionNode），控制节点（ControlNode），前提（Precondition）等基类，然后，还需要定义行为树的输入（InputParam）和输出（OutputParam），一般来说，我们希望行为树是一个黑盒，也就是说，它仅依赖于预定义的输入。输入可以是黑板（Blackboard），工作池（Working Memory）等等数据结构，输出可以是请求（Request），或者其他自定义的数据结构，如下图:

2.4、关于绘制和调试的讨论

看到行为树的定义后，作为程序员的直觉，我们很自然的就会想到，这好像应该能做一个工具来辅助行为树的创建和调试，我们可以把预定义好的前提和节点，在一个可视化的编辑器里搭建成行为树，然后再导出成数据给游戏用。对于调试来说，我们可以让工具和游戏通信，然后实时的检测行为树的运行状况，比如当前在哪个分支中等等。由于行为树的逻辑是可见的，并且是静态的，所以我们看其选择的路径，我们就可以知道 AI 为什么会作出这样的决策了。

参考原文:
行为树（Behavior Tree）实践（1）– 基本概念