Skip to main content
fsm

Finite State Machines in Javascript

I’ve been talking a lot about Behavior Trees (BTs) lately, partially because I’m using them for my PhD. But although, BTs provide a powerful and flexible tool to model game agents, this method still have problems.

Suppose you want to model a bunch of sheeps (just like my last Ludum Dare game “Baa Ram Ewe”), these sheep have simple behaviors: “run from cursor”, “stay near to neighbor sheeps”, “don’t collide with neighbor sheeps” and “follow velocity and direction of neighbors”. A sheep can also have 4 states: “idle” when it is just eating grass, “obey” when it is being herded by the player (using the mouse), “stopping” between obey and idle, and “fear” when a predator is near. The behaviors are always executing, but they may have different weight for different states of the sheep. For example, when a sheep is “obey”-ing, it try to be near other sheeps more than when it is eating grass or running scared.

Modeling this as a Behavior Tree is hard because:

  1. BTs don’t really model states well. There is no default mechanism to define or consult which state an agent is; and
  2. All behaviors are executed each tick, thus this agent wouldn’t exploit the BT advantages of constrained executions.

Notice that, you still can model these sheeps with BTs, but the final model would be a lot more complex than it would be using other simple methods.

In previous posts, I also talked about how Behavior Trees have several advantages over Finite State Machines (FSMs). But, in cases like this a FSM is a lot useful and considerably easier to use than BTs.

Implementation

Like my Behavior Tree implementation, I want to use a single instance of a FSM to control multiple agents, so if a game has 100 of creatures using the same behaviors, only a single FSM instance is needed, saving a lot of memory. To do this, each agent must have its own memory, which is used by the FSM and the states to store and retrieve internal information. This memory is also useful to store sensorial information, such as the distance to nearest obstacles, last enemy position, etc.

First, consider that all states and machines have a different id, created using the following function:

and to simply inheritance, we will use the Class function:

We will use a Blackboard as memory for our agents. Notice that, this is the same blackboard used in my behavior trees.

We will also use a state object that implements the following methods:

  • enter“: called by the FSM when a transition occurs and this state is now the current;
  • exit“, called by the FSM when a transition occurs and this state is not the current one anymore; and
  • tick“, called by the FSM every tick in the machine. This method contains the actual behavior code for each state.

Our FSM will have the following methods:

  • add(name, state)“: adds a new state to the FSM, this state is identified by a unique name.
  • get(name)“: returns the state instance registered in the FSM, given a name.
  • list()“: returns the list of state names in the FSM.
  • name(memory)“: return the name of the current state. It can be null if there is no current state.
  • to(name, target, memory)“: perform a transition from the current state to the provided state name.
  • tick(target, memory)“: tick the FSM, which propagates to the current state.

Notice that, some methods must receive the blackboard and the target object as parameters, which can be a little annoying – this is the downside of using a single FSM to control multiple agents – but the cost is small compared to the gain in memory.

The target parameter is usually the agent being controlled, but in practice it can be any kind of object such as DOM elements, function or variables.

Example

Using a simple Boiding algorithm, we have 3 states: “idle”, “obey” and “stopping”.

Use the mouse to move the white balls:

(more…)

preview

Architectural Changes on Behavior3 Editor

So, what is happening here? Almost March and I didn’t post anything useful here, hum? Well, I’m working hard on Behavior3 and on my Ph.D project. There is a lot of interesting things happening, and I hope to share some with you in time. For now, let’s talk about some major changes on Behavior3 Editor.

First of all, Behavior3 Editor and Behavior3JS are now individual projects, each one with its own repository. Check it out:

In the first version (0.1.0), I tried to make a visual editor, a visual debugger and, common to these two, a viewer. The viewer were responsible for drawing the blocks and connections in a canvas, the editor were responsible for the edition of blocks and connections (adding, removing, selecting, changing properties, moving, etc) and the UI needed to handle that. The debugger were planned to control the execution of the tree and view the information of nodes. This architecture were suppose to be modular and easy to handle, but…

