Here is part 2 of my lecture at the GDC in Lyon two weeks ago. Be sure to view the overview of behavior trees in part 1 first if you haven’t already. This video is exactly 21:48 minutes long, and is worth roughly 7.9 Mb of bandwidth!
In the video, I go over the process of making behavior trees easy to edit by using modular building blocks like decorators and filters. I also discuss the process of setting up a goal architecture with the behavior tree using a lookup table, and how you can both automate the process of assembling large trees — yet still get full control over the behaviors. Finally, I provide tips to deal with reactive planning in practice to make the most of the simple implementation of behavior trees.
This video is better quality than the previous video as I’ve got a bit more comfortable with the tools! (Note: Use Firefox if you have problems with other browsers.) The third and final part will be posted next Sunday… Be sure to subscribe to be notified when it’s released.
Comments
Comment on this article. | Show full forum thread.The logic for selecting sub-branches can be entirely customized. There's no built in mechanism for estimating probability of success, but you could implement that yourself modularly.
Alex
However i think the proposed usage of assertions breaks modularity.
Consider the example with the dog and his bone.
If we put these assertions at levels with lookup dependencies, then we effectively say "no hungry dog will ever be able to take the bone from another dog", or "No hungry dog will ever be able to beg his master for a new bone".
So if we want to create an alpha-dog(that can steal other dogs' bones) we would have to copy the normal "Satisfy hunger" tree and remove the assertion. Or hack the assertion to take alpha-dogs into account. Which ever solution breaks modularity.
I think the assertions should only be placed on levels in the tree where no lookup-dependencies exists (neither at the same level or levels below)
Great job, looking forward to part3!!
Johan
If the conditions are not met, the behavior can't be executed successfully because it breaks fundamental assumptions about the state of the world.
Instead of breaking modularity, to me the assertions help define the context in which the behavior can be reused.
It's not quite so black and white, but you both brought up great points. In the ideal case of faking full lookahead planning, the "assert" would do the same thing as the actual execution tree, so there would be no modularity at runtime since the logic must be duplicated.
If you want to support this using the traditional reactive planning approach, then you have to make a certain amount of assumptions from the behaviors. The more assumptions you make, the more you have to dig into the behaviors and break modularity...
However, two points which mean it's still modular for the designers:
• Your asserts often only help check only what the dependencies are designed to fulfill. That's the case of the bone.
• The asserts can be built partly or entirely using tools, so you build an assert tree offline that effectively does full planning for you within a reactive tree!
Of course it's a compromise, but most often there are ways to get around limitations!
Alex
Is the tree "evaluated" from the root down to a leaf "often"/"all the time"?
What is the root conceptually?
A Behaviour tree is a generalized Petri Net (see www.cse.unsw.edu.au/~rhamadi/pub/BPM_2003.pdf on Petri Nets for workflow specifications). An NPC has a Petri net where places represent tasks for the NPC and admits all possible tasks and sub-tasks. The system prunes this Petri net of all impossible tasks in a given game state, which results in a Petri net of permissible firing sequences. The system selects a firing sequence for the NPC and the NPC performs tasks in that firing sequence.
I am interested in how the system selects the appropriate firing sequence, can the system evaluate the probability of success for a firing sequence?
Cheers Rune.