HTML5 – Game on?

HTML5 is often (rightly!) lauded as the heir to Flash’s gaming throne. It offers true cross-platform development that allows you to build once and deploy to desktop, tablet and mobile. It’s a technology that can run on Smart TVs, or wrapped in a native application for desktop and devices. It can even run on consoles like the Xbox 360 or PlayStation 3 via their built in browsers.

HTML5 is an understandably attractive prospect for anyone looking to develop games across a large number of devices and platforms. But there remain some distinctive challenges.

The term itself, much like the specification that it represents, has a different meaning depending on who’s describing it. For clients, HTML5 is a technology that promises the Holy Grail of simple, cost effective, cross-platform delivery.

For developers, it’s the collective term for dozens of different technologies; JavaScript, Web Sockets, Web Audio, Canvas, CSS3, WebGL to name a few – each with their own standards, strengths and limitations from platform to platform.

But for users: it’s irrelevant – they just want the same experiences and performance they’ve become accustomed to, whatever they’re using. And as developers, that’s where our main challenge lies, especially if your aim is to deliver your game across a range of devices.

Desktop vs Mobile vs Cross Platform

By now we’ll all be familiar with the fantastic examples of HTML5 games that run within desktop browsers. They’re often created or funded by browser manufacturers themselves to showcase particular strengths in their own software, or to make the case for particular APIs they’d like to see ratified into the HTML5 specification.

Games such as HelloRun, or some of the excellent Chrome Experiments such as Racer or Arcade Fire’s Reflektor are great examples of what can be achieved in-browser using HTML5. If you want to see the future potential, look to libraries like three.js, the recently open-sourced Turbulenz or Epic’s HTML5 port of their Unreal Engine.

Technologies like WebGL show the future potential, but are beyond the capabilities of the current generation of mobile devices.

However, try looking at some of these examples on an Android device running OS2.3 (Gingerbread) and you’ll have a very different experience, or in some cases no experience at all.

Yes, that’s an operating system that’s nearly three years old, but it still represents almost a third of the installed Android base, a figure that could be even higher depending on your target demographic.

It’s not just older versions of Android. You’ll see a similar experience on Apple devices running iOS 5, or lower powered devices like the Kindle Fire. In actual fact, there isn’t currently a single mobile device that will run every one of the above demos well.

As mentioned earlier, for most clients the reason for choosing HTML5 is to ensure that their browser-based game is truly cross-platform. If you’re developing for desktop only, Unity and Flash are both strong options that should always be considered. They both have good browser support and the ability to export to devices as a native application, giving you a route to mobile and tablet from the same code should you require it.

There are two obvious challenges when developing cross platform games in HTML5. The first is the fluid nature of the HTML5 specification. This can result in fragmented feature support not just from device to device, but from browser to browser on each of those devices. Not just that, you’re developing against a constantly moving set of capabilities and support.

Just look at the recent launch of iOS 7, which broke a number of key features essential for HTML5 gaming, or the launch of Firefox 25 which finally added Web Audio support but at the same time broke the audio implementation of a large number of HTML5 games. Not quite ‘the foolish man built his house upon the sand’, but indicative of the problems that can happen overnight and are out with your control as a developer.

The second, and more challenging as a developer, is the massive variation in mobile handset performance and capabilities. Even when using a consistent feature set, how your game runs will vary massively between devices.

In order to understand just how much of a variance exists, you can run one of the many JavaScript benchmarks to test device performance. As an example, rendering 100 sprites via Canvas will perform at a relatively solid 60 frames per second on devices like the iPhone 4S or 5, Galaxy S3, Nexus 7 or Lumia 820. But if you try the exact same code on other devices like the HTC Desire (19fps), Galaxy Ace (7fps) or iPad 1 (9fps) and you’ll struggle to get anything representative of a playable game.

If your project involves targeting mobile or tablet, and especially if that includes these older or lower powered devices it’s essential to test and benchmark early on. This way, you understand the limitations of your device range and can tune both your technical approach and your game design to work within them.

