• 修复Task参数访问时有子树时的bug

有任何问题可以去问答社区寻求帮助，或者去QQ群（433547396）寻求技术支持！

behaviac是游戏AI的开发框架组件，也是游戏原型的快速设计工具。支持全平台，适用于客户端和服务器，助力游戏快速迭代开发 。

编辑器可以运行在PC上，操作方便直观可靠，支持实时和离线调试；编辑器可以导出xml，bson等多种格式，更可以导出C++、C#源码，提供最高效率。

运行时支持全平台，有C++和C#两个版本，原生支持Unity。

已被多款知名游戏及更多其他预研项目使用。

所有代码，包括编辑器和运行时全部开源https://github.com/Tencent/behaviac

编辑器和运行时

behaviac作为游戏AI的开发框架组件，有编辑器和运行时两个部分，这两个部分通过类型信息（描述AI实例属性和能力方法的信息）交换信息。

类型信息

类型信息用来描述类型的属性和方法。在3.5及之前的旧版本通过运行时端导出类型信息，3.6及之后的新版本通过编辑器创建类型信息，如下所示。编辑器中，该类型信息作为基本的语法单位用来创建行为树。

<agent classfullname="framework::GameObject" base="behaviac::Agent" inherited="true" DisplayName="" Desc="" IsRefType="true">
<Member Name="HP" DisplayName="" Desc="" Type="uint" Class="framework::GameObject" />
<Member Name="age" DisplayName="" Desc="" Type="long" Class="framework::GameObject" />
<Method Name="GoStraight" DisplayName="" Desc="" Class="framework::GameObject" ReturnType="void">
<Param DisplayName="speed" Desc="speed" Type="int" />
</Method>
<Method Name="TurnTowardsTarget" DisplayName="" Desc="" Class="framework::GameObject" ReturnType="int">
<Param DisplayName="turnSpeed" Desc="turnSpeed" Type="float" />
</Method>
<Method Name="alignedWithPlayer" DisplayName="" Desc="" Class="framework::GameObject" ReturnType="bool" />
<Method Name="playerIsAligned" DisplayName="" Desc="" Class="framework::GameObject" ReturnType="bool" />
<Method Name="projectileNearby" DisplayName="" Desc="" Class="framework::GameObject" ReturnType="bool">
<Param DisplayName="radius" Desc="radius" Type="float" />
</Method>
<Method Name="distanceToPlayer" DisplayName="" Desc="" Class="framework::GameObject" ReturnType="float" />
</agent>

在3.x版本之前的版本中，类型信息必须通过运行时来导出，策划需要新的属性或方法时，必须等待程序员更新代码重现导出类型信息后才能使用。而在3.x版本中，可以直接在编辑器中创建一个类型，并且创建它的属性和方法，而且可以导出类型的c++或c#源码，这极大的加速了迭代的过程，从而把编辑器作为一个原型设计工具。

编辑器

编辑器是一个可以运行在Windows平台上的编辑工具。

在编辑器内，使用鼠标或快捷键，可以添加、编辑、配置、修改行为树（包括FSM，或HTN），也可以实时或离线调试游戏的行为，既可以设断点，也可以查看或修改变量的值。

运行时

运行时有C++和C#两个版本，Unity使用C#的实现，像是cocos等使用C++的引擎或平台使用C++的实现。其具体逻辑是一致的，即加载编辑器中导出的行为树，解释运行之。

g_player = behaviac::Agent::Create<CBTPlayer>();

bool bRet = false;
bRet = g_player->btload(pszTreeName);
assert(bRet);

g_player->btsetcurrent(pszTreeName);

behaviac::EBTStatus status = behaviac::BT_RUNNING;

while (status == behaviac::BT_RUNNING)
{
status = g_player->btexec();
}

导出和调试

在编辑器内创建好行为后，需要导出，然后运行时才可以加载运行。编辑器支持导出多种格式：

1. xml
2. bson
3. cpp
4. c#

其中xml和bson作为数据，可以被加载，而cpp或c#作为源码直接编辑链接进程序，用户可以根据需要选择使用最合适的格式。

behaviac能解决什么问题

• behaviac作为游戏AI的开发框架组件，主要是用来开发游戏AI。
• behaviac的编辑器使用图形化的界面（Visual scripting）和操作，操作直观方便。
• 游戏中的NPC，小怪，老怪等等的游戏逻辑都可以通过behaviac来创建和开发。
• behaviac并不限于开发游戏AI的游戏逻辑，也可以用来开发组队逻辑（Squad Logic），策略AI（Strategy AI），玩家Avatar，甚至关卡设计等各种游戏场景。
• behaviac还可以用作原型设计工具，策划只是使用behaviac编辑器来设计类型安全的，表达严谨的游戏逻辑。
• C#版本的运行时原生支持unity，behaviac可以在unity内开发游戏AI
• 在iOS平台，作为热更新的一种手段
• C++版本支持全平台，不仅可以用在客户端，也可以用在服务器端。一套逻辑，可以根据情况分别在客户端，服务器运行，避免重复开发。

behaviac有哪些主要特性

• behaviac是游戏AI的开发框架组件，也是游戏原型的快速设计工具
• 支持持行为树（BT），状态机（FSM），层次任务网络（HTN）等多种范式
• 编辑器可以运行在PC上，操作方便直观可靠
• 编辑器可以导出xml，bson等多种格式，更可以导出C++，C#源码，提供最高效率
• 支持实时和离线调试，可以设断点，查看或修改变量
• 编辑器通过socket和游戏连接实现实时调试，支持远程实时调试
• 运行时支持全平台（Windows/Linux/iOS/Android等），有C++和C#两个版本，原生支持Unity。适用于客户端和服务器，助力游戏快速迭代开发
• 支持热加载，可以不用重启游戏就更新行为树
• 中英文界面可选，类型信息可以提供中英文显示信息
• 支持预制件（Prefab）、子树，方便重用共享
• 支持自定义数据类型，支持已有第3方库中的自定义类型
• 支持扩展节点类型

