Today, I am releasing Andro.js, a new JavaScript library that helps you compose objects from fragments of behaviour.

The problem

Over the last few months, I have been writing a new JavaScript game. It is a 2D platformer that involves leaping about, stabbing, shooting and blowing stuff up – that much is certain. But it also has a puzzle element that is almost totally undefined.

When I began working on this puzzle element, I experimented with objects with different capabilities: objects that would light up, or play a sound, or leap into the air. Soon, it became clear that I needed a way to give a single object multiple capabilities. Then, I needed a way for these capabilities to interact, like: make this cube light up and leap into the air when it is touched by the player.

A common approach to defining the behaviour of game objects is to use components. These are chunks of code that are installed in the object, each to handle a separate task: artificial intelligence, collision detection and so forth. When the game loop ticks, each game object gets an update call and, in turn, calls an update function on each of its components, so that they can do their work. This is nice because you separate concerns, which means your code is easier to read, easier to reuse, and easier to reason about. Further, the components have total control over their game objects, so you can still do powerful stuff.

I thought about using a component-based approach, but it seemed like it didn’t really fit the way the game objects actually worked. If I were to program a leap into the air capability, what type of component would it be? Logic? And if I wanted my object to only leap when it was touched by the player, how would I organise the code then? Could I shove the leaping and touch detection into some sort of vague Collision Detection component? Or would components somehow talk to one another? I wanted to organise the code by its function, rather than its approach.

A solution

I needed to be able to write very malleable, tightly focused fragments of code that could be reused and recombined as I changed my mind, and I was willing to sacrifice some code clarity to get this.

It seemed that mixins were a promising approach. A mixin is a bundle of attributes and functions that are written onto an object, thus conferring a set of capabilities. A traditional mixin puts these attributes and functions into the namespace of the object. Any clashes: boom. That seemed too dangerous to me. I decided to put each mixin in its own namespace.

Another potential danger was how these mixins would interact. Their reusability would be limited if they had to call each other’s functions by name. Further, direct interaction would make things into a wild free-for-all that was impossible to reason about, with behaviours walking into rooms and issuing orders and walking out to cause chaos elsewhere. I quelled the potential chaos (somewhat) by deciding that the behaviours should only interact via events.

Finally, I had a plan: mixins in their own namespaces communicating via an event emitter. I wrote Andro.js to enact this plan.

An example of Andro.js in use

I require the andro.js file. I instantiate Andro. I define the game object as a constructor called Cube. It has a touch function that, when called, emits a touch event to all behaviours (mixins) attached to the cube.

  var Andro = require('andro').Andro;
  var andro = new Andro();

  function Cube {
    this.touch = function(contact) {
      andro.eventer(this).emit("touch", contact);
    };
  };

I define the firstTouchBehaviour mixin. This binds to the touch events emitted by its owner and keeps track of the number of things currently in contact. When the owner goes from being untouched to being touched, firstTouchBehaviour emits a FirstTouch:newlyBeingTouched event.

  var firstTouchBehaviour = {
    touchCount: 0,

    setup: function(owner) {
      andro.eventer(owner).bind(this, "touch", function(contact) {
        if(contact === "added") {
          if(this.touchCount === 0) {
            andro.eventer(owner).emit("FirstTouch:newlyBeingTouched");
          }
          this.touchCount++;
        } else if(contact === "removed") {
          this.touchCount--;
        }
      });
    }
  };

I define soundBehaviour. This binds to the FirstTouch:newlyBeingTouched event. Each time this event occurs, soundBehaviour makes a noise: “Rarrrrrwwwwwwwwwwwwwwww”.

  var soundBehaviour = {
    setup: function(owner) {
      andro.eventer(owner).bind(this, "FirstTouch:newlyBeingTouched", function() {
        console.log("Rarrrrrwwwwwwwwwwwwwwww");
      });
    }
  };

