a technical blog

HTML5 Game Development

with one comment

20130226_233917After 2012 being “the year of the cloud”, HTML5 is currently catching up to be the new buzzword of what “we need to have in our application”. So, at work I have been doing a lot of research on technologies revolving around HTML5 and JavaScript. In my industry sector most HTML/JavaScript developers still code in a procedural fashion, produce interwoven JavaScript and HTML-code and use alert for debugging. I am finger pointing at myself here too. While doing research though, I have become a big fan of JavaScript for it’s good parts. Functions as first-class objects and closures to only name two. Also, frameworks like angular.js teach you to code in a very structure fashion that has been common at the server-side for years, but now is also finding it’s way into the browser (the buzzword is dependency-injection).

For my game development hobby projects I have been using Java for most things (libGdx is great for android). It is a great language with amazing tooling/IDEs (eclipse, IntelliJ). I espacially like hot code-replacement. Espacially in a run-loop of a game this can be very handy to do rapid development and immeditely see your changes take effect. It might not be on the level of what Bret Victor envisions, but it is a first step.

Anyway, I have been wanting to try out WebGL for a long time now; last time, after finding this WebGL port of one my favorite rendering engines. The context at work now gave me enough of an understanding for the surrounding technologies to actually try it for one of my game projects. I was hoping to directly jump into the actual game content and not have to learn a new language and environment from the ground up. And it actually worked out quiet fine.

Also, I wanted to go in the direction of using the web for future games anyway; the burden to start a browser game is much lower then to either download and start a game or even run a Java-applet based game in the browser. This can be crucial for a high exposure rate of your game during a game competition like the Ludum Dare.

