BadBehavior - Behavior trees for T3D
by Guy Allard · 06/21/2012 (6:30 am) · 12 comments
BadBehavior - Behavior trees for T3D
The last 5 years have seen behavior trees establish themselves as the must have AI tool for creating complex AI in games.
For a background on what they are and how they work, take a look at the excellent free articles at aigamedev.com, the blogs by Bjoern Knafla.
James Ford, Daniel Buckmaster and Konrad Kiss have posted about their behavior tree implementations using torque engines.
Here's my version.
Rather than write lots of words about it, here are some videos :)
(bah, can't figure out the embedding, so here are the links) -
Part1: Creating a simple behavior for use by an AIPlayer
Part2: Making a slightly more complicated behavior
Part3: Assembling complex behaviors from simpler building blocks
I think it's pretty obvious from the videos that you can create good behaviors with minimal scripting.
For me, the great thing about it is being able to mix and match the behaviours to quickly create a range of different trees.
You essentially have a modular, visual programming language that once learned is easy to use and is intuitive.
At the moment, trees can be built from the following components:
Sequence
Parallel
PrioritySelector
RandomSelector - like the priority selector, but chooses its children in a random order
Command - a leaf node that executes some torque script.
Condition - a leaf node that evaluates a torque script conditional statement
Inverter
SucceedAlways
Wait - doesnt execute its child until a random period of time has passed
RandomWait - like wait, but waits for a random period of time
Loop - repeats its children until certain criteria are satisfied
Logger - to help with debugging trees, outputs info to the console.
Currently, when a tree is assigned to an object (can be any object, not just AIPlayers) the object makes its own copy of the tree which it uses internally. The tree is evaluated by a separate 'ticker' class that processes the nodes sequentially from a queue, avoiding problems with recursion that some implementations suffer with. My next task is to separate the execution logic from the tree definition which will reduce the resources needed by each running tree.
Hopefully, you think they're as cool as I do.
Questions?
The last 5 years have seen behavior trees establish themselves as the must have AI tool for creating complex AI in games.
For a background on what they are and how they work, take a look at the excellent free articles at aigamedev.com, the blogs by Bjoern Knafla.
James Ford, Daniel Buckmaster and Konrad Kiss have posted about their behavior tree implementations using torque engines.
Here's my version.
Rather than write lots of words about it, here are some videos :)
(bah, can't figure out the embedding, so here are the links) -
Part1: Creating a simple behavior for use by an AIPlayer
Part2: Making a slightly more complicated behavior
Part3: Assembling complex behaviors from simpler building blocks
I think it's pretty obvious from the videos that you can create good behaviors with minimal scripting.
For me, the great thing about it is being able to mix and match the behaviours to quickly create a range of different trees.
You essentially have a modular, visual programming language that once learned is easy to use and is intuitive.
At the moment, trees can be built from the following components:
Sequence
Parallel
PrioritySelector
RandomSelector - like the priority selector, but chooses its children in a random order
Command - a leaf node that executes some torque script.
Condition - a leaf node that evaluates a torque script conditional statement
Inverter
SucceedAlways
Wait - doesnt execute its child until a random period of time has passed
RandomWait - like wait, but waits for a random period of time
Loop - repeats its children until certain criteria are satisfied
Logger - to help with debugging trees, outputs info to the console.
Currently, when a tree is assigned to an object (can be any object, not just AIPlayers) the object makes its own copy of the tree which it uses internally. The tree is evaluated by a separate 'ticker' class that processes the nodes sequentially from a queue, avoiding problems with recursion that some implementations suffer with. My next task is to separate the execution logic from the tree definition which will reduce the resources needed by each running tree.
Hopefully, you think they're as cool as I do.
Questions?
#2
06/21/2012 (3:00 pm)
This would be a great resource to have added to the CEV. 
#3
06/21/2012 (3:02 pm)
Spectacular work, Guy! Please keep us updated on your progress! 
#4
06/21/2012 (4:23 pm)
Now that I could use :) looks excellent, keep us posted! 
#5
06/21/2012 (5:16 pm)
That looks like great work Guy! 
#6
06/21/2012 (8:49 pm)
Good work! This looks awesomely cool. Having code is good, but having an editor is even better ;). 
#7
06/21/2012 (11:09 pm)
Now that is pretty sweet. Hope to see it as a resource or as a purchased add-on in the near future. =) 
#8
06/22/2012 (8:33 am)
That is awesome! Keep up the great work and keep us informed on your progress! 
#9
06/24/2012 (7:35 am)
Looks very cool indeed, but is it using evals to convert the text to actions? If it does, it wouldn't be an efficient solution and would cause trouble with several AI's in the game.
#10
06/24/2012 (6:43 pm)
This is just awesome. Finally watched the videos and it is really well done. 
#11
Edit: Question, what are the plans for this implementation?
06/25/2012 (4:07 pm)
Congrats Guy, jood job!Edit: Question, what are the plans for this implementation?
#12
@Lukas, it doesn't use eval.
Most of the nodes are entirely c++, with only the leaves using hooks into torque script. This could cause performance issues if the script hooks are complicated functions, but so far simple commands and condition checks are all that's needed. All of The leaves aren't evaluated every time the tree is ticked, and so far my profiling indicates that just rendering an AIPlayer is an order of magnitude more costly than the evaluation of the tree actions.
I've recently implemented a timer decorator, which controls the rate at which its subnodes get ticked, so performance can be controlled even further by giving the user the ability to control the speed at which individual parts of the tree tick.
I'm also working on 'loop until event' and 'wait for event' decorators which will passively wait until their required event (e.g. onReachDestination) has occurred, instead of polling for a condition check each tick.
@Novack, I'm not sure what my plans for this are atm. Get in touch on messenger if you want to chat about it some more.
07/01/2012 (11:32 am)
Thanks for the comments.@Lukas, it doesn't use eval.
Most of the nodes are entirely c++, with only the leaves using hooks into torque script. This could cause performance issues if the script hooks are complicated functions, but so far simple commands and condition checks are all that's needed. All of The leaves aren't evaluated every time the tree is ticked, and so far my profiling indicates that just rendering an AIPlayer is an order of magnitude more costly than the evaluation of the tree actions.
I've recently implemented a timer decorator, which controls the rate at which its subnodes get ticked, so performance can be controlled even further by giving the user the ability to control the speed at which individual parts of the tree tick.
I'm also working on 'loop until event' and 'wait for event' decorators which will passively wait until their required event (e.g. onReachDestination) has occurred, instead of polling for a condition check each tick.
@Novack, I'm not sure what my plans for this are atm. Get in touch on messenger if you want to chat about it some more.
Associate Steve Acaster
[YorkshireRifles.com]