可以继续阅读behaviac概述 →

如果编辑器不能正常启动，需要下载安装Microsoft Visual C++ 运行库及.net框架。

可以从下载链接下载或从github克隆源码，这里介绍的是源码的目录结构。

目录结构图示

目录结构说明

• build：构建脚本，使用CMake构建。可以参考文档《如何编译构建》。
• docs：文档，目前只有behaviac.chm，以后访问文档需要访问API
• inc：运行时库的C++头文件
• integration：Unity平台的实现及示例
  • demo_running：一个简单demo
  • unity：unity的实现及unittest
• projects：C++项目文件，用于打开unit test和tutorials等项目。这里的项目文件是预提供的，仅支持vs及make。如果需要其他平台，可以参考build目录下的构建脚本。
• src：运行时库的C++源码
• test：测试，C++
  • btperformance：简单的性能测试
  • btremotetest,：简单的连调测试
  • btunittest：C++ unit test
  • demo_running：简单的测试，适合少量修改，体会行为树的概念
  • usertest：简单的测试，适合少量修改，做出自己的测试
• tools：编辑器的C#源码
  • designer
• tutorials：教程相关的源码，配合教程相关文档使用，方便上手

开发游戏AI的目标之一就是要找到一个简单，可扩展的编辑逻辑的方案，从而加速游戏开发的迭代速度。在“行为系统图”中，行为系统（Behavior System）响应游戏中的各种信息，进行决策以挑选接下来将要执行的行动并且监控该行动的执行。

知识模型（Knowledge Model）是对游戏世界中各种信息的抽象。

在行为系统中，有限状态机（FSM，Finite State Machine）最为经典，FSM模型的优势之一是简单。但是FSMs需要用转换（Transition）连接状态（State），因此，状态（State）失去了模块性（Modularity）。

什么是行为树

行为树，英文是Behavior Tree，简称BT，是由行为节点组成的树状结构：

对于FSM，每个节点表示一个状态，而对于BT，每个节点表示一个行为。同样是由节点连接而成，BT有什么优势呢？

在BT中，节点是有层次（Hierarchical）的，子节点由其父节点来控制。每个节点的执行都有一个结果（成功Success，失败Failure或运行Running），该节点的执行结果都由其父节点来管理，从而决定接下来做什么，父节点的类型决定了不同的控制类型。节点不需要维护向其他节点的转换，节点的模块性（Modularity）被大大增强了。实际上，在BT里，由于节点不再有转换，它们不再是状态（State），而是行为（Behavior）。

由此可见，BT的主要优势之一就是其更好的封装性和模块性，让游戏逻辑更直观，开发者不会被那些复杂的连线绕晕。

一个例子

上图中，3号Sequence节点有3个子节点，分别是：
– 4号Condition节点
– 5号Action节点
– 6号Wait节点

而3号节点的父节点是2号的Loop节点。

先补充下各节点类型的执行逻辑（详见节点说明）：

• 序列（Sequence）节点：顺序执行所有子节点返回成功，如果某个子节点失败返回失败。
• 循环（Loop）节点：循环执行子节点到指定次数后返回成功，如果循环次数为-1，则无限循环。
• 条件（Condition）节点：根据条件的比较结果，返回成功或失败。
• 动作（Action）节点：根据动作结果返回成功，失败，或运行。
• 等待（Wait）节点：当指定的时间过去后返回成功。

执行说明

• 如果4号条件节点的执行结果是成功，其父节点3号节点则继续执行5号节点，如果5号动作节点返回成功，则执行6号等待节点，如果6号节点返回成功，则3号节点全部执行完毕且会返回成功，那么2号节点继续下个迭代。
• 如果4号条件节点的执行结果是失败，其父节点3号节点则返回失败不再继续执行子节点，并且2号节点继续下个迭代。

进阶

聪明的读者可能会问，上面的例子中只讲了成功或失败的情况，但如果动作要持续一段时间呢？如果5号节点，Fire需要持续一段时间呢？

• 节点的执行结果可以是“成功”，“失败”，或“运行”。
• 对于持续运行一段时间的Fire动作，其执行结果持续返回“运行”，结束的时候返回“成功”。
• 对于持续运行一段时间的Wait动作，其执行结果持续返回“运行”，当等待时间到达的时候返回“成功”。

当节点持续返回“运行”的时候，BT树的内部“知道”该节点是在持续“运行”的，从而在后续的执行过程中“直接”继续执行该节点，而不需要从头开始执行，直到该运行状态的节点返回“成功”或“失败”，从而继续后续的节点。从外面看，就像“阻塞”在了那个“运行”的节点上，其父节点就像不再管理，要一直等运行的子节点结束的时候，其父节点才再次接管

（请注意，这一段说明只是从概念上这样讲，概念上可以这样理解，实际上即使运行状态的节点每次执行也是要返回的，只是其返回值是运行，其父节点对于返回值是运行状态的节点，将使其继续，所以看上去好像父节点不再管理。）。

另一个例子

如上图，为了清晰说明运行状态，来看另一个例子。在这个例子中，Condition，Action1，Action3是3个函数。

• 0号节点是个Loop节点，循环3次。
• 1号节点是个Sequence节点
• 2号节点模拟一个条件，直接返回成功。
• 3号节点Action1是一个动作，直接返回成功。
• 4号节点Action3同样是一个动作，返回3次运行，然后返回成功。

其代码如下：