It was a complete nightmare, when you had to change something, you never knew  if you had to look to the editor or to the viewer, and when you modified something in the viewer, you had to build it (because editor were dependent on the built viewer), copy the built file to editor – then, you find a small typo, change again, repeat the process, over and over. Moreover, despite the fact that the editor worked fine, it was depending on the HTML elements, i.e., any change on the HTML stops the internal functions, any change to the internal functions stops the HTML elements.

To overcome these problems, I firstly merged the Viewer and Editor, so you don’t have to search inside two projects to find a piece of code that you want to change. The repetition of the build process was also solved, but the internal functions of the Editor were still coupled to the HTML elements.

AngularJS was the solution. A javascript MVC framework with two-way binding. Man, that’s awesome. So, I removed the dependence of jQuery and almost all other 3th party libraries, including foundation. I had to rewrite menu, scrolls and all other nice visual features, but at the end, it was worth and worked pretty well (some bugs on firefox, unfortunately). Check it out the general scheme:

b3editor - architecture
Current Behavior3 Editor Architecture – App and Editor are completely independent. App calls editor and listen to editor events.

With these architectural changes, I can add more features to b3editor. I already pushed a tree management (now you can add, edit and remove several trees) and I’m going to implement project management. To have a better follow up, check the issue list https://github.com/renatopp/behavior3editor/issues. I hope to release the next version of B3 in the next 2 months.

Thanks for @grifdail, @elmarquez and @FunkMonkey  and Daniel Balster for suggestions and patches on this version.

sheepdog_trails

Links to Understand The Boiding Algorithm

Ludum Dare 31, the last jam of the year, ended up very well for me. I created “baa ram ewe“, a game where you must herd sheeps with the mouse, moving them from a thin grass to a plentiful pasture. The game has a good – and solid, for an experimental game made in 48 hours – mechanics and a good overall aesthetics, I really liked the final result of this game. I also received a lot of positive feedbacks, mostly asking me to create a mobile version, which I decided to do.

Baa Ram Ewe uses a boiding algorithm (also known as flocking algorithm) to move the sheeps, to keep them together, and to avoid obstacles and dangerous elements. The boiding algorithm is a method to simulate collective movement of animals, such as fishes, birds, sheep, etc. For example, take a look a the following video, which shows a simulation of buffaloes running:

The algorithm is very simple. All agents in the simulation follow a set of simple rules. These rules defines how each agent will move accordingly to its neighbors flock-mates. The interaction between the agents generate an emergent behavior, as you can see in the video.

The rules used in these kind of simulation are really simple. Commonly, all boiding applications have the following ones:

  • Separation: the agent must avoid the nearest flock-mates by steering away from them;
  • Alignment: the agent try to head to the average position of the nearest flock-mates;
  • Cohesion: the agent try to move to the average position considering the nearest flock-mates;

You can see a visual example of these rules on the figure below (copied of the Craig Reynold’s site, the creator of this algorithm)

boiding_rules
(a) separation rule; (b) alignment rule; and (c) cohesion rule. From (http://www.red3d.com/cwr/boids/)

In Baa Ram Ewe, I used the algorithms presented by Conrad Parker in his site as basis. Summarizing, I have a FLOCKING function that moves the sheeps accordingly to a set of rules:

As you can see, you can define any number of rules, but be careful with that! More rules mean more complexity, you probably won’t be able to generate the behavior you want. Check it out the Conrad Parker site to a nice description of the basic rules.

See

 

 

b3editor-square

Behavior3JS, First Release!

After some weeks working on this, I finally released the first version of Behavior3JS, my javascript library for behavior trees.

http://behavior3js.guineashots.com

I wrote 2 tutorials this month about implementing a behavior tree from scratch (here and here), which content was based on this library. Together with the core classes and nodes, I also released an online and visual editor, where you can design your behavior tree with custom nodes and export it to JSON format.

b3editor

Unfortunately, I couldn’t release the visual debugger together (I will travel next week, so I preferred to release what I had right now), but for sure, this is the priority for the next versions.

Take a look in this project on Github: https://github.com/renatopp/behavior3js

I recommend you to also take a look at the user guide, so you can have an idea of how this works: https://github.com/renatopp/behavior3js/wiki

node_selector

Implementing A Behavior Tree – Part 2

Fast links for other parts and tutorials:

If you’re looking for actual code to use, check it out:


In the previous post (Part 1), I presented the base architecture for our Behavior Tree. In this one, there is not much to talk, but a lot to show. I will present some implementations of basic nodes here, and with this, you will have (hopefully) a pretty good idea of how this all works and how to continue on your own.

We will implement here:

  • Composites: Sequence, Priority, MemSequence, MemPriority;
  • Decorators: Inverter;
  • Actions: Wait, ChangeColor, ChangePosition;
  • Conditions: IsMouseOver.

By the end of this post, we will also put a simple behavior tree into action.

It is important to note that, I’m oversimplifying our implementations due to legibility and better understanding of the core features. For example, I would replace the “children” variable in decorators to a “child” variable in a real scenario, because they can only have a single child. More than that, I would create a class for each node category in order to treat the these differences between them. If you are going to implement a BT from scratch with basis in these tutorials, I trust you are going to make the necessary changes. =)

