Earlier this year Spil Games asked us to create a new mobile HTML5 version of their classic Mahjong-inspired game, Dream Pet Link. If you know anything about HTML5 game development you’re probably aware that there’s some controversy over whether it is now, or ever will be, a viable platform for game development, especially mobile game development. This article isn’t about that, though the debate will continue.
We want to convey real, practical, information to game developers who are thinking about making games in HTML5, which is the new lingua franca for the multiplatform web software. If cross-platform HTML5 games become popular, life will become easier for game studios that currently spend a lot of resources making different versions of games for every single platform. We know it can be done, because we’ve done it. In this post we’ll show you (at least at a high level) what we did with the hope that it will encourage you to take the next step and start building great HTML5 games. (Note the HTML5 Developers conference is coming up Oct. 22 and Oct. 23 in San Francisco).
Above: Dream Pet Link
Challenges of HTML5
In porting any game to mobile, you need to consider things like adapting mouse or keyboard inputs to touch and support for different screen sizes and orientations. Porting from Adobe’s Flash format to HTML5 presents additional challenges.
Flash is mature platform that is extremely consistent across different web browsers, but the HTML5 platform is still evolving and can vary by implementation. Although we are seeing very good implementations from several phone makers on modern devices, there are still many legacy devices in market. Supporting these devices isn’t easy.
The two biggest problems we encountered were poor rendering performance and audio capabilities.
While there are multiple ways to render graphics in an HTML5 game, the one most familiar and accessible to game developers is the Canvas applications programming interface (API). Much like other 2d graphics APIs, the Canvas API provides a drawing surface in which to render graphics primitives (e.g lines, rectangles and text) as well as draw prerendered bitmap images. Some platforms provide hardware acceleration for canvas rendering operations by offloading drawing tasks to the GPU (graphics processing unit). Unfortunately, not all mobile platforms have hardware acceleration available and others don’t accelerate all drawing operations.
Screen sizes and CPU performance also vary widely across mobile devices. Some devices have a slow CPU with a large screen. This is the worst case scenario since blitting performance is a function of the number of pixels that need to be copied.
In order to overcome these challenges we created multiple resolutions of our graphics assets. This allows us to show optimal resolution graphics while not wasting cycles copying more pixels than a particular device can handle. We also took advantage of CSS scaling (typically hardware accelerated) to allow the game to fill the screen even if the graphics didn’t exactly match the screen resolution.
Audio support was an even bigger challenge. There are essentially two ways to play audio on mobile HTML5 browsers. The “old” way is to use HTML5 audio (also known as the <audio> tag). This method is widely supported but provides limited audio capabilities, the most severe of which is the inability to play simultaneous sounds. A newer API called the Web Audio API provides advanced audio support, including the ability to precisely time sound playback and play simultaneous sounds. It is not yet widely supported for Android mobile devices, though it’s rapidly gaining ground and is notably available on iOS 6 and better devices.
Editor’s note: Developers! If you’re good and want to be great, our upcoming DevBeat conference, Nov. 12-13 in San Francisco, is a hands-on event packed with master classes, presentations, Q&As, and hackathons, all aimed at boosting your code skills, security knowledge, hardware hacking, and career development. Register now.
In order to avoid a lowest common denominator approach, we support both HTML5 audio and the Web Audio API. We detect at runtime if Web Audio is available and, if not, fall back to HTML5 audio. If we only have HTML5 audio we avoid playing sound effects over music. We also recently implemented support for audio sprites to work around some of the latency issues with mobile HTML5 audio implementations.
By adapting the graphics to the rendering performance of the device and supporting multiple audio playback methods we were able to work around a large number of problems that we’ve seen with other HTML5 mobile games.