For those of you who don’t know it, LAZEROIDS!!! is a networked, multiplayer, asteroids game written in JavaScript with a Ruby on Rails back-end. We built Lazeroids last weekend for the Rails Rumble, a 48 hour programming contest.

Since then, we’ve gotten a ton of questions about how we did it. Because we don’t see too many people writing massively multiplayer games in HTML and JavaScript (much less in under 48 hours), we thought some of our tricks might be useful to the rest of you.

As a caveat, the title of this post is actually fairly meaningful. LAZEROIDS!!! was a bit of a “Hello, World” program for us. None of us had ever worked extensively with comet, canvas or web sounds before this weekend (we’d dabbled, but nothing serious). Furthermore, we’re web programmers, not video game guys, so we made up a lot of the video game stuff as we went along. So take anything we write here with a grain of salt. We may not know what we’re talking about.:-)

Now, on to the good stuff.

Architecture

We used a pretty standard JavaScript MVC pattern for the application. There are some frameworks out there that look pretty good, but we’d never used any of them, and a 48 hour programming contest is not time to learn a new framework. We’ve built a substantial amount of JavaScript MVC coding for Swivel, so we were pretty comfortable with rolling our own. However, we did use prototype.js to give us all the niceties that make working with JavaScript pleasant.

The controller took care of initializing the view and model and dealing with user input like keyboard commands. The view was a canvas. We had a model class for the Universe that held masses and dealt with time. We also had various Mass classes (Spaceships, Asteroids, Bullets, etc), that all had their own movement explosion and display code. We broke down from traditional MVC in that the masses knew how to draw themselves, and the Universe model also took care of the networking.

Networking

No matter what advances the Web has made in recent years, we knew that we couldn’t rely on robust, instantaneous networking. To keep things snappy, most of the game was built to work without networking, and the parts of the game that were built with networking were built to deal with a lossy network. The game actually degrades to single player mode if the network goes down.

A network message is sent when: the ship changes direction or acceleration, any object is added to the universe (this includes bullets, asteroids, or fragments of asteroids after it blows up), or any object is removed from the universe. We additionally send b-frames with the current information for all the objects around a ship every few seconds, to make sure that asteroid positions are synced across clients.

Peer-to-Peer

We knew performance would be an issue, so we tried to leverage the power of the other players as much as possible. Also, we wanted to make the application feel seamless as possible from each client’s perspective.

Rather than have every client check for every possible collision in the game world, we made each client responsible for its own collisions. Your ship’s bullets check whether they hit an Asteroid (but don’t check whether they hit another ship). You ship checks whether it hit anything (including whether somebody else’s bullet hit you). The nice thing about this is that actions are almost always consistent from your perspective, no matter what’s happening on other clients. If you hit something or you see a bullet hit you, you blow up. If your bullet hits something, it blows up.

The one thing that can be frustrating is that other clients might see a bullet hit you, but you don’t blow up (because it misses you from your perspective). As we do a better job of syncing clients with multiple frame rates, this sort of discrepancy should happen less often.

This also opens the door for people hacking their own JavaScript code and cheating, patching it to ignore any collisions with their own spaceship, basically hacking in a god mode cheat. There are numerous other ways that they could cheat the open network protocol. We actually thought being able to do this was cool rather than a flaw. It spoke to the flexibility and generality of the system rather than as a detraction. If you wanted to add a shield, you could hack it in with just JavaScript. If you wanted a radioactive aura that melted your enemies if they came too close, you could do that too.

Connections

We used AJAX/HTTP to send data, and Comet/STOMP to receive it. We let Orbited.js deal with cross-domain comet queries (assumably by abusing iframes). For the most part, the networking “just worked.” But we wrapped everything in a simple connection object to make the implementation a bit friendlier.

Lz.Connection = Class.create({

  initialize: function(host, port, user, password) {
    this._observers = { message: [], connect: [] };
    this._stomp = this._initializeStomp(host, port, user, password);
  },

  observe: function(type, callback) { this._observers[type].push({callback: callback}); },
  fire: function(type, frame) { this._observers[type].invoke('callback', frame); },

  send: function(data) {
    new Ajax.Request('/update', {
      method: 'put',
      parameters: { data: Object.toJSON(data) }
    });
  },

  _initializeStomp: function(host, port, user, password) {
    var stomp = new STOMPClient();
    stomp.connect(host, port, user, password);

    stomp.onconnectedframe = function(frame) {
      stomp.subscribe('/topic/lazeroids');
      this.fire('connect', frame);
    }.bind(this);

    stomp.onmessageframe = function(frame) {
      this.fire('message', frame);
    }.bind(this);

    return stomp;
  }
});

It does take a bit of time to establish the connection, so make sure you wait for the connect frame before sending out any messages you want to hear a response to.

Domain = Domain

We found out the hard way that when you are requiring your browser to make cross-domain queries, you need to include the following seemingly innocuous line in the <head> tag of your web page.

document.domain = document.domain; // x-domain scripting!

Note that allowing cross domain queries enables security holes, but we felt it was ok to sacrifice security for development speed in the context of a 48 hour competition. It’s relatively easy to get rid of the cross domain queries if you use the right proxy set-up.