bool CBTPlayer::Condition()
{
    m_Frames = 0;
    cout << "\tCondition\n";
    return true;
}
behaviac::EBTStatus CBTPlayer::Action1()
{
    cout << "\tAction1\n";
    return behaviac::BT_SUCCESS;
}
behaviac::EBTStatus CBTPlayer::Action3()
{
    cout << "\tAction3\n";
    m_Frames++;
    if (m_Frames == 3)
    {
        return behaviac::BT_SUCCESS;
    }
    return behaviac::BT_RUNNING;
}

而执行该BT树的C++代码如下：

    int frames = 0;
    behaviac::EBTStatus status = behaviac::BT_RUNNING;
    while (status == behaviac::BT_RUNNING)
    {
        cout << \" frame " << ++frames << std::endl;
        status = g_player->btexec();

        //other codes
    }

上面的执行行为树的代码就如同游戏更新部分。status = g_player->btexec()是在游戏的更新函数（update或tick）里，需要每帧调用。
特别的，对于运行状态，即使运行状态概念上讲是“阻塞”在节点，但是依然是每帧需要调用btexec，也就是说，其节点依然是每帧都在运行，只是下一帧是继续上一帧，从而表现的是运行状态，在其结束之前，其父节点不会把控制转移给其他后续节点。这里的“阻塞”并非真的被阻塞，并非后续的代码(上面的other codes部分)不会被执行。status = g_player->btexec()后面如果有代码，依然被执行。

执行结果会是个什么样的输出呢？

第1帧：
2号节点Condition返回“成功”，继续执行3号Action1节点，同样返回“成功”，接续执行4号Action3，返回“运行”。

第2帧：
由于上一帧4号Action3返回“运行”，直接继续执行4号Action3节点。

第3帧：
由于上一帧4号Action3返回“运行”，直接继续执行4号Action3节点。

同样需要注意的是，2号Condition节点不再被执行。

而且，本次Action3返回“成功”，1号Sequence节点返回成功。0号Loop节点结束第1次迭代。
第4帧：
Loop的第2次迭代开始，就像第1帧的执行。

再进阶

又有聪明的读者要问了，持续返回“运行”状态的节点固然优化了执行，但其结果就像“阻塞”了BT的执行一样，如果发生了其他“重要”的事情需要处理怎么办？

在behaviac里至少有多种办法。

使用前置

每个节点都可以添加前置附件或后置附件。
上图的action节点添加了一个前置，两个后置。

可以添加前置附件，并且“执行时机”设为Update或Both，则在每次执行之前都会先执行前置里配置的条件。

使用Parallel节点

如上图，可以使用Parallel节点来“一边检查条件，一边执行动作”，该条件作为该动作的“Guard”条件。当该条件失败的时候来结束该处于持续运行状态的动作节点。

使用SelectorMonitor节点

• SelectorMonitor是一个动态的选择节点，和Selector相同的是，它选择第一个success的节点，但不同的是，它不是只选择一次，而是每次执行的时候都对其子节点进行选择。如上图所示，假若它选择了下面有True条件的那个节点（节点7）并且下面的1号Sequence节点在运行状态，下一次它执行的时候，它依然会去检查上面的那个8号条件的子树，如果该条件为真，则终止下面的运行节点而执行9号节点。
• WithPrecondition有precondition子树和action子树。只有precondition子树返回success的时候，action子树才能够被执行。

使用Event子树

任何一个BT都可以作为事件子树，作为event附加到任何的一个节点上(用鼠标拖动BT到节点)。当运行该BT的时候，如果发生了某个事件，可以通过Agent::FireEvent来触发该事件，则处于running状态的节点，从下到上都有机会检查是否需要响应该事件，如果有该事件配置，则相应的事件子树就会被触发。请参考behaviac的相关文档获取详细信息。

总结

行为树的基本概念：

• 执行每个节点都会有一个结果（成功，失败或运行）
• 子节点的执行结果由其父节点控制和管理
• 返回运行结果的节点被视作处于运行状态，处于运行状态的节点将被持续执行一直到其返回结束（成功或失败）。在其结束前，其父节点不会把控制转移到后续节点。

其中理解运行状态是理解行为树的关键，也是使用好行为树的关键。

其他

上文另一个例子中“demo_running”的例子在安装包及源码里都有提供。最好查看源码，编译运行，自行尝试体会。
可以查看目录说明

请指定demo_running作为参数或不指定任何参数运行demo_running：

源码及示例下载地址

需要配置“持续时间”，可以是常数、属性或方法的返回值（支持double和int类型），如下图所示：

在工作区配置窗口中，可以勾选左下角的“使用整数值”来表示是否使用整数值，如下图所示：

如果勾选了“使用整数值”选项，那么在导出代码文件behaviac_agent_meta.cpp中，会自动生成Workspace::GetInstance()->SetUseIntValue(true)。

等待节点的更新逻辑是：

bool bUseIntValue = Workspace::GetInstance()->GetUseIntValue();

if (bUseIntValue)
{
    long long time = Workspace::GetInstance()->GetIntValueSinceStartup();

    if (time - this->m_intStart >= this->m_intTime)
    {
        return BT_SUCCESS;
    }
}
else
{
    double time = Workspace::GetInstance()->GetDoubleValueSinceStartup();

    if (time - this->m_start >= this->m_time)
    {
        return BT_SUCCESS;
    }
}

因此，只有保证Workspace::GetInstance()->GetIntValueSinceStartup()或Workspace::GetInstance()->GetDoubleValueSinceStartup()正确的返回从游戏启动到现在的总时间，等待节点才能正确工作。

如果勾选了“使用整数值”选项，那么Workspace::GetInstance()->GetUseIntValue()将返回true，并且该总数值需要通过Workspace::GetInstance()->SetIntValueSinceStartup(long long value)设置，可以在自己的游戏更新函数中调用该函数。

如果没有勾选“使用整数值”选项，那么Workspace::GetInstance()->GetUseIntValue()将返回false。该总时间需要通过Workspace::GetInstance()->SetDoubleValueSinceStartup(double value)设置，可以在自己的游戏更新函数中调用该函数。

注意：在C#代码中相应的接口需改为Workspace.Instance.IntValueSinceStartup或Workspace.Instance.DoubleValueSinceStartup，默认实现方式是返回Unity的系统时间Time.realtimeSinceStartup，一般情况无需自己重新实现，直接使用即可，不用类似C++的接口每帧更新时调用Workspace.Instance.IntValueSinceStartup或Workspace.Instance.DoubleValueSinceStartup为其赋值。

具体的执行逻辑可以查看behaviortree/nodes/actions/wait.cpp

图1 等待帧数节点

需要配置“帧数”，可以是常数、属性或方法的返回值（必须是int类型），如下图所示：

图2 等待帧数节点的属性

等待帧数节点的更新逻辑是:

if (Workspace::GetInstance()->GetFrameSinceStartup() - this->m_start + 1 >= this->m_frames)
{
	return BT_SUCCESS;
}

因此，只有保证Workspace::GetInstance()->GetFrameSinceStartup()正确的返回从游戏启动到当前的总帧数，等待帧数节点才能正确工作。

该总帧数需要通过Workspace::GetInstance()->SetFrameSinceStartup()设置，可以在自己的游戏更新函数中调用该函数。

注意：在C#代码中相应的接口需改为Workspace.Instance.FrameSinceStartup，默认实现方式是返回Unity的当前系统帧数Time.frameCount，一般情况无需自己重新实现，直接使用即可，不用类似以上C++的接口方式每帧更新时再额外调用Workspace.Instance.FrameSinceStartup为其赋值。

具体的执行逻辑可以查看behaviortree/nodes/actions/waitframes.cpp

behaviac组件不仅支持行为树，也支持有限状态机（FSM），并且支持行为树跟状态机的相互嵌套调用。

behaviac组件中的状态机主要用到了状态（State）、等待状态（WaitState）和等待帧数状态（WaitFramesState）三种节点，以及条件转换（Transition）和总是转换（AlwaysTransition）两种附件，如下图所示：

图1 状态机相关节点和附件

状态节点

状态节点（State）是状态机中的基本组成部分之一，可以在状态节点上添加前置、后置以及转换等附件，如下图所示：

图2 状态节点

• 在状态节点上添加的前置：表明进入该状态节点时，需要执行的操作。
• 在状态节点上添加的后置：表明退出该状态节点时，需要执行的操作。
• 在状态节点上添加的转换：表明满足该转换所表示的条件时，由当前状态切换到转换所指向的下一个状态。

如下图所示，可以编辑状态节点的相关属性：

图3 状态节点的属性

• 名字：为状态节点指定一个有意义的名字，以便区分其他状态节点。
• 方法：表示该状态节点需要执行的操作。
• 结束状态：如果勾选，表示该状态作为结束状态，即在执行完该状态节点之后，整个状态机也直接结束。该节点形状也将显示为RoundRectangle，以示区别。

具体的执行逻辑可以查看fsm/fsmstate.cpp

等待状态节点

等待状态节点（WaitState）是一种特殊的状态节点，可以在状态节点上添加前置、后置以及等待转换等附件，如下图所示：

图4 等待状态节点

添加等待状态节点时，会自动的生成唯一的等待转换附件，不接受添加其他类型的转换附件。

如下图所示，可以编辑等待状态节点的相关属性：

图5 等待状态节点的属性

相比状态节点的属性，等待状态节点少了“方法”属性，但多出了一个“持续时间”属性，用来指定需要等待多长时间，可以是常数、属性或方法的返回值。

具体的执行逻辑可以查看fsm/waitstate.cpp

等待帧数状态节点

等待帧数状态节点（WaitFramesState）也是一种特殊的状态节点，可以在状态节点上添加前置、后置以及等待转换等附件，如下图所示：

图6 等待帧数状态节点

添加等待帧数状态节点时，会自动的生成唯一的等待转换附件，不接受添加其他类型的转换附件。

如下图所示，可以编辑等待帧数状态节点的相关属性：

图7 等待帧数状态节点的属性

相比状态节点的属性，等待帧数状态节点少了“方法”属性，但多出了一个“帧数”属性，用来指定需要等待多少帧数，可以是常数、属性或方法的返回值。

具体的执行逻辑可以查看fsm/waitframesstate.cpp

条件转换附件

转换附件（Transition）是状态机中的基本组成部分之一，它表示一个条件，当这个条件满足时，由所在的状态切换到另一个状态，如下图所示：

图8 转换附件

如下图所示，类似条件节点来编辑转换附件的相关属性：

图9 转换附件的属性

此外，在上图中有个“效果”的属性，是转换附件执行完之后需要执行的额外操作。

具体的执行逻辑可以查看fsm/startcondition.cpp

状态转换附件

状态转换附件（StatusTransition）是一种特殊的转换附件，根据它的配置，转换时机会有不同：

1. 总跳转，表示无条件从所在的状态切换到另一个状态，如下图所示
2. 成功时，表示当所在节点是子树并且成功的时候转换
3. 失败时，表示当所在节点是子树并且失败的时候转换
4. 结束时，表示当所在节点是子树并且结束（成功或失败）的时候转换

图10 状态转换附件

具体的执行逻辑可以查看fsm/alwaystransition.cpp

Code bloat occurs because compilers generate code for all templated functions in each translation unit that use them. Back in the day the duplicate code was not consolidated resulting in “code bloat”. These days the duplicate code can be removed at link time.

所以，在看到产生的代码的大小后不要过于惊慌。（另外，编译速度也会比较慢。）

在3.4.0后的版本里，behaviac已经支持了Link Time Optimization（LTO）。LTO可以极大的减少产生代码的大小以及优化产生代码的效率。

gcc

