The thrill for me in making these simple browser games is the challenge of a new feature. I’ve wanted for a long time to sit down and figure out just what I need to add to my game’s framework to ensure that future developments are made that bit easier.

There’s another driving factor: publishing the end product to the client. More often than not when I sit down to try and identify the bottlenecks in the process I see that publishing and all the associated / bespoke developments comes back to haunt me. Many of the new features I have added in the last week have been driven through necessity based on specific client requirements.

With every new game that I create there’s always a variety of things that I have to do to it for it to fit with the client’s contractual requirements. Such things as localisation, adding back-links to specific locations, the presence (or otherwise) of advertising, audio, scaling, screen-locking. The list grows.
Most recently I have done a fair amount of work in importing and exporting specific data from each game. The client wanted specific data both ingoing and outgoing from each game.

Again courtesy of the querystring the games accept a string of data, store them within an AJAX object and then pass them out to a .php (or whatever format you like) file at set intervals in the game.
The games also support MD5 for added protection.

Once written it naturally made sense to add this as a complete feature for future games. Not too difficult to code by any means but a fantastic feature to be able to sell.

So I implemented a bunch of new features that allow me to just focus on getting back to making games.

For example; at the start of the game’s initialisation it scans the querystring. If it finds returnURL and a corresponding value it paints a branded backlink icon to the screen in a pre-configured location that acts as a shortcut back to the parent site.

For fonts I use Google’s font library for my games. This is a wonderfully free method for introducing some variety to my game’s copy. But when it comes to translation in to a language such as French we soon find that the character set does not support the variety of accents and other language-specific features. In this scenario the game knows to revert to a safe font and will resize and position the text accordingly.
The data in my text arrays is always saved out in UTF-8 so presenting rich character sets in a standard system font is easy.

requestAnimationFrame (rAF) and Audio were the last two features to go in. rAF gives silky smooth movement in browsers that support it and audio, courtesy of the Web Audio API, simply brings the games to life.

I’m looking forward to being able to sit down and churn out more games. I always intended to aim for 2 – 3 new games a month. One of my key goals for 2012 was to increase my portfolio from 8 to 30 games. There’s chance of a late spurt in development, yet !

With this new framework for making games rapidly taking shape I’m confident I can achieve it.

Like this:

When I first started creating these HTML5 arcade games I confess I had nothing to test them on. So I created my games and just tested them in a desktop web browser. Normally Chrome.
It soon became apparent that the best way to reach out to people and monetise my work was to adapt the games to run within a mobile browser.

I soon became bored of pestering friends to test my games so I scraped together some cash and bought an HTC Desire HD. A wonderful smartphone in every respect but perhaps not the best handset to choose for testing.
You see the handset is so capable it can run CANVAS based games at lightning speed. I was really no better off than when I was using the desktop.

My wife has an iPod Touch first generation. I tested my games with this for a while and assumed that the games would work first time on all iOS devices.
How wrong could I be ?

iPhone 4 is a dog. I soon realised that the CANVAS performance on iPhone 4 was considerably less than desirable. There are probably several reasons for this and generally they’re not without their fair share of conspiracy theories.
Apple throttling JavaScript performance on iPhone 4 deliberately to encourage more business through their App Store ?
Surely not.

Whether it was true or not I was left with a huge hole in my portfolio. I had these cool looking games that really only worked on anything that wasn’t an iPhone 4. Trouble is of course that iPhone 4 is one of the most popular handsets in the world. My market was a fraction of the size it could be.

To make things worse I’m really not a hacker. I guess I hold this daft old fashioned view that I shouldn’t have to hack. I’d rather the vendors sort their devices out than me hack around trying to scrape some FPS together. I’m really just terrible at that kind of thing.

So yesterday we saw iOS5 arrive. Plenty of hype about a number of cool features but not much of a fanfayre for the performance of JavaScript in the browser. A few rumours surfaced that the performance was up to 3 or 4x the performance of the current hardware but I really needed to see it for myself.

I decided to put together some tests to compare raw CANVAS performance against old school DIVs and IMGs.

If you have a mobile phone point it to the two following links.
Take a look at the FPS count in the top corner. If you like comment your findings below. I’d be interested to see your thoughts and experiences.