上一篇文章里说的一种基于命令的结构，这种结构的缺点主要是，没法设计行为结构，GD也没法参与其中，而且不是一种层次逻辑结构，下面这种结构在游戏界也是一种主流。
基于静态树结构的行为系统（Based on Static Tree’s Behavior System）
这种结构就是传说中的Behavior Tree（下简称BT，不要想成另一个BT），BT的实现方法可以有很多种，这里说的是我的实现方法。
BT的基本结构是节点（Node），节点分为两种：
- 行为节点（Ternimal Node）
- 控制节点（Control Node）
在BT的叶节点上全部是是行为节点，中间的全部是控制节点，控制节点就包括了我前面说过的三种基本结构，选择，并行，序列（可以翻一下前面的文章）。
代码实现上来说，BT的结构是一个通用的框架，所以应该尽量使得通用和特定的部分分开，比如，控制节点的逻辑是通用的，但逻辑的实现是游戏特定的，如果这样说还是不好理解的话，我来举个例子，比如一个控制节点是一个选择结构的节点，选择节点的逻辑是选择一个子节点来运行，这就是通用的部分，但如何选择是要根据不同情况定制的，这就是特定的部分。正是有了这样的要求，所以，我就引入了一个节点脚本（Node Script）的概念
每一个控制节点都会绑定一个节点脚本负责实现控制节点的逻辑定制，这样在构建整个BT的过程中，就分为以下几个步骤
- 搭建整个BT的结构，可以由GD一起参与
- 对每一个控制节点编写控制逻辑
- 编写每一个叶节点，即行为节点的代码
可以看到，这样的一个过程很容易用一个可视化的Tool来实现，画画，拖拖，写写，越想越赞，随便说一句，我对做可视化的AI结构一直相当的有兴趣！
这里，对于代码的结构就不多说了，对OO熟悉的话应该很容易搭建这样一个系统，写一些Tips，大家可以参考：
- 行为节点可以使用 1P+3E的简单FSM结构，即，Precondition，Enter，Execute，Exit，这样可以有很大的灵活度（原因可以参看上一篇文章）
- 对于控制节点必须提供一个Transition接口的调用来完成相关的清理工作，比如从这个节点转到另一个节点，必须调用上一个节点Transition来完成转换
- BT的每个节点可以允许挂的子节点数可以自定义，如果允许两个的话，就是2叉树，这样会使树的结构比较大（可以想象一下，如果我要做4个行为的序列，那树的层次就是3），但接口会相对简单
- 构建BT时，最好为每一个节点取一个名字，以方便从callstack观察运行路径
我现在想法中的Behavior系统基本就是这样，连载了3篇，算一个系列了，以后用这个可以做个demo看看，现在比较忙，一回家也懒得写代码。再说再说。
相关：
—>Behavior系统的思考和实现(1)
—>Behavior系统的思考和实现(2)
————————————————————————
作者：Finney
Blog：AI分享站(http://www.aisharing.com/)
Email：finneytang@gmail.com
本文欢迎转载和引用，请保留本说明并注明出处
————————————————————————