• 如下所示，通过参数指定Release以及ForeUseRelease可以打开LTO（如果你的gcc支持的话）
  cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DBEHAVIAC_VERSION_MODE=ForeUseRelease --build ../../../..
• 或者通过cmake gui设置CMAKE_BUILD_TYPE为Release和BEHAVIAC_VERSION_MODE为ForeUseRelease
• gcc版本需要是4.9以上，低版本不支持LTO
• 其他版本的gcc请参考相应文档设置LTO

msvc

• 在visual studio中可以参考打开编译选项/Gy, /GL及/OPT:ICF /OPT:REF /LTCG链接选项
• 指定ForeUseRelease的时候，cmake生成的项目文件，在Release下缺省的已经打开上述优化开关。
• 也可以考虑调整O1,O2或Ox编译选项

请参考构建说明

behaviac作为图形化的脚本，设计上是用来调用代码（c++，c#）提供的方法，在调用这些方法的时候会有些额外消耗，该消耗已经被充分优化，可以参考消耗。

实践中，要尽量把需要计算的操作由代码实现，通过方法提供给behaviac，behaviac只是去选择这些方法，behaviac作为选择者，发挥behaviac灵活直观的优势。

设计

要想高效的使用behaviac，首先要有好的设计，需要什么Agent，Agent需要有什么属性，什么方法，有一个好的接口。所谓好，是指不能太底层，也不能太高层。

• 太底层，意味着需要进行很多小的计算
• 太高层，意外着失去了灵活性

底层的计算要尽量在代码（c++或c#）实现。behaviac用来做策略选择。

behaviac虽然提供了Assignment，Compute，Compare，IfElse等节点，允许做一些“小的”计算，允许就像写代码一样进行if else的基本选择，但不鼓励这样做。鼓励使用Selector，Sequence，前置，后置等节点及附件。

持续运行的动作

Agent提供的方法，最好是能够持续运行的方法，比如，播放动画，移动一段距离，都是持续很多帧的动作；而不是只是返回某个值，然后再需要在行为树里根据该值做比较，进行计算，再执行其他小的一帧触发的方法。

持续运行的节点在下一帧会被持续继续执行，behaviac不会愚蠢的每一帧都从根节点重新执行。但是，不好的行为树（只是简单的成功或失败，没有返回运行的节点）就会迫使behaviac每一帧都不得不从根节点重新选择。可以参考行为树的基本概念及进阶。

持续运行的动作往往需要大量计算，由代码（c++或c#）实现，behaviac只是在高层去选择使用它，避免大量的计算。这样子，利用behaviac的灵活直观的优势而不会有性能的损失。

并行及选择检测节点

选择监测节点以及并行节点用起来很方便，但是需要提醒的是，相比其他节点，这两个节点比较费。

并行节点每次更新都会更新它所有的子节点（子树），选择监测节点也是如此。不仅如此，这两个节点还会导致接管所在树对处于运行状态节点的控制，形成多一级的控制。（不理解没关系，总之，比其他节点更费。）

不是说这两个节点不能用，但是使用起来请注意其性能，特别的不能滥用，最好不要嵌套这两个节点。

发布版

当发布版本或测量性能的时候，可以定义宏BEHAVIAC_RELEASE关闭开发功能，这样子性能是最优的。或者可以保留开发功能但使用功能开关有选择的关闭或打开开发功能。

关于BEHAVIAC_RELEASE可以参考优化及性能

离线调试

离线调试功能是指在编辑器里加载运行时产生的_behaviac_$_.log文件，如下图，可以加载_behaviac_$_.log文件：

_behaviac_$_.log是运行游戏时产生的log文件。一般都是产生在exe所在的目录，对于Unity，是产生在Assets的同级目录。

在离线调试里，可以模拟游戏的运行，甚至可以设断点，然后查看变量的当前值，可以查看树的执行情况。

文件_behaviac_$_.log只在开发版本下产生，或者是Config::IsLogging为true时产生。

可以参考：优化与性能和开发功能开关。

连调

连调功能是指在游戏运行的时候，编辑器可以连上游戏，实时的查看树的运行情况，变量的当前值，可以设断点等。而离线调试实际上是回放运行时产生的log。

和上面离线调试时需要在开发版本下一样，连调同样需要游戏是开发版本，发布版本下没有连调的功能。可以参考：版本说明和开发功能开关。

除此之外，还需要下面的事项：

1. 请检查Agent::SetIdMask 和 Agent::SetIdFlag的调用是否合适。IdFlag和IdMask都是int，IdMask是个公用的Mask，而IdFlag是设置给某个Agent实例的，当(IdFlag & IdMask)!= 0的时候，该Agent才被调试。
2. 请确保游戏确实在更新，具体可以参考更新流程。Workspace::DebugUpdate需要被调用，如果只是调用Agent::btexec来更新，则连调功能不能正常工作。

有问题可以参考连调相关常见问题

1. version.txt中的版本号和安装包（如BehaviacSetup_3.3.16.exe）的版本号以及编辑器的版本号是一致的。请使用相同版本号的编辑器和运行时。
2. version.txt的存在是用来表明该版本的版本号之用，出现了问题请提供该版本号。
3. version.txt只是从3.3.16版本后才提供，之前的版本中没有该文件。
4. Cpp版本中提供了函数behaviac::GetVersionString()来返回版本号，该版本号和version.txt中的版本号是一致的。
5. Cpp版本运行的时候，有下图所示的信息。
   
   • 第一行就包含了版本信息。其中的debug，NRELEASE等信息是用来表明是否定义了宏_DEBUG或DEBUG,BEHAVIAC_RELEASE
   • 该信息在vs的输出窗口中有输出，在_behaviac_$_$_.log文件里也有输出

除了可以在config.h中定义BEHAVIAC_RELEASE宏为1来完全使‘开发功能’不被编译外。也可以保留这些‘开发’功能但只是使用下面所列的‘开关’来关闭或者打开某些功能。

