Hints for Making a Cross-platform HTML5 Game

You already know that HTML5 is great for game development, right? Perhaps best of all, it provides a way for you to develop cross-platform applications, effectively reducing the time needed to spend on browser testing. Even so, developing a HTML5 game is not always an easy task. In this post, I’m going to share some tips for developing a quality, cross-platform HTML5 game.

First Priority: Mobile

The mobile-first policy is something I ignored in my first HTML5 game project. From now on, I’ll never underestimate the amount of mobile players out there. I’m a game player. I love playing Angry Birds on the desktop, and I appreciate the fact I can play it on my Android device when not at home.

If I’d figured out this earlier, I would have spent more time and energy optimizing the mobile game experience instead of concentrating on the desktop browser experience with my first HTML5 game. Although I took it into consideration, mobile was only treated as a secondary game environment. Make mobile game experience optimization a priority.

Think Cross-platform Early

Take Zynga’s CityVille as an example. I’ve played CityVille before, as well as CityVille Hometown (the mobile version) on my Android device. Frankly, the game experiences are quite different. CityVille Hometown revolves around a a totally different gaming experience.

From a game developer’s perspective, CityVille is not suitable for a mobile platform — it would need to change significantly. Its menu is too large and complex for an iPhone’s screen; that’s why Zynga published individual versions of CityVille Hometown for iOS and Android. It pays to think of your cross-platform contingencies early on in the development phase.

Multi-platform Detection

Once you start to develop an HTML5 game, you may want to show different styles and forms of content (such as different user interfaces) for players on different platforms. This can become quite complicated, because whatever language you choose to specialize in, different devices always have differing levels of support for JavaScript, CSS3 and so on.

Use of JavaScript

JavaScript is pretty popular with most game developers. In the following code snippet, the JavaScript property navigator.userAgent returns a string object and enables you to detect the name and version of any web browser.

 <script type="text/javascript">// <![CDATA[ var mobile = (/iphone|ipad|ipod|android|blackberry|mini|windowssce|palm/i.test(navigator.userAgent.toLowerCase())); if (mobile) { document.location = "http://www.yoursite.com/mobile.html"; } // ]]></script> 

The problem is that many mobile devices don’t (currently) support JavaScript, and using one JavaScript script to detect all browser types could create a page performance nightmare for your users.

Use of CSS @media queries

Media queries are a good way of displaying CSS styles for mobile devices. You simply create one page and two style sheets — the first for a desktop screen, and the second for mobile devices. You just need to maintain one game page, and the style sheet defines how it looks.

Let’s suppose the screen size is 800px wide. We can use media queries to hide or move UI elements that aren’t critical for display on mobile devices:

@media screen and (max-width: 800px) {

    /* Whatever CSS you want here */

}

Use of PHP, JSP, ASP, etc

Another method uses a server-side language (PHP, JSP, ASP, etc) to detect the browser type. It doesn’t rely on a scripting language or CSS, which a mobile device doesn’t use. A simple PHP code for detection might look like this:

<? if ( stristr($ua, "Windows CE") or stristr($ua, "AvantGo") or stristr($ua,"Mazingo") or stristr($ua, "Mobile") or stristr($ua, "T68") or stristr($ua,"Syncalot") or stristr($ua, "Blazer") ) { $DEVICE_TYPE="MOBILE"; } if (isset($DEVICE_TYPE) and $DEVICE_TYPE=="MOBILE") { $location='mobile/index.php'; header ('Location: '.$location); exit; } ?> 

Bone Up on Your CSS Knowledge

Study and improve your CSS. Developing a game that runs on desktop, iOS and Android requires a large amount of CSS knowledge. Now, CSS3 is so powerful that you can make games entirely with it. In my team, there is a guy responsible for all CSS-related work, and he creates dynamically changing menu sizes depending on the mobile device. In cross-platform HTML5 game development, a good 50% of your work could relate to CSS.

Test with the DOM

When I began HTML5 game development, I thought it was a nice idea to render game using Canvas, because it’s quite useful on desktop computers. But on a platform like the iPhone 3GS, it turns out to be a bit of a headache. The game performance sucked; images were rendering at less than 5fps. I had to create rendering engines, one after another.

