HTML5: the rightful heir to Flash’s gaming throne. True cross-platform development that allows you to build once and deploy to desktop, tablet and mobile; that will run on Smart TVs; can be wrapped up in a native application for desktop and mobile devices – and can even run on consoles like the Xbox360 or PlayStation 3 via their built in browsers. It’s an understandably attractive option for anyone looking to develop games for a large number of devices and platforms.
The term HTML5 itself, much like the specification that it represents, has a different meaning depending on who’s describing it. For clients, it’s a development technology that promises the Holy Grail of simple – and therefore cost-effective – cross-platform delivery.
Lastly, and perhaps most importantly, for users: it’s irrelevant – they just want the same experiences and performance that they’ve become accustomed to. And as developers, that’s where our main challenge lies, especially if your aim is to deliver your game across a range of platforms.
Desktop vs mobile vs cross platform
By now we’re all familiar with the fantastic examples of HTML5 games that run within desktop browsers. They’re often created by browser manufacturers themselves to showcase particular strengths in their own software, or to make the case for particular APIs that they would like to see ratified into the HTML5 specification.
Games such as Cut the Rope or Contre Jour for Internet Explorer, or some of the excellent Chrome Experiments like Jam or Racer are great examples. 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.
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 almost three years old, but it still represents almost a third of the installed Android base, a figure that could skew even higher depending on your target demographic. And it’s not just older versions of Android. You’ll see a similar experience on Apple devices running iOS5, or lower powered devices like the Kindle Fire. In actual fact, you currently won’t find 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, resulting in fragmented feature support – not just from device to device, but from browser to browser on each of those devices. The second, and more challenging as a developer, is the massive variation in mobile handset performance and capabilities, meaning that even when using a consistent feature set, how your game runs on one device will vary massively from the next.
If your project involves targeting mobile or tablet, and especially if that includes these older or lower-powered devices, it’s important to test and benchmark early on to understand the limitations of your device range and tune both your technical approach and your game design to work within them.
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 that it is 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, and have 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.
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 will 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, but with careful design and a lot of optimization we believe that it is still possible to produce engaging games 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;
- Consider your audience. Look at the demographic and what devices they’re using. If you have web metrics, use them to determine the core range of devices your visitors are using and target your solution at those devices.
- Design your game with your technology in mind. Yes, this should always be the case, but the limitations and fragmentation in 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.
- 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.
- Get your hands on 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 have to be running on device. There are some great community-led device testing labs like Open Device Lab that will give you access to a huge range of devices. Otherwise scour places like eBay to find old handsets and add them to your test lab.
- Keep abreast of the ever-changing landscape. The HTML5 specification is constantly shifting, as is device support, so you need to keep on top of these developments as they happen. This is especially relevant to areas like sound, where features like the WebAudio API can radically change the capabilities.
- Stay agile throughout development. What works today, may not work tomorrow. What isn’t available to you today, may be tomorrow. Allow yourself the flexibility to adapt to these changes as they happen throughout your build.
- Think about ways to scale your 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.
- KISS (Keep It Simple, Stupid). By all means test the limits and try to push the capabilities, but remember that you’re working with a technology that’s in its infancy, and an overcomplicated or overambitious project is only going to cause you pain down the line.
- Consider the lifespan of your content. Capabilities are changing all the time, and your content can become dated very 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.
- 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 is going to be the de facto development technology for cross-platform browser-based gaming, of that there is no doubt. At the moment it’s a painful space, but that’s the case with most technologies in their infancy. Become familiar with sites like caniuse.com to check browser compatibilities. Test regularly on the biggest range of devices you can, and be pragmatic in your game design. Not only will you reduce your pain for now, but you’ll put yourself in a strong position when device support catches up, which it inevitably will.
Title image courtesy of MediaLoot