Tree Nodes
Every Behavior Tree is composed of many Nodes. Here we shine some light on what the Nodes actually are.
Every Node implements the BehaviorNode interface. Not to clutter this page up, click here to see the API it specifies. The important bits are:
-
getName()- required for every node - this is what identifies the node for the BT / prefab system.
-
construct(actor)- called when a Node begins executing - when it is reached in the tree.
-
execute(actor)- called each time the node is executed - when the interpreter ticks and the tree is in a state where the node is executing.
-
destruct(actor)- called when a node finishes executing.
- child management methods
- these are self-explanatory, with children stored by index.
- implementation differs widely based on node type - more info in their respective categories
Control Flow nodes are responsible for the 'logic' parts of the behavior tree - they ensure some nodes are only run in a sequence, some run in parallel, some are run exactly n amount of times, etc. Some Decorator nodes fall into this category (e.g. Timer, Inverter, Counter).
More on control flow nodes here: Control Flow Nodes.
Action and Decorator nodes are what most creators will be concerned with, in terms of creating new nodes.
-
Action nodes are leaves - nodes with no children. They are what enables the entity to have visible behavior traits - the actual actions the entity takes are defined in
Actions. -
Decorator nodes are nodes with strictly one child, usually an
ActionNode, adding functionality to the child or modifying its return state.
Actions and Decorators are loaded dynamically using the @BehaviorAction annotation.
An in-depth look at Actions, Decorators and how to use them is here: Action Nodes, Decorators.
In order to save on RAM and some processor cycles, some nodes (notably Actions and Decorators) are created only once per behavior tree, and are stateless in nature - the state needs to be stored at the Actor. More on this here.