具体可以参考优化及性能

Cpp

namespace behaviac
{
class BEHAVIAC_API Config
{
public:
static bool IsProfiling();
static void SetProfiling(bool bEnabled);

//logging是否打开
static bool IsLogging();
static void SetLogging(bool bLogging);

//logging打开的情况下，是否每次logging的时候都Flush
static bool IsLoggingFlush();
static void SetLoggingFlush(bool bFlush);

//socket连接是否打开，只有打开socket连接，连调功能才会支持
static bool IsSocketing();
static void SetSocketing(bool bSocketing);

//是否是阻塞模式，当时阻塞模式的时候，游戏会阻塞，等待编辑器的连接，
//只有成功建立连接后，游戏才继续运行
static bool IsSocketBlocking();
static void SetSocketBlocking(bool bBlocking);

//游戏和编辑器建立连接的时候使用的端口
static void SetSocketPort(unsigned short port);
static unsigned short GetSocketPort();

//热加载是否打开
static bool IsHotReload();
static void SetHotReload(bool bHotReload);
};

具体的代码可以查看behaviac/base/workspace.h

Unity

C#下同名函数的意义和Cpp一样，此外，IsSuppressingNonPublicWarning是个用来控制是否输出非public成员的警告。

当IsSuppressingNonPublicWarning为true的时候，Agent的成员（field，method，property）如果不是public的，则输出警告信息，从而可以修改其为public，这样的话，当使用导出格式为c#时其效率就是最高的，而且没有GC Alloc。

具体的代码请查看behaviac/runtime/workspace.cs

缺省的，我们使用cmake来生成对应平台的项目文件（sln或make文件等）。

但cmake不是必须的，也可以选择自己喜欢的方式创建自己的项目文件。比如，使用premake等来生成项目文件，或者手工创建。

Windows平台

• 下载并安装cmake，请使用3.3以上版本
• cmake的路径需要添加到环境变量PATH
• 运行build目录下的cmake_generate_projects.bat生成项目文件
• 如果需要build android版本
  • 需要安装vs2015
  • 使用android_vs2015子目录下的项目文件
  • 或者使用cmake生成项目文件
    • 下载并安装cmake android, 直接覆盖上面步骤安装的cmake就好。
    • 运行build目录下的cmake_generate_projects_android.bat生成项目文件
    • 如果想使用mk，可以修改生成的linux下的make文件

其他平台

• 下载并安装cmake，请使用3.3以上版本
• 如果可能，请保证4.4.6以上版本的gcc
  • 使用版本为4.4.6的gcc可以顺利编译，但4.1.2的gcc有错误（未测试低于4.4.6的版本）
• 运行build目录下的cmake_generate_projects.sh生成项目文件
  • mac上，运行build目录下的cmake_generate_projects_mac.sh生成项目文件

注意

1. cmake_generate*.bat里使用的是vs2013和vs2015，用户可以根据自己的需要选择相应的编译器，比如vs2008、vs2010等，或者通过cmakegui进行选择。
2. CMakeLists.txt里提供的是缺省设置，可以根据自己的需要直接修改或通过cmakegui来选择配置。特别的，CMakeLists.txt里有若干个选项可以配置。
   
