While the goal of Behave keeps it at a highly abstract level of operation, there are many simple to implement, yet powerful patterns of use.

A common pattern is that your agent class is also the one ticking its behaviour tree instance(s) at a frame rate. Through the Behave tree designer UI, a designer can link a different frame rate to each tree. This has no direct practical implication at runtime though. Its purpose is merely to communicate a desire from designer to implementer.

Not being limited to frame rate execution, ticks could just as well occur in response to an event – be that a game / simulation event or even an action handler invocation from another tree. Again, note that any agent can have multiple trees associated with it.


An example of such non-frame-rate ticks could be for use in intelligent items. These are items with embedded behaviour trees – ticked by item consumers when needed. In a game, such an item might be a weapon.

The agent would have a reference to its currently equipped weapon and in response to action ticks from its main tree, tick relevant trees referenced by the weapon and return the result as the action result.

Aside from the obvious “attack” action / embedded tree combination, these could also be availability and range checks.


A more simple case would be the agent implementation of a dynamic or “lookup” selector. In some cases, branch selection is not simple enough that is can be expressed in simple control nodes – more state awareness is required.

In such a case, an agent might hold a collection of trees in addition to its main tree. On tick / init or reset of certain actions, the agent would then pick an appropriate tree from the collection (based on agent state) and invoke the appropriate handler on that.

This can be particularly useful if, like with embedding, the agent needs to be able to receive certain behaviour for execution at runtime, relevant in only a specific scenario or section of simulation duration.

In the case of a game, such behaviour could be related to dynamic quest or story systems or crowd simulations where characters are dynamically moved between low-cost milling behaviour and more costly, interactive behaviours.


Action forwards allow for events from multiple actions to be handled by the same handler which could be implemented by the same agent or an entirely different class.

One use case for this could be a squad system which uses agents based on the selection pattern to assign task trees to agents in a squad. Trees which upon task completion need to inform the squad system at certain points in task execution – such as start and end.

By using action forwards on the task trees, the squad system can ensure low complexity agent class while preserving the ability to do extensive special casing of task events.