After my talk at GDC, a few people wondered what a behavior tree editor actually looks like since I kept mentioning their benefits, including their flexibility and intuitiveness. From my experience with the AI designers at Rockstar, I noticed a boost in productivity of multiple orders of magnitude by providing them with this kind of tool.
I also mentioned that it shouldn’t take much more than one man-month of work to get a good editor up and running — but that’s being conservative! So, I decided to put my time where my mouth is and create a quick prototype on my way back from Lyon. Here’s the result:
Of course, there are lots of things missing and the code right now is a collage of the wxPython samples, but it’s a start! Comments welcome…
5 Comments ↓
Very nice. Behaviour trees are especially suited for this kind of interface, and AI Designers definitely prefer “programming with the mouse” to typing code.
However, I would consider your estimate of one man-month to be optimistic, not conservative. Sure you can get something up and running much faster than that, and then you’ll spend many months polishing and improving it to get a production-strength editor, that’s fully featured, robust and bug-free, easy to use, fast, is integrated with the game so you support hot-loading, has a rich interface (e.g. for actions with tens of parameters), nice different icons for sequences and parallels, can be saved/loaded from a text file and a binary one, etc.
We have a similar editor here, written in QT, and it’s been in development for several months, and gone through two full iterations already, as the first version was very organic (read, chaotic).
Sergio,
Working from a fully capable behavior tree implementation, it took me a month to get it to the state where designers would be able to use the editor for editing all the behaviors we did in the previous milestone. It also took a little less than a month to get to a point where they no longer questioned the concept and saw its potential!
But you’re absolutely right, I was still working on features for months after, and it’s something you’ll no doubt have to do right until you ship the game!
What do you mean by chaotic? The editor I made was simple enough not to get very complex. The only part that needed refactoring eventually was the right click menu :-)
Alex
P.S. I have also found that using C++ to implement user interfaces is generally a much slower process (e.g. QT). With wxPython you can be up and running much faster…
By chaotic I mean that some of the UI decisions that were made in the first version were driven more by “we have this new feature/screen, now, where do we put it?” than by a reasoned plan.
Our tree is used by several systems, not only AI, but animation, level scripting, prop logic, effects and, essentially, anywhere where you want to drop a tunable FSM. Trees can be global or tied to specific characters. The interface has to present the choices on what actions/groups are available (we have tens of different ones for each tree), the parameters (which can be not only numbers, but strings, selection lists, points in space, game assets, etc), and the history window we use for debugging. And it has to do this for each of the dozen or so of trees we use. Building a good structure to display all this information in a clear way is no small feat, and there were a lot of rough edges in the first implementation.
I get the feeling that a visual editor that was a bit more “visual” might get a bit more designer loving. Something like the kismet thing they have in UT3 these days might do it.
But hell, you got me fired up for trying out this behavior tree malarkey and coding up an interface for that in C# sounds like a fun way to spend a few days.
Would it make sense to extend this “editor” to act as some sort of remote debug interface do you think (i.e. as the game runs, it sends info to the editor to allow you to single step the tree as it gets traversed).
Might be thinking too much there :) hahaha.
Nice one alex, will update when I’ve had a chance to try this.
I’m working on a Python implementation of Behavior Trees, and it struck me that XML would be an appropriate format for storing the structure. Using Eclipse, I spent a little bit of time designing an XML Schema to describe the structure, and now I have a Behavior Tree Editor for free: Eclipse has a built-in point-and-click XML editor that’s better-refined than anything I could come up with in a month.
Alex, thanks for all the articles on Behavior Trees. They’ve been extremely helpful!
Leave a Comment
You can also reply to this thread in the forums.