I decided to join the “One game a month” initiative (#1GAM) and make a February game based on HTML5 technologies. The result is a simple retro-style jump-and-run ala Commander Keen and named “Agent 386”. You can find it here.

What technologies have I been using and what are some of the take-aways?


  • On the one hand JavaScript is missing the classical inheritance model in an easily useable fashion and instead exposes a prototypical inheritance model, it is so powerful, that you can define the classical model yourself. I picked up the proposal by John Resig and basically copied the code over in my project. Voila: Classical Inheritance with “extends” and super-calls. This somehow reminds me of the amazing strength of Lisp; …just that it is actually widely used outside of academia.
  • I have become to learn that for me the function-scope of local variables (instead of proper block-scope) paired with closures is a really huge stepping stone and one of the baddest parts of Javascript. I have been making this mistake over and over again and really dislike the omnipresent “var self = this” solution.
  • WebGL is just great! Instead of having to write a lot of boilerplate code just to get one triangle on the screen, in WebGL it is just so easy: Create a canvas, get it’s 3D-content and you are ready. Also the code to load a shader is quiet straight-forward if you include the shader-code in a script-block in the HTML page. As WebGL, just like OpenGL ES 2.0, does not come with a matrix stack, the glMatrix library is indispensable.
  • WebAudio I only got working in Chrome as it seems Firefox does not support it yet; nevertheless, in Chrome it is working great (I first had some issues with the sound beeing distored but it went away and never came back) and you can easily load and play an Ogg-Vorbis encoded audio-file in a few lines of code. Wait until Firefox fully supports it and over are the days of flash. Well, the days of flash are already counted but a flash-based sound plugin was one of the last useful applications I could think of.
  • The LocalStorage API is great for storing save-games and high scores.
  • Now comes the greatest part: Gamepad API! I bought an XBox 360 game controller (the “for Windows”-version) and hocked it up to my macmini (see this controller driver to get it running). I have the mac connected to my TV running mainly XBMC as an entertainment system. But, it also has chrome on it. Perfect place to try out my jump-and-run and actual enjoy a few entertaining minutes in front of the TV (german TV is crap; I usually try not to turn on the TV; except for listening to some music television). It worked like a charm; and I imagine there is a huge potential and market for casual browser-based games in the living room. Playstation 4 has already blown it (what indie game developer can afford to publish a game on that platform?) and Microsoft might do as well with the XBox, but there still could be a new gold-rush for indies and gaming in the living room. Apple TV might be the winner here just as on the mobile market (100$ annual developer subscription and  a 70/30 revenue share; that was needed to start the gold rush and is all that’s needed now). But I digress…
  • Require.js: I have started to do some experimenting with it at work and liked to not have all my scripts/classes in the global scope and be a little more structured. No long lists of script-tags in your HTML-file. Instead, state the dependencies of each JavaScript file locally and let require.js take care of resolving the dependencies. Kind of like imports in Java and includes in C; even more. I was hoping that the require-calls will also function as an easy visual clue for the dependencies each of my JavaScript classes has. But, due to the dynamic typing it happens to be that a lot of classes might not be listed as a “require”. I.e. types of function parameters that flow into my methods don’t need to be listed; only if I instantiate a type or reference static attributes, I have to include a require-call. Actually the problem is no real problem as it is part of the nature of JavaScript; but I took it as a point anyway because by this require.js basically fails to be useful in a game project of the scale I am using. Async script loading is nice but rarely needed. Just list all your scripts and let them get loaded in the beginning and you don’t have to care about script loading anymore. And managing the dependency-graph manually is also doable if you have a good architecture. It works for Quake as well…
  • Zepto.js: JQuery is a quiet heavy and big framework but without discussion it is indispensable in almost any web application. Just for the simple DOM-manipulates of a WebGL game, this might be overkill. Creating or querying a canvas (and loading the shaders from script tags) is no reason to include JQuery. Zepto.js is an implementation of the JQuery API without all the legacy browser support et al. Making it lightweight and a reasonable include.
  • Duck-typing: This is one thing of Javascript I really started to appreciate. I have never been doing a one-man game-project in a scripting language before so this might be obvious to scripting language users in general, but duck-typing is just great. I can define a function “distance(a,b)” do calculate the distance of two points and all “a” and “b” need to define is parameters “x,y,z”. The type is irrelevant. I can calculate the distance between the player and some other game object with having an explicit Vec3 type or similar; which I find overkill in smaller projects. Especially in a game jam.

IDE, Browser, Runtime, etc..

  • I have a license for the Webstorm IDE at work. So, I naturally chose to use it for my game as well. It has a great debugger integration. And setting breakpoints in your code is a big plus. I don’t want to do this in the debugging panel of Chrome. But the missing hot code replacement is really a disadvantage. For developing with angular.js et al WebStorm comes with a great Chrome plugin to do immediately swap in  code changes in the browser. I think it is similar to a page refresh with a little bit of additional stardust; because of that is is useless for me in a WebGL context. Make a code-change and basically the game is reloaded. Maybe I am also missing something; because I have been reading that you CAN do hot code-replacement in Chrome if you change your files directly in the Chrome Developer panel (“does the WebStorm plugin maybe work in a similar fashion?”, I am just now thinking…) but it did not work for me. I think I will be trying Sublime text 2 for my next project as the lightweight feeling and responsiveness might make up for the non-present debugger integration.
  • I have used Chrome for the most part of development. And I only started to test in Firefox and Safari when I was already well into the development and almost 50% finished. I was surprised that the game immediately ran in both browsers without needing to do any modifications. Firefox without sound (I coded the access to WebAudio defensively as it is the one HTML5 API that the game does not have to rely on to function) but still impressive. I tested it quickly in Chrome on my android phone and it did not work out of the box. But I also did not really care as i don’t like the feel of Jump-and-Run games on a touch-screen. The game controller with haptic feedback is the homezone of these kind of games. Disabling cross-site scripting checks in the browser (–disable-web-security for Chrome) was also a big plus for loading config files and resources via Ajax and not needing a webserver for the development.

My takeaway from this journey is that I will stick with HTML5 for future projects. It has all that’s needed in a nice sandbox and the runtime environment  is omnipresent environment (the browser). Everybody has a browser everywhere and can enjoy a casual game. Let’s wait for Apple-TV and Steam Box and we will have the living room gold rush; and HTML5 taking a front seat!

I also have my asset-creation and development toolchain set up and ready for bigger projects now. As I wanted to learn, I did not go for Impact.js as the game library but created the framework from scratch and myself. Sprite-creation, spritesheet conversion, audio-file conversion to ogg, etc are set up in a make-based automated process. So, compilation of all the assets, obfuscation/minification of the code and deployment to the web-server is only one “make deploy” command. For the first time I have been trying to rely on a lot of good tools that already exist instead of doing everying myself. The tools I used for Agent 386 are:

  • Tiled for creating the tile-based levels (before, it was usually Paint.NET; just “draw” a map into a PNG)
  • TexturePacker for creating spritesheets (commandline interface included!)
  • ASEprite aside of Paint.NET for the actual creation of animated sprites (it helps to see the animation immediately instead of starting up the game and checking there)
  • oggenc for converting WAV files to Ogg Vorbis
  • Bfxr for sounds

The only thing left for me to say: Try out WebGL for game development and if you are in the mood, check out Agent 386 on your big-screen TV with gamepad and enjoy. For me it was certainly an interesting journey and with only 3 weekends of almost full-nighters, I am proud to have been able to get something finished.

Written by 38leinad

February 28, 2013 at 11:42 pm

Posted in Uncategorized

One Response

Subscribe to comments with RSS.

  1. Inspiring story there. Whatt happened after? Good luck!

    addicting app

    October 17, 2014 at 2:32 pm

Any thoughts?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: