Behavior系统的思考和实现(2)

上次说了AI行为的一些想法，在很多的游戏AI引擎中，都或多或少存在这样的概念，这篇文章想继续上面的话题，说说实现。在现在的项目里，我做过一些探索，并且用两种方式实现过AI行为系统，效果都还可以。

在实现前，一般有几个必须要考虑的问题，当然，这些不仅适用于游戏AI开发，也适用于其他类型的软件开发。

下面来介绍一下我尝试过的两种实现方法，当然，这里给出的是一些思路，一些很细节的东西，我不会很深入，要不就成代码解释了，顺便说一句，这两个名字是我自己取得，只是为了便于说明和理解。先介绍第一个。

基于动态命令队列的行为系统（Based on Dynamic Command Queue’s Behavior System）

这种系统自顶向下分为三个部分， 行为命令（Behavior Command），行为机（Behavior Machine），行为结点（Behavior Node）。

行为命令（Behaviour Command）：是面向AI决策层的接口，AI把行为命令压入行为队列，等待行为机的处理。这里的命令都是预先定义好的，再用上次举过的小狗的例子，决策层发现小狗的疲劳度很高了，需要“睡觉”，就可以发一个定义好的睡觉的命令，然后再由下层行为机负责处理。
行为机（Behaviour Machine）：行为机的主要任务是维护一个行为队列，并执行队列中的行为命令，每一个行为命令都对应一个定义好的执行单元，即行为结点
行为结点（Behaviour Node）：真正的行为执行单元，是一组简单行为的集合。结点内部，根据行为命令中的相关信息，进行处理，如选择动画，播放动画等等

在这种结构中，复合行为是由预定义的行为命令来实现的，比如定义一个 “边吃饭边喝水”的命令，这样的话，如果我们要扩展，只需要扩展行为命令，然后再添加相应的行为结点作为执行单元即可。

行为机是整个系统的核心部分，我做的时候，接受命令请求的队列容量是2，即当前执行的和下一个要执行的，这可以根据实际需求来调整。另外实现过程中，发现有可能有用的Tips，给大家参考：

检测行为命令是否相同：AI可能重复发一个行为命令（很多情况下无法避免），所以在命令进入队列的时候，需要检测这个命令是否与队列中相同
检测行为命令的优先级：因为命令是被压入的，而不是立即执行的，所以可能有时希望命令间有优先级，比如，小狗 ”睡觉“比”移动“的优先级高，这样当”睡觉“指令入队列的时候，”移动“命令就不会覆盖掉”睡觉“ 的指令。
提供特殊命令：行为机可能需要提供一些控制命令，如重置，剔除，暂停，查询等给AI接口，当然，过多的控制命令会破坏行为机的封装性，只能平衡一下了。
用FSM（有限状态机）来实现行为结点：一个行为执行可能是一个需要不断重入的过程，也就需要几帧或者几十帧来完成，这样可以考虑用FSM把行为结点分为Enter，Execute，Exit三段（我叫这种为3E结构）来处理，会十分的方便。

调试这种结构也很便捷，可以做一个工具来监控整个行为命令队列的运行情况，比如，当前是哪个，下一个是哪个，集成在AI的调试工具里即可。

AI分享站