** Remember: all nodes must inherit from BaseNode.

Composites

A composite node can have one or more children. The node is responsible to propagate the tick signal to its children, respecting some order. A composite node also must decide which and when to return the state values of its children, when the value is SUCCESS or FAILURE. Notice that, when a child returns RUNNING or ERROR, the composite node must return the state immediately.

Sequence

The sequence node ticks its children sequentially until one of them returns FAILURE, RUNNING or ERROR. If all children return the success state, the sequence also returns SUCCESS.

Priority

The priority node (sometimes called selector) ticks its children sequentially until one of them returns SUCCESS, RUNNING or ERROR. If all children return the failure state, the priority also returns FAILURE.

MemSequence

MemSequence is similar to Sequence node, but when a child returns a RUNNING state, its index is recorded and in the next tick the MemPriority call the child recorded directly, without calling previous children again.

Notice that, this is the first time we use the blackboard inside a node. The MemSequence must save the index of the last running child in the blackboard in order to start from it in the tick function. Also notice that, every time the MemSequence is opened (which means that it was closed), the node resets the “runningChild” to zero.

 

MemPriority

MemPriority is similar to Priority node, but when a child returns a  RUNNING state, its index is recorded and in the next tick the, MemPriority  calls the child recorded directly, without calling previous children again.

Decorators

Decorators are special nodes that can have only a single child. The goal of the decorator is to change the behavior of the child by manipulating the returning value or changing its ticking frequency.

Inverter

Like the NOT operator, the inverter decorator negates the result of its child node, i.e., SUCCESS state becomes FAILURE, and FAILURE becomes SUCCESS. Notice that, inverter does not change RUNNING or ERROR states, as described in algorithm below.

Actions

Action nodes perform computations to change the agent state. The actions implementation depends on the agent type, e.g., the actions of a robot may involve sending motor signals, sending sounds through speakers or turning on lights, while the actions of a NPC may involve executing animations, performing spacial transformations, playing a sound, etc.

Wait

Wait a few seconds. Notice that, in this node, we need to define a parameter in the initialization!

ChangeColor

Change the color of the target object.

Note here: this is the first time we use the target object. Thus, this node, different of the previous ones, is very coupled to our application. Here, this node will be used in our example below and the target object is a shape of CreateJS.

ChangePosition

Choose a random position for our target object.

Conditions

A condition node checks whether a certain condition has been met or not. In order to accomplish this, the node must have a target variable (e.g.: a perception information such as “obstacle distance’” or “other agent visibility”; or an internal variable such as “battery level” or “hungry level”; etc.) and a criteria to base the decision (e.g.: “obstacle distance > 100m?” or “battery power < 10%?”). These nodes return SUCCESS if the condition has been met and FAILURE otherwise. Notice that, conditions do not return RUNNING nor change values of system. Graphically, condition nodes are presented by gray ellipsis, as shown in the image below.

IsMouseOver

Verifies if the mouse is over our target object.

Example: Jumping Box

So, we have all our nodes. Now put it all together in a file called behaviors.js and copy the code below into a html file:

This example presents a blue rect in the screen. When will move the mouse over this rect, it will change to red; then it will wait a half second to change its position, resetting its color to blue again. Check it out:

.

This ends the series of tutorials about Behavior Trees. I hope to hear some feedback from you guys!