Archives for: June 2012, 01


Early Design Decisions & Progress on Event Driven Behaviour Trees

Permalink 21:47:24, Categories: GSoC 2012  

Hello CrystalSpace,
First, to quickly wrap up last week's discussion of the problems with a few apps hanging, I have raised a ticket covering this problem (Ticket 103) and will look to help with a solution later into the summer once I am sure to have met the planned deadlines.

This week work moved on to focus on beginning to implement event driven behaviour trees (BTs). I spent some time studying openly available implementations and have made some initial decisions that I would like to discuss briefly.

The current CrystalSpace BTs parse the entire tree every frame starting from the root node. This will obviously not scale well to large trees or games with many trees. Event driven BTs instead remember where in the tree they have reached and parse only active nodes on each callback.

Therefore, my intention is to add a stack of pointers to BT nodes to the behaviour tree and pass a pointer to this to a node when it is executed. This way parent nodes can push their child nodes to the stack instead of calling their children themselves. Then when the behaviour tree receives it's callback it only needs to execute the top node on the stack.

This will reduce the number of nodes executed per callback to a constant number. It should also help with debugging, as by watching the stack a developer can understand which nodes in the tree are being executed and which path has been taken to reach there.

Furthermore, this should allow me to easily add the function of being able to control the rate of updating a BT as the top node can be executed multiple times per callback (with the callback set to either every frame or by time.) On each execution of the top node the subsequent top node may change and so repeat execution of the top node is effectively parsing through the tree.

Whilst exploring existing implementations and designing our solution I noticed that the easiest milestone to add first was Christian's suggestion of extending the termination statuses. Previously a node would indicate only success or failure on termination, but now (as of revision 4899) a failing node can indicate whether it failed cleanly or whether it has exited unexpectedly. (For more detail on why this is useful please see this article.)

This revision will be used more in the upcoming work on event driven BT's as a parent node will want to check the final status of a child node once the child has terminated and the parent has returned to the top of the stack. To do so I intend to add the current status of a node as a public variable of the iBTNode interface.

Please feel free to comment on this blog, email me on the mailing list or catch me in the IRC channel if you have any comments or suggestions.

As mentioned in my proposal I am now leaving for a conference, and so will not be updating the blog next week nor likely to commit any code. However, I do have my linux laptop with me and the source code checked out, so I may get time to think more about the design and look further into prop classes and existing XML code in CEL (as needed for the later BT milestones.) I will update the blog again Friday 15th June.

See you all in 2 weeks time, Sam.

June 2012
Mon Tue Wed Thu Fri Sat Sun
 << < Current> >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  




XML Feeds

What is this?

powered by