While many established high-level AI middleware companies are apparently focusing on finite state machines, the rest of the industry seems to have converged towards behavior trees. I'm sure you're wondering, why hasn't anyone shifted their focus to BTs or why haven't any new companies taken up the challenge? As of today, that's all changed...
There's now a new startup dedicated to behavior trees, and they've been hard at work on their new middleware product. Here's the official announcement about GameBrains:
“GameBrains, a Dublin-based AI middleware company and commercial pioneers of Behavior Tree technology, have released their integrated SDK, a graphical editor and runtime code library for the rapid development and debugging of Behavior Tree based AI. CEO Paul Hayes, MD Shane Ryan, CTO Diego Pérez, creative lead Joe Roe and the rest of the GameBrains team are excited to give a peak at their latest technology.”
As you'll find out in the rest of this article written by the team, GameBrains is designed to provide all your behavior tree needs, either through their pre-made solution or with a custom solution for your own unique needs. The team is also very serious about providing great support.
GameBrains currently has (limited) spaces for a beta program and is interested in partnerships with games companies. To contact them or find out more information, visit their official site, or follow them on Twitter at @GameBrainsAI.
Behavior Tree Editor in Action
Alex Champandard: Some developers feel that AI is very game specific and how you implement your decision making has a huge impact on the final product. How does GameBrains address these issues?
Diego Pérez: As GameBrains is based on behavior tree technology, the real question is how do behavior trees help the decision making process. Or, in other words, how do behavior trees affect the decision making process differently than other systems like planners or finite state machines?
On the planning side, planners are very good at very controlled environments. So if you can prepare each small task in advance to address specific situations they work great. However, they are not good at a reactive level. If things change they have to create new plans in real time with a ton of overhead, and this affects the responsiveness of the game AI. Finite state machines are really easy to use and implement, but they lack in scalability, reusability and you can find yourself dealing with deadlocks when executing many of them at the same time. There are some work-arounds to some of these problems, like hierarchical state machines, but then you lose most of the advantages that come from FSM’s simplicity. And even hierarchical FSMs still have problems of scalability as they grow in size and complexity.
The advantage that behavior trees have over these approaches is that they are simple and intuitive, scalable and hierarchical, and without most of the drawbacks of hierarchical finite state machines. They are also very good for reactive processes, and this helps a lot when designing the decisions of characters that must be responsive to changes in the world. BTs have also very good reusability; you can reuse the same subtree all over the tree with (or without) small modifications, to provide different solutions. To do that in a state machine, for instance, you would have to include more and more transitions that would rapidly increase the complexity and reduce the state machine’s reusability. In the end, this could turn it into a spaghetti code nightmare.
GameBrains is based on behavior trees, and our objective is to give a lot of scope to designers and developers. We are trying not to add any restrictions to them. In that way, they can design their own nodes, customize the existing ones and use our own software in ways we never considered.
AC: Now developers are mastering this generation of console hardware, performance in the actual execution of BTs is becoming a big concern. What have you planned to address performance?
DP: The biggest bottleneck in BT performance is not typically the BT itself, but the external functions called by the leaf nodes. This is because the transitions between the nodes in the tree are so fast that relatively speaking they don’t become a performance issue. To date most of our focus has been on the front end and keeping our runtime small and fast. But moving ahead our objective is to work very closely with the developers to address all the kinds of performance issues they encounter. We have planned in our roadmap to work closely with developers to create memory and performance profiling, pointer hydration and make some efficient tools to identify bottlenecks in the code. BTs lend themselves very well to profiling because of their tree like structure you can easily find the bottlenecks with a simple binary search.
AC: As a community, we're becoming more and more comfortable with behavior trees and we're seeing larger trees and much richer behaviors. How does GameBrains help scalability?
DP: The best way to address scalability is with reusability. This can be provided in behavior trees by look-up table entries. With this functionality the designer can reuse small or large subtrees by making multiple references to them in several parts of the tree, without the need of duplicating code.
If you think about it, this is the ideal situation. When you learn how to program, you learn that there are some pieces of code that you are going to use very often. Then, the programmer encapsulates those into functions and makes calls to them. If something goes wrong, or the functionality has to change, you just need to go to that function and not to navigate over all the code. With behavior trees you can do the same thing, but by using subtrees via lookup tables, where in traditional programming you would use functions. You just need to reference the same subtree everywhere it is needed in the tree.
In the graphical view, our look up table entries will be referenced as a single node, so even when the behavior tree becomes huge, it will be easy to understand by just looking at its graphical representation. And if the designer needs to make modifications, he just needs to go and open that subtree without the need of changing the whole tree.
AC: As the low-level engine technology matures, teams are now more willing to invest some time in debuggers. What are the advantages of GameBrains' debugger compared to a home-grown one?
DP: When we first started talking to developers the main problem they were crying out for a solution was debugging, so we’ve made that a focus with our technology. GameBrains functionality can be separated into two main branches. The first one is the creation and editing of new behavior trees. This is the easy step; the interface is so simple that the design process can be fast and reliable. The second (and harder) thing is the one that we are putting our main efforts: the debugging capabilities.
These capabilities include extensive logging information returned from the runtime about the BTs execution, the ability to set breakpoints going into and out of tree nodes, and the ability to review execution logs step-by-step or millisecond-by-millisecond in an intuitive graphical interface. We have even more features in the works, like exposing behavior tree runtime information to the game engine so it can be displayed in the game (for instance above an NPC) and capturing video from the game and synching it with the execution log. We are also planning a huge effort in enhancing the log view, so the users can easily identify which part of the behavior trees is being executed.
An important advantage of using Gamebrains is that we work very closely with developers. We are a young new company and we are very open to new ideas coming from developers. We’re willing to provide whatever the functionality that the developers might need, and we can do this relatively fast: we know our system very well, and our team can easily extend its functionality.
AC: There are now increasingly many lectures and tutorials on BTs, as well as a few open source examples. If writing a good BT from scratch can take a few weeks, what's the advantage of middleware?
DP: The primary benefits of middleware are cost, support and time savings. Our software is great but a good team of programmers could build the tech in house… but it would cost more than it would cost to license it from us. This is because the cost of middleware is amortized over many games. When you license it you are only actually paying a fraction of what it actually cost to develop in the first place.
So, why not go open source? I am a huge fan of open source. But the licenses can be restrictive. Many time you can’t use open source software unless you want to make the source code to your hit game available to the public. Plus there is no one to support it. No one you can phone in the middle of the night. In a tight deadline oriented businesses like game development you need someone who understands the code base and who can stand behind it and fix problems when they arise. If a bug is stopping 50 other programmers from proceeding with their work, posting to a discussion forum and waiting a week for a reply is not an option. With our product you get access to the source code and you get support. In other words you have someone to yell at and hold your hand.
We give the advantages of open source, by providing full access to the runtime code base and we also give the advantages of a professional product. We provide documentation, support and quick identification and solution to problems the developer might have.
Finally there are the advantages of using our software for quick prototyping. You can download our software and start using it to prototype AI in a matter of hours instead of weeks. Our software deals with the boring stuff and allows developers to focus instead on the more creative aspects of game development.
AC: Thanks for taking the time to answer these questions!
DP: Thanks Alex! To everyone out there please contact us for all your behavior tree needs. We can provide our pre-made solutions or customize it to any needs you may have. We also offer great support for all our products.
Technology and Debugging Capabilities
The first thing GameBrains did before beginning development of its tools was to interview several AAA developers within the industry. It will come as no surprise that the number one problem developers mentioned is debugging. So GameBrains has concentrated on making easy debugging a priority.
The GameBrains GUI connects via TCP to a streamlined C++ runtime that can run on any C++ based platform including consoles. While running behavior trees the runtime sends back state information to the GUI via UDP. This setup allows the GUI to send TCP commands to the runtime to start and stop multiple behavior trees and allows to the GUI to receive extensive UDP runtime information to aid in debugging. Breakpoints can be set when entering or exiting nodes. This allows developers to trace when individual branches are executed or when a problem leaf node finally finishes executing.
The GUI has the ability to record and display a graphical view of the BT executing. The developer starts executing the BT and can then review a graphical session of the BT executing. The developer can watch the BT as it transitions from state-to-state or in a time based view. This gives the developer an easy to use graphical view of what the BT did to help them track down unexpected behaviors.
The GameBrains SDK allows for rapid integration into an existing library of code. The SDK comes in two integral parts. The first is a C++ runtime library (ActionScript 3 and Java coming soon) that can be integrated with any existing C++ game. This part runs behavior trees in the game engine. The second is a graphical editor that allows for creation and visual debugging of behavior trees.
Features and benefits of the runtime include:
Full c++ source code access. Customize or extend the code any way you want.
Load behavior trees from an XML file or from the Behavior Tree Editor: Run behavior trees as you edit them or from static files.
Rapid and easy custom leaf node creation of actions or conditions. Create leaf nodes containing c++ code, lua script, FSMs or any other type of code.
Blackboard manager library for creating custom blackboards in your behavior trees. This allows quick sharing of data between behavior tree nodes.
Assertion tools for a safer way of programming. Minimize the bugs in your application with minimal effort.
Two fully documented integration demos, including tutorials and code, to help you integrate the runtime into your game and get running with behavior trees in a matter of minutes.
Features and benefits of the graphical debugger and editor:
All the standard selectors, sequences, actions, conditions and seven different types of decorators. Rapidly create new behavior trees with standard behavior tree components.
Create and edit new behavior trees, using a friendly intuitive user interface. Save them for later or run them now for rapid prototyping and easier debugging.
Parameterize your nodes. Create your own node parameters to tweak behaviors while reusing node classes.
Run behavior trees dynamically from the editor and watch your changes happen live within your game. Easy and quick way to modify behavior trees without restarting the game or editor.
Set breakpoints in your running behaviors from the editor: Stop the game on entry or exit from behavior trees nodes.
Record step-by-step behavior tree runtime sessions. Run your behavior tree then replay a graphical log to see what happened. Easily navigate through the log with an easy to use timeline slider.
Play, step, pause and stop your loaded behaviors from the editor. This gives you total control over your behavior tree execution.
If you'd like to find out more about GameBrains, and inquire about the limited beta program that's just started, don't hesitate to contact the team via the official website. You can also follow them on Twitter.
If you have any questions, don't hesitate to post them below in the comments or in the corresponding forum thread.