[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.3.9 Behaviour Tree

Property Class Details

General Information

A behaviour tree is an ai tool for designing character behaviours and controlling enitities. A CEL behaviour tree can replicate any standard FSM in an intuitive manner. Behaviour trees are responsive and useful for programming standard behaviours with fallback plans.

Anybody interested in this tool is highly recommended to visit http://www.AiGameDev.com, specifically these freely available resources:

CEL's behaviour tree is based on the 2nd generation event-driven design.


Each node of a CEL behaviour tree must implement the iBTNode interface. The key methods for designing a behaviour tree are the AddChild and SetName methods. Setting a name for a node can be very useful when debugging trees as the errors reported will name the nodes responsible.

The basic nodes provided are very descriptive and powerful when used in combination, however, it is possible for developers to create their own nodes if they wish to add unavailable functionality to their tree. The macros CEL_DECLARE_BTNODE(className) and CEL_IMPLEMENT_BTNODE(className) can simplify the process. If used, the developer only needs to implement the node's AddChild and Execute methods. Execute returns a BTStatus indicative of the current state of the node. If not using the macros provided, the developer must also implement the node's Initialize, SetStatus, GetStatus and SetName methods.


At any time, behaviour tree nodes must be in one of the following five states:

For more information on the difference between BT_FAIL_CLEAN and BT_UNEXPECTED_ERROR please see this article.

Selectors (plgSelectors)

A selector is a composite node, it has multiple children that it must decide which to execute. The following selectors are available at this time in CEL:

Leaf Nodes (plgBehaviourTree)

The leaf nodes of a behaviour tree are where conditions are evaluated or actions performed. To make use of CEL rewards, triggers and parameters, the following wrapping classes are available.

It is possible to define your own leaf nodes and it is expected that many developers may choose to implement bespoke conditional nodes for checking game specific data.

Decorators (plgDecorators)

Decorators tend to have only one child (although they are not limited to as such). There purpose is not to decide an action to take but to add some functionality to their child node/subtree. A number of decorators have been implemented as default in CEL, they are:

Again it is possible to define your own decorators by implementing the iBTNode interace. It is hoped that as public use of the CEL behaviour tree grows, so will the library of available decorators. Their potential uses covers a wide spectrum of possibilities and the more available the more powerful the tool becomes.

Construction and Execution

Finally to construct a behaviour tree, each node must be connected to its children using its own AddChild (iBTNode* child) method from the interface iBTNode. The "root node" property of the propclass must then be set as a csRef<iBTNode>.

Alternatively, the behaviour tree can be loaded from XML by setting the propclass property "xml" to a csRef<iDocumentNode> pointing to the root of the tree in XML and then executing the action "Load BT From XML".

Other properties of the behavioure tree propclass that can be set are the "tree name" and "update rate". The latter being the number of nodes in the tree that will be executed per frame.

Once set up the tree can be started by performing the propclass action "BT Start" and stopped by "BT Interrupt".

An example of constructing or loading a behaviour tree from XML is implemented in appbttest and discussed in the related tutorial (see section BTTest Tutorial.)

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html 1.76.