Simple Behaviour Trees for your game in Javascript and C#

A little while ago I tried to understand what Behaviour Trees are about, as in a couple of games I’m developing I have sets of NPCs that I have to manage and I would like to somehow decouple their behaviour from the main game flow. Here you can find a good explanation of behaviour trees.

Sample behaviour tree

Sample behaviour tree

Got this, I searched for implementations (I wanted both Javascript and C# implementations) and I didn’t like them because of the amount of code and classes required. Then on StackOverflow I found this very simple example:

Stack Overflow simple behaviour trees

Encouraged by this,  with Matteo Bicocchi we started writing our own implementations, as I simply could not believe that the code needed to be so complex 😉 . We first wrote the Javascript implementation, and the two main points we had to deal with have been:

1. Distinguish between the tree description and the instance tree being run: you need a concrete instance as you need to be independent of “tick” speed and need to be able for each instance to find what is the current node.

2. You need to handle single node completion asynchronously e.g. if you have a “chase” node, this may take a long time to resolve.

Now we have our implementation, its very simple code and can be useful in a wide variety of game development situations – surely its not a complete solution but it works fine.

Here is a simple Js Fiddle example you can play with directly in the browser.

Fiddle with behaviour trees

and here are full sources in both Javascript and C# on GitHub. The C# code is a simple port from Javascript, surely it could be refined (branch it!). It also contains two classes making the C# example run, its made with a for Unity (extends MonoBehaviour) but the code can be used anywhere.

The code is mostly commented in the Javascript version.

Follow me on Twitter where I post about game design, game development, Unity3d 2D, HTML5, applied games.

Social Share Toolbar

Game Development with Unity 2D – part 3: GUI, or No Text is an Island

This is the third part of a voyage in Unity 2D development, where we document in video the design and development of a simple strategic game reproducing the Battle of the Teutoburg Forest. Here are Part 1, Part 2, Part 4.

Video

In this part three we are going to have health bars, labels and winning conditions; here is the video (also directly on YouTube watch it in HD for a better experience): [Read more…]

Social Share Toolbar

Game Development with Unity 2D – part 2: Javelins & Battle Cries

This is the second part of a voyage in Unity 2D development, where we document in video the design and development of a simple strategic game reproducing the Battle of the Teutoburg Forest. Here are Part 0, Part 1, Part 3, Part 4, Part 5. [Read more…]

Social Share Toolbar

Game Development with Unity 2D – part 1: The Battle of the Teutoburg Forest

In this episode of our voyage in Unity 2D development, we create the first version of our Battle of the Teutoburg Forest.

Here are Part 0, Part 2, Part 3, Part 4, Part 5.

Teutoburg Battle

In this first video we see the basics of Unity 2D sprites and animations (as provided in Unity 4.3 and following), and a base class structure for a strategic game.  [Read more…]

Social Share Toolbar

A short note on using Object Oriented models in Unity

In the last weeks as a part of my learning Unity development I have been exploring how to integrate object oriented programming (OOP) modeling concepts in Unity, as done in projects such as in those by Brett Hewitt, Unity 4.x Game AI Programming,  in the Unity examples and in others created by friends. Given what a nice and evolved language is C#, the temptation of projecting the OOP techniques I’m used to in Java is irresistible.

One useful answer to a “root” doubt I got it here:

OOP for Unity

But my impression was more and more that I simply had to drop my “start modeling from the root” approach (coming from server side web development) as wrong, and now the point has become clear: in Unity you simply don’t begin at the top of the object hierarchy, not even closer: you begin at the bottom! MonoBehaviour is neither an interface nor an abstract class, but as concrete as it can be, handling e.g two timelines and a series of extension by components. The correct way is to use a component based approach, just like MonoBehaviour does, where your MonoBehaviour (flat, direct, and final) extensions instances can carry modeling properties which can use inheritance modeling.

Happier now Sorriso

Social Share Toolbar