Go游戏服务器开发的一些思考（十三）：behavior3go的一些坑（备忘）

内容提示

使用behavior3go已经一段时间，主要用它来实现AI、技能。
总体来说，非常好用，不管在设计上，还是编码上。

这里记录几个开发过程成中遇到的坑。

默认前提：某一时刻只能处于一种状态

根据有限状态机理论，某一时刻只能处于一种状态。behavior3go也是遵守这个前提的。

如有同事为了便利，写了个自定义composite，来处理同时可以让多个分支处于RUNNING状态。这显然破坏了默认前提。因此运行过程中，总有些分支被无故关闭。

Blackboard是唯一的数据来源

根据behavior3go的设计思路，树对象是可以复用的，行为树的数据则是放在Blackboard实例中。

如每个Player对象都有一个Blackboard实例。这样它们可以复用一棵行为树，在行为树的每个Tick时，传入自己的Blackboard实例，来得到自己的行为。

然而在开发过程中，有不小心的、或是状态不佳下，有可能会把某个字段定义在Action中了，会埋下比较深的坑。一般开发过程中不易发现BUG。只有该Action大量被执行中时，才会暴露出问题来。

切换树前时，切记关闭上个树

通常情况下，一棵树会正常执行，知道关闭。但是实际应用会更复杂。

比如在做技能时，通常会把受击行为也做成技能行为树。这时候，技能释放过程中，就会有几率被打断，更换为受击行为树来执行。所以这种情况，切记先把旧树关闭，再执行新树。

树的横向扩展

behavior3go是每次Tick都是从根节点开始执行的。如果树的层次越深，如N层。则每次执行需要遍历的N个节点。

同时为了更好的维护一棵树，也不会建议把行为树设计的很复杂。

比如技能的行为树，显然会把一个技能对应1棵行为树。服务器根据客户端指令，来选择对应的某棵技能行为树来执行。

同理，其他系统也是这个道理。可以有很多简单、内敛的行为树，根据精心设计好的决策算法，选取一棵来执行。这样就可以达成横向扩展。