tl;dr; Hacked on BrowserQuest – results available at http://208.115.237.122. For details, read on.
As you may have heard, last week Mozilla released Browser Quest, which is essentially a technical demonstration of web gaming – in this case, Browser Quest is a massively multiplayer HTML5 browser based game that uses Canvas for rendering, WebSockets for network communication, and Node.js for a back end server. If you’ve played Browser Quest, or had even a brief look at the code, you’ll already understand that Mozilla hasn’t set out to make Browser Quest as the next World of Warcraft, but rather to spark the ideas and creativity in a field that has been a little lacking up until now – the field of open technology (native to the browser) HTML5 games.
Best of all however, they open sourced all the code for the game (minus a few audio files) which means, if you’re like me, you can get a little bit of a buzz out of hacking together a little bit of a game. After all – making web apps is fun, but making web app games is much more so, so the team at Sidelab thought this was an ideal project for one of our occasional hack days.
Taking a look into the code, we found that there are some bits that are extremely well written, particularly on the client side. The Renderer class, which renders the tile based map onto the screen, does a lot of things well (I particularly liked the use of multiple canvases to provide the foreground, background and sprite layers – it makes a lot of sense!). Likewise, the WebSocket communications, despite some rigidity which is to be expected in a technical demonstration, makes a strong case for the ability of WebSockets to be realistically used in browser based gaming – something that I had before been sceptical about.
On the flip side, the code was proved to be not inherently extensible, and the use of some odd coding conventions (possibly for speed reasons) on the server side, such as not using events – something which Node.js prides itself on – seemed to be a little strange. But on the whole, it looked like an ideal platform with which to get something up and running quickly.
For my part, my desire was to provide a little more meat to the game – a bit of atmosphere, without affecting the game too much, and hopefully creating something I could later translate to a different coding project. In order to do this, I decided to implement an Orchestrator, an object that is able to observe the each of the WorldServer’s that the Node.js server creates, and apply any number of configurable Orchestrations to the world that could receive and publish events, and thereby, allow the WorldServer to be extended without requiring significant modifications to the original BrowserQuest source.
The test of this was the creation of a Day/Night cycle orchestration that causes the world of BrowserQuest to shift between a bright glorious day, and a dimly lit night filled with ravenous, aggressive bats, a change which, along with some other small client side and server side tweaks, can be seen on my own hosted instance of Browser Quest at http://208.115.237.122. (a small aside – again, massive kudos to Mozilla for releasing everything you need to deploy your own server)
Whilst this server plays very much similar to the original BrowserQuest (my attempts to build in an overarching attack by monsters didn’t realise as much gains as I’d hoped in the small amount of time I spent on it), what it has sparked in me is the realisation that finally native browser based games are possible; are a reality and now that someone else has gone to the effort of proving it for me, are something that I can see myself sinking my teeth into – and for that, you’ve got to give Mozilla (and the guys who made the game, Little Workshop) a lot of the credit.
For those who are interested in playing around with my Orchestration changes for BrowserQuest – be my guest! The source is available in my fork of the BrowserQuest source in my GitHub repository.