I now put everything together. I instantiate cube, set it up for use with Andro.js and augment it with firstTouchBehaviour and soundBehaviour. Finally, I simulate two touches upon the cube. On the first, it roars. On the second, it does not.

  var cube = new Cube();
  andro.setup(cube);
  andro.augment(cube, firstTouchBehaviour);
  andro.augment(cube, soundBehaviour);

  cube.touch("added"); // rarrrww
  cube.touch("added"); // silence

Limiting mentalness

The approach Andro.js takes exchanges a measure of one’s ability to reason about the code for a measure of malleability. Though the modes of expression are constrained to events and mixins, you can still express yourself into one hell of a mess.

As I’ve worked on my new game, I’ve discovered some guidelines that avoid most of the mess. First, all my behaviours have only one responsibility. Second, most either emit information about state, or act upon information received. Third, behaviours do not meddle with the state of their owner objects.

Was this all a mistake, my beloved?

It’s hard to express something at the same time as you’re figuring out what you’re trying to say. Andro.js has enabled me to design some complex game objects. For example, one type of object can simultaneously flash, be a note in a step sequencer, and play a sound when struck that is conferred to it by a nearby object. The code for the behaviours is clean and readable. But, I have rewritten it four times. So, I wonder if there are superior approaches.

I keep on thinking about Arc. Paul Graham has said it is a language designed for exploratory programming. And I keep on thinking about GOOL, the dialect of LISP that Andy Gavin invented to script the game objects in Crash Bandicoot.

These are both languages designed to solve the problem I have been grappling with. Is the logic of game objects in fact a microcosm of all of programming, as complex a problem as any that might be solved by a programming language? Or is it usually a limited problem that is easier to solve when you limit the tools at your disposal? And if that is so, is mixins+events a good approach, or is there a better one?

1. Players stand in a circle, each an arm’s length apart from their neighbours.

2. Someone shouts, “One! Two! Three! Ninja!”

3. On, “Ninja!”, the players adopt a ninja-like pose and remain still.

4. The person who counted everyone in now makes their first move. Their aim is to use their hand to touch the hand of another player, thus killing them. The player’s move must be made in one smooth motion. They may only take one a maximum of one step. The player being attacked may move their upper body in defence.

5. The next player then makes their move, and so on around the circle.

A video of one of the games we played at the Bocoup offices:

About a week ago, Kanen Flowers interviewed me on his show, Scruffy Thinking. I am very honoured. We talked about my latest record, using emacs, Pistol Slut, Kanen’s alien snuff movie, BBEdit, dressing like a teenaged boy and landing in Bangkok for a two day layover and only finally leaving a year and a half later. To listen, go to the Scruffy Thinking podcast on iTunes. Here is a post about the show on the Scruffy Thinking site.

I got interviewed on The Setup and, in doing so, wrote a love letter to emacs.

A few months ago, I released my new record, 10997. I put it out as a CD-R and gave copies to friends and to people who emailed me. I was reluctant to make it downloadable because the lyrics are about stuff that was current affairs. Now, however, that’s not really true, so stream and download away.

The first version of the artificial intelligence code that controlled the enemies in Pistol Slut, my 2D platform shooter, was a nightmare thicket of if statements. Fortunately, someone told me about behaviour trees, and, after reading half of an excellent article about their implementation in Halo 2, I rewrote the Pistol Slut AI code as a hierarchical state machine. To do this, I made a little JavaScript library called Machine.js that implemented a generic behaviour tree. This code is open source, like all of the code I write in my spare time, but, today, I broke it out into its own library and released it as a separate project. This should make it easier for other people to reuse.

Go to the Machine.js home page to get the code and read a tutorial.

And, in case you are interested, here is the entire behaviour tree for the enemies in Pistol Slut:

I’ll be speaking at JSConf in Portland on 2nd May. I’m very excited. I will talk about Pistol Slut. Specifically: fakery, artificial intelligence, collision detection and falling in love.