Recently we redeveloped CBeebies’ Tiny Tumble Bubble Art into a HTML5 game aimed at mobile platforms. One of the requirements for this project was that it be built on DOM elements rather than the canvas, the main argument being maximum browser compatibility (here’s looking at you, IE8). Today, we are going to cover a handful of the issues, workarounds and methods we came across and use while re-imagining a Flash game for HTML5 technologies.
The DOM relies on CSS to perform its image manipulation, which produces some interesting situations when dealing with animations, large sprites, or numerous sprites. Sprites are displayed using the DOM by creating a new div and assigning it a background image, generally a sprite sheet. If you require a large number of sprites, the number of elements on the screen will skyrocket, slowing down the browser which is especially noticeable on mobile devices. In order to animate these sprites, the CSS of the div needs to be modified so that each frame looks at the correct position of the background image. On top of this, there are limitations on the size of an image, especially on iOS devices, preventing them from loading and potentially breaking your game if you exceed them, necessitating good graphics management. DOM also limits what can be done with per pixel manipulation and image effects such as masking, meaning we baked in a lot of effects that normally could be added in programmatically in Flash. In order to create the “cut-out” style of Bubble Art to highlight the painting area and isolate the final picture sans masking, we implemented several layers of images utilising alpha to reproduce the effect.
Sound is the component of HTML5 that currently gives developers the most grief. If you want to be able to use more than one audio file in your game or app, you need the Web Audio API. The catch? Web Audio API is, as of writing this, a working draft. Meaning that implementation across browsers is sparse and currently limited to webkit based browsers, and in every case there is only partial implementation. Chrome 27 and Safari 6 are the only current desktop browsers to partially support sound in this way, while on mobile platforms partial support is available only on Apple devices running iOS6.
Ways around these limitations? A Flash fallback sitting silently in the background of the webpage ready to take over if HTML5 Audio fails or has no support. Not exactly an acceptable solution for HTML5 apps aimed at mobile, as well as defeating the purpose of HTML5 in the first place. Alternatively, you can limit yourself to a single audio file comprised of all your audio assets stitched together, playing and pausing as required, which can be unreliable at best.
HTML5 is still a developing area of the web, and there are still issues out there that are not DOM specific, sound being a major culprit. Issues will reduce in severity and be resolved as HTML5 technologies improve and as browsers update, more so as users migrate to canvas capable browsers. It will be interesting to see what can be achieved in HTML5 games in the future.