Currently, I rely on the DOM (Document Object Model). It dictates the way in which my applications are constructed of HTML elements and CSS3 selectors, rather than how they’re rendered to a Canvas. The advantage of using the DOM is that the game can be much faster and more responsive, due to hardware acceleration. It’s important to test your game again and again, and I personally think using the DOM is a better choice than Canvas.

Deal with Audio Issues

Embedding sounds within a game is vital. Unfortunately, the biggest issue in developing a cross-platform HTML5 game is sound. Within HTML5 game development, Canvas has good support, Video is constantly improving, but Audio is still pretty patchy. Games can’t play sound and music simultaneously. Taken from this aspect, HTML5 is not necessarily an ideal Flash alternative!

Other audio issues include:

  • Different browsers support different sound formats (mp3, wav, ogg etc)
  • iPhones and iPads allow only one mp3 sound to be loaded and played at any time
  • Android has limited support of the <audio> tag and the JavaScript audio API

There are a few ways around these issues:

  • For the format issue, I duplicate all game sounds in two formats (OGG and MP3), which covers most browsers.
  • For the iOS platform, I keep sound and music in the desktop version of the game, and only music in the mobile version.
  • As for Android, because it supports Flash audio play, so I use jPlayer to handle automatic HTML5/Flash audio transition.

However, all these should be temporary measures. The real solution for the issues surrounding HTML5 audio involves the W3C working with app and browser developers to create a good standard that everyone can follow.

Conclusion

I hope these tips are helpful in guiding you in the development of a cross-platform HTML5 game. Although it is not an easy task, and there are still problems such as audio integration, there is no reason not to develop a game that can run across multiple platforms and bring your game experience to a wide variety of users.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Bas

    Hi Benny, thanks for sharing your ideas. I lately tried to create a demo with css3, html5, javascript with a bunch of divs that were rotated and scaled using css transforms. Performance was awesome on desktops. It was ok on the ipad, until the memory was full. Then the performance dropped to 1fps, he ipad crashed with an out of mem message. You mention that using DOM elements should work better than using canvas, but didnt you encounter this problem? The task manager on my desktop showed that ffox needed only 190mb of memory to run the app, so its surprising that my ipad chokes on it. If you’re interested please send me an email, and I will show you the location of the js demo. It contains photos of other people, so I dont want to share it in public.

  • http://www.7plusdezine.com/ Benny Liu

    Hi, Bas,

    I do encounter with such problems. Mobile performance is not as good as on desktop due to poor support of hardware acceleration in mobile browser.

    Your demo is a typical out-of-memory problem. I guess the reason might be endless loop code, such as for(**, ** ,**){} that runs such long time, and while(**) that there’s no terminal point.

    Or the game creates so many object repeatedly, and doesn’t clean it up so as to save memory. Although one object only takes a little in memory, it will take out of memory after running a long time. That leads the crash in your iPad.

    Yep, I’m glad to help.

  • Matthias

    I believe that feature detection is more sustainable than browser or device detection, isn’t it?

    • http://www.7plusdezine.com/ Benny Liu

      Yes, absolutely!

  • http://qwokgames.com/ Jan Niestadt

    Good write-up. Another way to target HTML5 and stay cross-platform is with Haxe/NME: you can target HTML5, Flash and native iOS, Android, Window and Mac. I ported my HTML5 game over in the last few weeks and I’m very happy with it so far. It’s not the same as “pure” HTML5 development obviously, and indeed the HTML5 target for NME still needs a bit of work. But if you’re interested, you can read more about my experience here: http://qwokgames.com/2012/09/porting-from-html5-to-haxe-the-whys-and-the-hows/

    • http://www.7plusdezine.com/ Benny Liu

      Sounds pretty interesting Jan, let me take a look.

  • Anonymouse

    I believe you can use multiple audio tags for polyphonic sound in HTML5.

    Also this line seems a bit redundant.
    > “The problem is that many mobile devices don’t (currently) support JavaScript, and using one JavaScript script to detect all browser types could create a page performance nightmare for your users.”
    How would you even make a ‘html5′ game without Javascript.