Working Behaviour Tree From Editor

A lot has happened to Banana Tree and I’m quite happy with its current state. More variable types are now supported in the node inspector. I prioritized the variables that are used in existing actions so I could test them as soon as possible.

While thinking about how action nodes should pass variable values to other nodes, I realized that it’s not effective for nodes to have references of other nodes. Playmaker has this concept of “FSM level” variables. These variables can be referenced by any states in the FSM. Though initially not planned, I think I needed this type of feature in Banana Tree as well for cross node variable communication. I need to have some kind of behaviour-level variables that can be referenced by any action nodes in the behaviour. I’m surprised that the implementation is really not that hard.

Node level and behaviour level variables
I have this action class “TestVariableAction” which is used to test all supported variables. On the right are the behaviour level variables which can be referenced by action level variables.

I use custom classes to add variables to an action node. The editor identifies these properties and renders the appropriate UI controls. Here’s the implementation of TestVariableAction:

    public class TestVariableAction : BntAction {

         * Constructor
        public TestVariableAction(string name) : base(name) {

        public BntString StringVariable {get; set;}

        public BntString StringTest2 {get; set;}

        public BntGameObject GameObjectTest2 {get; set;}

        public BntFloat FloatVar {get; set;}

        public BntFloat FloatVar2 {get; set;}

        public BntVector3 PositionVar {get; set;}

        public BntVector3 PositionVar2 {get; set;}

        public BntTransform TargetVar {get; set;}

        public BntTransform TargetVar2 {get; set;}

        public BntBool BoolVar {get; set;}

        public BntBool BoolVar2 {get; set;}

        #region implemented abstract members of BntNodeAdapter
        public override BntResult Start() {
            return BntResult.SUCCESS;

        public override BntResult Update() {
            return BntResult.SUCCESS;

        public override BntResult FixedUpdate() {
            return BntResult.SUCCESS;


If you want to do something like this, I suggest you use custom classes instead of directly using string, float, bool, GameObject, etc. Custom class variables adds indirection so you can add some intermediary features to your variables like referencing another variable when its value is requested or add some more information to the variable. It’s also much easier to assign values to it on game runtime since the class variables can be implemented as serialized and you’ll just have to assign it directly to the action node instance properties through reflection.

With this in place, I was able to instantiate a minimal behaviour tree at runtime from serialized data. What it does is it moves an actor back and forth in two positions, Home and Destination.

Minimal working behaviour... Yey!
Minimal working behaviour… Yey!

The editor is almost complete. When I say complete, it means it must be verified which further means that it should be used in a working game. Tomorrow, I’ll replicate the existing enemy behaviour in Warrior Defense using this editor. It’s not that easy because I’ll have to implement lots of action classes. I’m sure there will be some hiccups but I’ll find a way.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s