Animash Development

The Refactoring

So, this week I took a step back to evaluate all of the code that has been written so far and look at how it could be improved to make the game as stable as possible, scalable and importantly - more secure against potential cheating.

The Singleton Design Pattern

At this point the code for Animash was based around singletons, a class for the interface, game, controls, networking, player, hud and more all living in the global namespace and all exposing public methods in-order to interact with each other.

Up until now this has made life easy as any class can reference another - and boy, did they! For example, the network code was hooked into the interface, game and controls. This lead to a tangle of functionality and references and all the inherent problems of cluttering up the global namespace.

Cheating

Unfortunately this approach also makes cheating a breeze; simply open your javascript console in any decent browser - watch the events going back and forth between the exposed methods and insert your own to give yourself more speed, kills or any number of other possible tweaks to ensure you win ;-). For example one of the methods you could call was as simple as:

Game.squashAllPlayers();

Handy, huh?!

The Module Pattern

The solution to all of these issues has been to implement the module design pattern, utilising requirejs to load and manage the requirements of each module. Although initial this meant a lot of going backwards to go forwards (completely breaking the game!) - this now results in no exposed methods that can be easily tampered with and a huge reduction in global variables, although there will always be some…

All Important Interface

Although animash is first and foremost browser-based we want to create an experience that feels like a real game and not the usual embedded flash surrounded by flashing adverts that has become so synonymous with casual online games.

The game adjusts to take up the entire browser window - menus and other interface elements will be navigable with both the keyboard and mouse.

As part of the interface development I have created a jQuery plugin to enable keyboard navigation on any number of dom elements, check out the documentation and sourcecode over at github. It will be improved during the course of the games development - let us know if you find it useful!

Zap! - Html5 Audio Manager

As mentioned previously one of the most interesting and frustrating parts of building a browser-based games in html5 is the audio management. Handling the different browser idiosyncrasies and providing a common interface is an essential part of game development.

Zap! is an audio management library that provides an interface to the common functions required in games and interactive applications. Including:

- Loading, buffering and managing sounds
- Seamlessly looping samples
- Multiple audio channels

Zap! is being used as the audio engine in Animash and will grow and involve with the project to support more functionality. 

Download and multiple examples on Github

We have life!

(not our server)

Our multi-player development server has sprung to life and can now host multiple games in many rooms at the same time, awesome.

One of the main aims of the game is to make it as easy as possible to create and join rooms (ongoing games), it should also be easy to make your own ‘corner’ and invite your friends for a private game. The solution is to have the game name in the URL with a hash eg:

game.com/#roomname

This way you could create your own private room just by entering it into the URL - of course there will be a nice interface for the less technically inclined.

The next step is moving some of the core game logic that is already written on the client-side to the server. This should help in making games fairer, easier to manage and harder to cheat on. In particular powerups are still being spawned in different positions and times on each players screen… not ideal!

(Source: Flickr / jemimus)

Node.js & Socket.io

Some big architectural decisions have been made over the last couple of days on the server side structure of animash. Originally we were thinking of creating the server in Ruby using EventMachine with Redis as the persistent store.

However, after researching node.js it seems to make sense to use a language that we know inside out (javascript) with a super active community and incredible performance. It will also give us the opportunity to share code between the client and server as well as leverage shared libraries like socket.io.

On the storage front the plan is still to use redis for storing user accounts and scores in simple, high performance sets.

Boom! Crash! Zap!

So, the original plan was to tackle the character animation first but this seemed like a waste before a designer gets onboard, instead I decided to stray into the minefield that is HTML5 audio.

The original thoughts were to use an existing library such as SoundManager2 or jPlayer to manage the in-game sounds and music. Although this would have meant introducing a flash fallback I’m not that fanatical over completely avoiding flash if it could provide a better experience.

However, after integrating SoundManager2 it was quickly obvious that the latency introduced was unacceptable and unpredictable - In all honesty I was also uncomfortable giving over such an important piece of the puzzle to 3rd party code. Unfortunately the problems with using html5 audio for games are numerous:

- The loop property is glitchy and introduces a gap at the end of each loop, rendering it useless for many in-game uses.

- The audio tag does not support multiple channels so cannot be started whilst it is already playing.

- Latency is variable as the tag doesn’t seem to be designed for real-time use, however the most recent versions of browsers seem acceptable n this department.

The next post will cover how to tackle the multi-channel issue, this I think is the most important element apart from latency which is largely out of the developers control.

Powerup Time

This evening has mostly been focussed on improving how powerups are created, initalised and managed within the game. The powerup management is a pretty standard affair contained within the main game class, it keeps track of whether there is a powerup on screen and spawns new powerups at appropriate times in random positions

The powerups them selves are extended from a base ‘Powerup’ class (which is itself a child of the EaselJS Bitmap class). See code in public gist here. This class is kept very simple, each powerup simply overrides the init method with it’s custom logic.

Currently powerups are spawned after a set amount of time in a random position, they stay in this position until collected - This will change so that they move if not collected, this should add some drama as it has to be reached before it moves and protect against the really rare occurance where a powerup could spawn in an uncollectable location.

Next up: character animation!