More Behavior Tree Goodness

Following on from my previous blog, I've been working on some extra goodness for my BadBehavior behavior tree kit.

Behind the scenes, I've changed the way that the trees are handled internally by objects that are using them. Previously, each object using a tree was given its own copy of the tree to evaluate. As each node of the tree is a separate SimObject, that was getting quite expensive in terms of memory. Now when a unit is given a tree to run, it creates lightweight tasks for each node of the tree to be executed. Much more memory efficient.

The next upgrade was to modify the way that the condition and command tasks work. Previously they were running arbitrary script commands, and even though these were all being evaluated engine side, I wasn't happy with their performance.


The above image shows the new condition node. It looks similar to the old one, but instead of running arbitrary torque script, the conditionFunc field now specifies a function to be run that returns true or false. Internally, it is evaluated using Con::execute, and I've gained a performance increase of at least 4x.



This image shows the new command node. The important part here is the func field, which specifies the name of a function in the namespace of the object running the tree. The four args fields allow arguments to be passed to that function. So the example command node when it is executed calls %obj.moveAlongPath(PatrolPath). Again, this uses Con::execute internally, and is also at least 4x faster than the old version.

As the new condition and command nodes are slightly less flexible than the old system, I've also added a new ScriptTask node (not shown) which is able to execute arbitrary torque script. This can be used when a simple condition or single command is insufficient (you could do container searches etc with it if you wanted).



The next new feature is the ticker decorator. This node acts like a timer, and controls how often the node can be executed. In the example, the ticker limits the branch that checks for a player to only execute once per second. By sprinking these tickers throughout the tree you gain fine grained control over how often expensive tasks are run.



Finally, the behavior tree system now has event handling. This has allowed for two new decorator node types - WaitForEvent and LoopUntilEvent. In the example, I'm using a WaitForEvent decorator to pause the execution of the movement branch until the bot has received an onReachDestination event. Before, we actively checked each tick if the player had reached its destination, now we can just do nothing until the event is received.
The LoopUntilEvent decorator (not shown) works like a normal loop decorator, but it stops running when it receives the event it is listening for.


I have a couple of jobs that are going to take me away from this over the next week or two, but when I am able to get back to it, my next plan is to get the behavior tree editor integrated within the T3D editor framework so that it seamlessly fits in with the other tools, and can take advantage of the undo/redo facility and the persistance manager.

After that, I want to put together some more example trees to demonstrate how quickly you can create a variety of interesting AI with just a few mouse clicks.