Orbited.js and JSON

For reasons unknown, Orbited.js totally munges JavaScript’s String.toJSON implementation. We tried to code around this, but it became obnoxious, so we monkey patched a fix.

String.prototype.toJSON = function() {
  return '"' + this.valueOf() + '"';
};

Out of Order Events

It’s important to keep in mind that AJAX will happily send requests out of order. What this meant for us is that you could receive old ship positions after you had received later ones.

Since our client was basically RESTful (weird to write a RESTful client, rather than a server), each time an update happened it sent a complete refresh of data. We didn’t have to depend on old packets to determine current state.

Thus, we were able to keep a cross-client synced time-tick to determine whether we had received old messages that could be thrown away. It was a simple change to ignore old messages.

Lz.Mass = Class.create({
  update: function(options) {
    if (options.tick < this._tick) return; // ignore old updates
    this._tick = options.tick;
    // other stuff here...
  }
});

Canvas

Objects were drawn using canvas. We weren’t concerned about IE support during the competition. After the competition was over, we were able to drop in ExplorerCanvas and have things mostly just work. That was a pleasant surprise.

Curiously, we have had a bit of trouble getting Chrome to work. We’re not sure if it’s our code or Google’s.

Zooming

When we started out the weekend, we wanted to have a radar in the bottom corner of the screen. As the clock ran down, it became clear that we wouldn’t have time. Instead, we were able to leverage the power of canvas to quickly implement zooming out when you press the ‘z’ key. The code below is the universe’s main render loop. The highlighted zooming code assumes only two possible values for this._zoom: 1 (no zoom) and 0.5 (2x zoom).

render: function() {

  var ctx = this._ctx;
  ctx.clearRect(0, 0, this._canvas.width, this._canvas.height);

  ctx.save();
  if (this._zoom != 1) {
    ctx.scale(this._zoom, this._zoom);
    ctx.translate(this._bounds.width*0.75, this._bounds.height*0.75);
  }
  this._bounds.translate(ctx);
  this._masses.invoke('render');
  ctx.restore();
}

Panning

When we started the app, screen coordinates were fixed. If you flew your ship off screen, you were flying blind, because the screen didn’t move with you. Unlike the traditional asteroids game, where you wrap to the other side of the screen when you go off, we wanted our game world to feel massive. However, keeping the ship in the center of the screen didn’t feel right either (especially because we had no background to give you a sense of movement). Instead we implemented panning. When you near the edge of the screen, the screen swoops ahead of you. That makes it dangerous to go over the edge of the screen, because you’re flying somewhat blind. However, we think it adds to the excitement.

Canvas again makes this relatively simple with it’s drawing state stack. All we had to do was translate to the next screen when the player hit the edge. That’s as easy as:

ctx.translate(-canvas.width, 0)

to move one screen to the left. But, we wanted flashy scrolly transitions. That’s a little harder, but we have scriptaculous and other effect js libraries to inspire us. What you want to do is know your final key frame value for the translation and get to it incrementally. It l

check: function(ship) {
  var p = ship._position;

  if (p.x < this.l) {
    this.dx = -this.width * 0.75;
  } else if (p.x > this.r) {
    this.dx = +this.width * 0.75;
  }

  if (p.y < this.tR) {
    this.dy = -this.height * 0.75;
  } else if (p.y > this.b) {
    this.dy = +this.height * 0.75;
  }

  if (this.dx != 0) {
    var dx = parseInt(this.dx / 8);
    this.l += dx; this.r += dx;
    this.dx -= dx;
    if (Math.abs(this.dx) < 3) this.dx = 0;
  }

  if (this.dy != 0) {
    var dy = parseInt(this.dy / 8);
    this.t += dy; this.b += dy;
    this.dy -= dy;
    if (Math.abs(this.dy) < 3) this.dy = 0;
  }
},

translate: function(ctx) {
  ctx.translate(-this.l, -this.t);
}

Sounds

We implemented sounds early on. They gave the game a sense of concreteness. Sounds are the one place we broke with an all HTML / JavaScript solution. We used the open source SoundManager JavaScript to SWF bridge to play sounds. It was amazingly easy to drop in and just start using.

This is what the code looked like:

Lz.play = function() { };  // no-op stub for before soundmanager finishes loading

soundManager.debugMode = false;
soundManager.url = '/swf/';
soundManager.onload = function() {
  soundManager.createSound('ambient', '/sounds/ambient.mp3');
  soundManager.createSound('shoot','/sounds/shoot.mp3');

  var playLoop = function(id) {
    setTimeout(function() {
      soundManager.play(id, {
        onfinish: function() { playLoop(id) }
      });
    }, 1);
  }

  playLoop('ambient');

  Lz.play = soundManager.play;
};

In the near future, we want to look into the HTML5 audio element, but sound file format agreement among browser makers might keep us on soundmanager for a while.

That’s about it! We hope this helps any aspiring JavaScript MMO game developers.

If you have any questions, you can reach us on Twitter at @lazeroids.