Javascript Game Foundations - A Web Server

Mon, Dec 2, 2013

Ten Essential Foundations of Javascript Game Development

  1. A Web Server and a Module Strategy
  2. Loading Assets
  3. The Game Loop
  4. Player Input
  5. Math
  6. DOM
  7. Rendering
  8. Sound
  9. State Management
  10. Juiciness

Web Server

You might imagine that a pure client-side HTML5 game can be developed and tested by simply opening your HTML pages directly from local disk in an appropriate browser, but due to various security restrictions, that approach generally doesn’t work (e.g. you can’t make an AJAX call to load assets from local disk)

Therefore you will need to run a rudimentary web server on your local development machine in order to see the fruits of your labor while you are busily creating your next gaming masterpiece.

There are many, many ways to get a local webserver, depending on your technology of choice:

Phaser recommends:

Those are also some more lightweight options for Linux and OS X users:

Personally, since I do a lot of ruby development, I am comfortable with the simple adsf local web server:

> sudo gem install adsf

> cd my/game/directory
> adsf -H thin -p 3000

Module Structure

In addition to serving up your game during development you will also need to decide on the structure of your code.

  • is the game small enough to live inside a single module?
  • do you want to break it up into a separate module per-class?
  • will you need a build tool to unify and minify your javascript?

Javascript is a very flexible language, but with that flexibility comes a multitude of choices on how you want to pattern your application.

If your game is small and simple, it might be easiest to have a single file and use the module pattern to keep the implementation private. I use this approach for many smaller games such as my rotating tower game, for example:

(function() { // private module pattern

  'use strict'

  //===================================
  // CONSTANTS
  //===================================

  var FPS    = 60,
      WIDTH  = 720,
      HEIGHT = 540,
      ...

  //===================================
  // VARIABLES
  //===================================

  var tower,
      monsters,
      camera,
      player,
      renderer;

  //===================================
  // GAME - SETUP/UPDATE/RENDER
  //===================================

  function setup(images, level) {
    ...
  }

  function update(dt) {
    ...
  }

  function render(dt) {
    ...
  }

  //===================================
  // GAME CLASSES
  //===================================

  var Tower = Class.create({
    ...
  });

  var Player = Class.create({
    ...
  });

  var Monsters = Class.create({
    ...
  });

  var Monster = Class.create({
    ...
  });

  var Camera = Class.create({
    ...
  });

  var Renderer = Class.create({
    ...
  });

  //===================================
  // LET'S GO!
  //===================================

  run();    // see "the game loop" in the next article


})();

Once the size of your codebase gets larger you will want to break it up. Best practice is to maintain individual source files for development and then unify (and minify) them for performance reasons, to serve up a single javascript and a single css file at run time.

There are a number of open-source solutions to this problem:

  • sprockets - if you have a ruby/rails back end
  • gears - if you have a python back end
  • mincer - if you have a node back end
  • requirejs - if you want to do it the AMD way

However, it’s not that hard to roll-your-own. Using Ruby and Rake, I created a simple UnifiedAssets library that will take my individual .js and .css files and combine them into a single unified run-time file.

I can then declare a simple Rake file in my game directory that uses the UnifiedAssets library to provide some simple rake tasks:

rake assets:clear     # clear unified asset files
rake assets:create    # create unified asset files
rake assets:server    # simple webserver that auto-regenerates assets if they are out of date

For example, in my earlier snakes game, the Rakefile declared the following list of javascript and css assets:

UnifiedAssets::Task.new do |t|
  t.minify = true
  t.assets = {
    "snakes.js"  => [
      'js/game/vendor/stats.js',
      'js/game/vendor/sizzle.js',
      'js/game/vendor/animator.js',
      'js/game/vendor/audio-fx.js',
      'js/game/vendor/state-machine.js',
      'js/game/base.js',
      'js/game/game.js',
      'js/game/dom.js',
      'js/game/menu.js',
      'js/game/key.js',
      'js/game/math.js',
      'js/game/vector.js',
      'js/snakes.js'
    ],
    "snakes.css" => [
      'css/vendor/normalize.css',
      'css/snakes.css'
    ]
  }
end

The rake assets:server task provided by the UnifiedAssets gem can now be used as a replacement for the simple local web server described in the previous section, and provides the additional benefit of automatically unifying all of my assets whenever they change:

$ rake assets:server
(in /home/jake/github/javascript-snakes)                           
>> Thin web server (v1.2.11 codename Bat-Shit Crazy)               
>> Maximum connections set to 1024                                 
>> Listening on 0.0.0.0:3000, CTRL+C to stop
...

So now I can point my browser at localhost:3000, edit the source files in my favorite editor, and hit refresh in my browser to see the changes immediately.