And if your project isn’t targeting mobile or tablet, it probably should. Nearly a third of UK page views are from mobiles and tablets, with that growth climbing at such a rapid rate it’s expected to overtake desktop views in 2014.

While PCs still dominate during working hours, mobile devices are prevalent in the mornings and tablets in the evenings – both ideal times for browsing the web and playing games.

Choose your battles

At Chunk, we’ve been developing cross-platform HTML5 games for broadcasters and brands for almost two years. We’ve created browser-based mobile games for clients like the BBC and Disney that run on everything from an HTC Desire to an iPad4, from a Nexus 7 to an Xbox360.

Chunk’s Agent Alert Field Missions for Disney runs on a huge range of devices, from the HTC Desire to the iPad Air.

As developers, it would be great to determine how deep into this fragmentation we want to dive, but our target audience and the devices they use largely dictate this. Working with children’s brands, we have often found ourselves working within the constraints of older ‘hand-me-down’ phones, or cheaper, underpowered devices.

However, with careful design and a lot of optimisation, it is still possible to produce engaging gaming experiences on the mobile web.

What have we learnt from those experiences? Well, if we had to produce a list of the top ten tips for HTML5 games development, it would be as follows:

1. Consider your audience. What’s your demographic, and what devices are they using? If you have web metrics, look at them to understand the core range of devices your visitors use and target your solution at those devices.

2. Design your game with your technology in mind. Yes, this should always be the case, but the limitations and fragmentation of HTML5 make it even more pertinent. WebGL will let you make a great 3D first person shooter, but its unlikely to (read: not going to) work on tablet if that’s going to be one of your target platforms.

3. Become familiar with caniuse.com. It’s a great way to quickly check the support for any HTML5 feature that you would like to use across practically every browser or device.

4. Fill your studio with as many devices as possible, running as many different OS versions as you can. Simulators will help during development, but to get an accurate picture of how your code is performing you must be testing on the devices themselves. There are some great community-led device testing labs like opendevicelab.com that will give you access to a huge number of models. Scour places like eBay to find old handsets and add them to your test lab.

5. Keep ahead of the curve. The HTML5 specification is constantly changing, as is device support and you need to keep on top of these developments. This is especially relevant to areas like sound, where features like the WebAudio API can radically change the capabilities.

6. Stay agile throughout development. What isn’t available to you today may be tomorrow. What works this week may not work the next. Allow yourself the flexibility to adapt to these changes as they happen throughout your build.

7. Think about ways to scale functionality. A mobile first approach isn’t just for traditional web design. Look at ways that you can create a good experience on mobile and then layer on functionality and effects for other platforms as they permit. Target those devices using user agents or media queries and deliver a tailored experience relative to each.

8.KISS. By all means test limits and try to push capabilities, but remember you’re working with a technology that’s in its infancy, and an overcomplicated or overambitious project will be likely to cause you pain down the line.

9. Consider the lifespan of your content. Capabilities change all the time, and content can become dated quickly as new features are enabled on devices. If your game is going to be live for a reasonable length of time, allow yourself time to go back and both bug fix and update it.

10. One last one? Oh yeah. Test on every device you can, as often as you can.

Gladiator, you will go on my second whistle

HTML5 will be the go-to development technology for cross-platform browser based gaming, of that there’s no doubt. At the moment it can be a painful space, but that’s the case with most technologies in their infancy.

Tools such as the CreateJS framework or WebGL exporters are really going to help smooth out the bumps in your development workflow. And you’re going to want to get that as smooth as possible, as pretty much every connected device will have some form of HTML5 capability in the future, including consoles such as the Xbox One and PlayStation 4.

Become familiar with sites like caniuse.com to check compatibility, test regularly and continually on the biggest range of devices you can. Be pragmatic in your game design and not only will you reduce your pain for now, but you’ll put yourself in a strong position when device support catches up, which is going to do very, very soon.