   • BEHAVIAC_VERSION_MODE用来控制BEHAVIAC_RELEASE是否定义。BEHAVIAC_RELEASE的用途请参考文章《优化及性能》。
     • Default：缺省模式是Debug下BEHAVIAC_RELEASE没有定义，而Release下BEHAVIAC_RELEASE有定义
     • ForceUseDev：强制不定义BEHAVIAC_RELEASE
     • ForceUseRelease：强制定义BEHAVIAC_RELEASE
       • 在ForceUseRelease的时候，Release下，生成的项目文件会试图打开LTO开关，请参考文档《Cpp生成代码大小的说明》
   • CMAKE_BUILD_TYPE用来控制生成Debug还是Release（Visual Studio的时候不需要指定CMAKE_BUILD_TYPE）
   • BUILD_SHARED_LIBS用来控制libbehaviac是stati lib/a还是dynamid dll/so
   • BUILD_USE_64BITS用来控制是否生成64位 （使用Visual Studio时，需要指定带Win64的generator，请参考cmake的文档）
   • 根据上面的配置，CMake生成下面的_config.h文件，用来自动定义宏BEHAVIAC_RELEASE，如下图所示：
   • 在另一个文件config.h中，会根据_DEBUG或DEBUG宏来尝试重新定义宏BEHAVIAC_RELEASE，如果在_config.h中宏BEHAVIAC_RELEASE并没有定义，如下图所示：
3. cmake不是必须的
   • 你可以选择自己喜欢的其他类似工具，比如premake等来生成项目文件。
   • 或者，你可以手工创建项目文件。
   • 又或者，可以直接把src和inc加到你已有的项目文件。
   • 当你自行修改或创建项目文件的时候，可能需要参考CMakeLists.txt查看需要的设置：
     • include_directories包含目录，你需要设置正确的包含目录
     • add_definitions编译宏，比如_DEBUG
     • add_target_definitions编译宏，比如BEHAVIACDLL_EXPORTS，BEHAVIAC_DLL
     • CMAKE_CXX_FLAGS编译开关
     • BUILD_SHARED_LIBS是否动态库还是静态库
4. build\android_vs2015是提供的缺省的使用Visual Studio 2015来生成android项目的项目工程，支持64位。
5. 可以使用cmakegui选择设置，或者在cmake的命令行里指定设置（ -DCMAKE_BUILD_TYPE=Debug -DBUILD_USE_64BITS=ON等）。请参考build/cmake_generate_projects.bat或者cmake文档。

构建

• 无论Windows平台还是其他平台，项目文件都生成到目录cmake_binary
• 项目文件生成到目录cmake_binary，根据选用的编译工具（vs2013、make等）打开相应目录的项目文件或运行make等进行构建
• .a、.lib、.dll、.exe等被生成到根目录的lib目录和bin目录
• 生成的项目配置(mvsc, linxu, xcode)包含了Debug和Release，请根据需要构建Debug或Release版本

每个使用行为树的对象（Agent）依据这个共享的资源创建独立的实例数据，例如对于Sequence节点，实例数据中只是存储更新到哪个子树，至于Sequence节点的配置信息等则被共享。

• 加载行为树请使用Workspace::Load或Agent::btload
• 卸载行为树请使用Workspace::UnLoad或Agent::btunload
• Workspace::CreateBehaviorTreeTask用来根据加载的行为树资源创建实例数据，而它配套的是Workspace::DestroyBehaviorTreeTask
• 一般情况下，不需要显式调用Workspace::CreateBehaviorTreeTask和Workspace::DestroyBehaviorTreeTask
  • 初始化的时候调用Workspace::Load或Agent::btload加载可能会用到的行为树
  • 游戏循环的时候，根据需要，调用Agent::btsetcurrent指定该Agent当前的行为树，后续Agent::btexec更新的就是当前行为树，除非再次调用Agent::btsetcurrent修改当前行为树
  • 退出的时候，调用Workspace::UnLoad或Agent::btunload，或Workspace::UnLoadAll卸载行为树资源。而行为树实例是在Agent::btsetcurrent的时候被创建的，释放Agent的时候被Agent负责释放
• C#代码是同名类型里的同名函数，如Workspace.Load和Agent.btload

1. 3.6版本的概述，请参考文章《关于新旧版本的说明》。
2. 3.6.x版本的编辑器将导出类型信息代码文件，运行时不需要注册和导出xml类型信息文件。
3. 如果3.6.x版本的编辑器打开之前版本的workspace文件，将读取xml类型信息文件并且转存其中的内容，之后的版本就不再需要xml类型信息文件了
4. 下列宏及函数已删除，升级后使用该宏或代码的相应代码注释掉或删掉即可（升级的时候，只需要修改编译出现错误的部分，其他的不是必须修改的，因为为了尽可能向后兼容，已经把相关宏重新定义为了空）
   1. BEHAVIAC_REGISTER_METHOD/BEHAVIAC_REGISTER_PROPERTY
   2. BEHAVIAC_BEGIN_PROPERTIES/BEHAVIAC_END_PROPERTIES
   3. BEGIN_PROPERTIES_DESCRIPTION/END_PROPERTIES_DESCRIPTION
   4. behaviac::Agent::Register/behaviac::Agent::UnRegister
   5. behaviac::TypeRegister::Register/behaviac::TypeRegister::UnRegister
   6. behaviac::Agent::ExportMetas
5. 升级步骤
   1. 备份程序代码及workspace项目
   2. 删掉老版本中behaviac的所有代码（src及inc等），使用新版本中behaviac的代码（src及inc等）。（因为很多文件被删除，不要只是覆盖！）
   3. 使用新版本的编辑器打开workspace.xml文件，重新导出（可能需要配置“代码生成位置”）
      1. 仔细阅读该说明，点击确定后，你的workspace文件将被更新（不能恢复，除非你预先有备份！）。
      2. 在弹出来的类型信息浏览器中，点击下方的“应用”按钮，生成类型代码文件，点击左下方的“打开代码生成位置”，将生成的类型代码文件添加到程序make文件或项目文件中，并编译构建成为程序的一部分：
      3. 你可能需要通过菜单项“文件->编辑工作区”来配置“代码生成位置”，如下图：
      4. 通过菜单项“文件->导出全部…”，重新导出所有的行为树及生成所有的类型文件，如下图：
   4. 把上一步中导出的源码加入工程中开始编译构建，并修改出现的编译错误，把出错的代码都删掉即可（如上述4中所说，那些宏和函数已删除。只需要修改编译出现错误的部分，其他的不是必须修改的，因为为了尽可能向后兼容，已经把相关宏重新定义为了空）
   5. 如果是C#版本，步骤基本一致。
6. 等待节点和等待帧数节点的使用，请分别参考文档：/language/zh/wait/和/language/zh/waitframes/
7. 按照上述步骤就可以正常运行了。对于“已有实现”的类型，如果需要修改，请参考下面的说明。

对于‘已有实现’的类型

如果需要修改的话，有两个流程可以选择。可以选择生成代码，也可以选择不生成代码，请参考下面的步骤，选择自己适合的方式。

生成代码

1. 打开类型信息浏览器，如下图，“生成代码?”没有勾选上的类型就是在程序里已经实现的类型，程序里已经有了相应的类型声明以及函数定义的代码。如下图中的ChildNodeTest在代码里已经有’class ChildNodeTest’了。
2. 勾选上该Checkbox，然后点击“应用”，会生成类型文件。
3. 点击“打开代码生成位置”，可以看到ChildNodeTest.cs被生成了。在上图类型信息浏览器中，每个类的“生成位置”可以用来配置该类的生成位置，如果不配置，则使用工作区统一配置的代码生成位置。
4. 打开ChildNodeTest.cs，可以看到如下，只能在红色框内添加自己的代码。红色框外面的修改将会在重新生成代码的时候被丢弃！需要手工的把原来类型中的代码复制到新生成的类里，而把原来的文件删掉！否则会有重复定义的错误产生。
5. 从上可知，如果要修改类型名、成员名，请在“类型信息浏览器”中修改，然后“应用”就可以生成更新的代码。而其他相关代码只能添加在‘///<<< BEGIN WRITING YOUR CODE’和‘///<<< END WRITING YOUR CODE’中间，添加在这个块外面的代码在重新生成代码的时候将会丢失！C++代码也是同样的处理。不要手工修改‘///<<< BEGIN WRITING YOUR CODE’后面的内容（例如FILE_INIT，FILE_UNINIT，CLASS_PART等），该内容在重新生成代码的时候将被使用到。
6. 对于enum和struct，如果需要修改，也需要勾选上其”生成代码?”的Checkbox。

不生成代码

上述生成代码的流程，需要手工的把原来的代码copy/paste到生成的代码文件中有“///<<< BEGIN WRITING YOUR CODE’和‘///<<< END WRITING YOUR CODE”这样的注释块中间，比较麻烦！而且有人可能并不喜欢这样的形式，那么可以采取下面的流程：

1. 不要勾选“生成代码?”，任何修改依然在原来自己维护的代码中进行。
2. 任何需要在行为树中暴露的属性或方法需要在类型信息浏览器中同样的添加，否则编辑器中将看不到该属性或方法，即不能被使用。但原来已有的不需要重复加入，添加后需要点击“应用”重新生成胶水代码。
3. 另一方面，如果只是在编辑器中添加了属性或方法（添加后需要点击“应用”重新生成胶水代码），而在你的代码中没有相应的修改，编译程序的时候，会有编译错误。
4. 如果运行没有重新编译的程序，有可能会有报错发生：
   1. 当只是添加了属性的时候，如果没有使用“应用”后重新生成的代码编译构建程序，而使用老的程序的时候，可以正常运行，只是新添加的属性作为自定义属性使用而已（编译构建后，新添加的属性就将作为Agent的真正成员，效率最高）。
   2. 当修改了方法（添加或改名），如果没有使用“应用”后重新生成的代码编译构建程序，而使用老的程序的时候，会有错误发生，在_behaviac_$_$.log中会有详细的错误输出。

总结比较

从上面可以知道，对于从老版本升级到3.6.*的情况下，对于已经有了大量代码的类来说，可以选择依然使用原来的代码，或者可以选择生成代码。

使用原来的代码的好处是不需要copy/paste大量代码到新生成的类型文件中了，并且所有的代码都可以保持原来的风格，缺点是之后任何关于属性、方法的修改（改名、添加、删除等）都需要在类型信息浏览器中重复的做一遍。

选择生成代码的缺点是需要手工copy/paste大量的代码到新生成的类型文件里，并且需要忍受begin/end注释块的束缚。但好处是后续的修改都只需要在类型信息浏览器中改一次，重新生成就好了。

实际上即使对于选择了生成代码的情况，后续也可以再选择不生成代码，反之亦然。选择生成代码，则编辑器负责在你指定的位置生成代码；而选择不生成代码，编辑器将不为你生成代码，所有的代码由你自己来维护。二选一，如果选择生成代码，而自己原来维护的代码没用删掉，则会有编译错误！

另外，需要说明的是，这里的生成代码是指生成class的声明代码（.h和.cpp，或者.cs）。而不管这里是否选择生成代码，在点击“应用”的时候，都会生成所有类型的胶水代码，可以在配置的代码生成位置查看生成的behaviac_agent_meta.cpp文件或AgentProperties.cs，里面的代码就是所谓的“胶水”代码。

此外，我们知道，行为树的导出格式可以是xml或bson，也可以导出cpp或c#代码。即使采用xml或bson格式的时候，这里的“胶水”代码或者类型代码都会被生成，而且需要被添加到工程项目中参与编译构建！

相比3.4.x版本，3.5.x版本有若干重大改动

1. 用最新的代码把你们的游戏能够编译运行（如果可能首先删除旧的的代码及导出数据，用新代码替换。）
2. 导出最新的meta的xml文件
3. 用最新版本的编辑器打开老的workspace，重新导出
4. 用3中导出的新的文件，重新编译构建，运行游戏

大版本升级，导出文件的版本号都会有改变，不严格按照上述步骤的话，在运行游戏或编辑器的时候都会有报错。而小版本的升级的时候，导出文件的版本号没有改变，可以不严格按照上述步骤。

对于unity，3.5.3及以后的版本，在上述步骤3中导出文件的时候，会生成c#文件（AgentProperties.cs和customizedtypes.cs），需要添加都项目中，否则运行时会发生错误。

为了支持C# GC Free，生成的代码有大的变化，需要按照上述升级步骤升级版本，否则运行游戏或者编辑器都会有报错。

相比2.x版本，3.x版本有若干重大改动

1. meta browser， 变量的使用更加统一和方便
2. preaction/postaction，任何一个节点都可以添加前置和后置，统一了用法和体验
3. 支持了FSM

相比2.x版本，API的改动（请参考test/unittest或test/usertest中的代码）：

• 删掉了behaviac::Start, behaviac::Stop
• LogManager::SetEnable -> Config::SetLogging
• 删掉了World
• 删掉了SetWorkspaceSettings
• 删掉了REGISTER_EVENT
• bttick rename to btexec
• DECLARE_BEHAVIAC_OBJECT_NOVIRTUAL rename to DECLARE_BEHAVIAC_OBJECT_STRUCT
• 删掉了REGISTER_METHOD_CHECKRESULT
• RegisterName -> RegisterIntanceName, UnRegisterName -> UnRegisterIntanceName
• behaviac::Property::Registger, behaviac::Condition::Register -> behaviac::TypeRegister::Register, UnRegister类似
• 在所有加载BT之前，调用behaviac::Workspace::GetInstance()->SetFilePath和behaviac:: Workspace::GetInstance()->SetFileFormat来设置路径和格式
• behaviac::Workspace::ExportMetas修改为behaviac::Workspace::GetInstance()->ExportMetas，其他相应的对Workspace的函数的调用也要类似的修改
• 删掉了Workspace::LogFrames和Workspace::HandleRequests, 添加了Workspace::DebugUpdate
• behaviac::World::GetInstance()->btexec()修改为behaviac::Workspace::GetInstance()->Update()