HTML5 game development: mobile platform comparison

I’ve been putting a lot of thought into the true definition of ‘cross-platform’ recently. When I started out developing games, there was no single language/IDE/API (call it what you will) that would deliver a game to every platform out there – although many promised to do so.

 

I thought at this point developing on HTML5 with CSS and JavaScript and using PhoneGap to port to all platforms would be the solution. I was pretty wrong about how painless this would be. The information below is intended to be a guide for new developers so that they don’t have to go through many months of frustration.

 

When I started this journey, this was my loose, perhaps naive definition of the existing ‘platforms’ out there:

 

Phones

Definition: a device with a screen smaller than about 6″ that had cellular network connectivity built in. It can fit in a pocket and most people would carry it with them all the time.

  • iPhone (including iPod touch)
  • Android (phones)
  • Blackberry
  • Windows
  • Nokia

Tablets

Definition: a device with a screen larger than about 6″ without a physical keyboard. It has a touch-screen surface and primarily connects to the internet over WiFi. It usually cannot run PC operating systems. It is not as easily ‘portable’ as a phone.

  • iPad
  • Android (tabs)
  • Blackberry
  • Kindle
  • Nook
  • HP tabs (WebOS)

Computers

Definition: desktop or laptop devices with a physical keyboard including all-in-one desk computers and netbooks. It primarily connects to the internet over WiFi, ethernet, DSL etc.

  • Windows
  • Mac
  • Unix (all flavours including Linux, BSD etc.)

Consoles

Definition: devices that require a TV or similar for output. Mostly used for gaming. It primarily connects to the internet over WiFi, ethernet, DSL etc.

  • Sony PlayStation
  • Microsoft Xbox
  • Nintendo Wii

Other Devices

Definition: anything not included above. Examples below.

  • Nintendo DS
  • Sony PSP
  • Nokia N-gage

Note: my definition of a ‘platform’ is the final device/operating system that a user would play my games on (e.g. an iPhone). It is not the system upon which a developer makes games (e.g. Unity).

 

That’s a boatload of platforms! Knowing that I had to decide on jut a few to get my games out there, I narrowed it down pretty quickly. I wanted platforms that:

 

  1. Were already fairly large and growing (in terms of user/device numbers)
  2. Were fairly easy (quick / cheap) to develop for
  3. Allowed the ‘core’ game code to be fairly easily ported to other platforms
  4. Were fairly easy to distribute games on

That pretty quickly ruled out consoles and other devices. I wrangled over computers for a while but decided against them (at least initially) because the user base isn’t growing as fast as mobile/tablet and because distribution on computers is still a jungle – there is no one universally accepted ‘store’ equivalent on computers, although iTunes is pretty close for Macs and the Windows 8 store shows promise, but it’s far too early to tell.

With that in mind, I had another decision. Which development tool do I use? My choices were:

  1. Native code. Most expensive option as games would need to be re-developed for every platform. But games would be super fast and smooth.
  2. Flash. Already very popular on computers. But Apple’s lack of support is a major stumbling block for portable device deployment.
  3. HTML5. New technology so there would be teething problems. But allows porting (in theory) to any device that can run a browser and can be made to look like native code.

HTML5 it was. So now that we’re almost at the end of the decision making funnel, I had to decide which mobiles/tablets I would develop for. I knocked out Blackberry and Nokia for mobiles as their market shares are rapidly declining. On tablets, I knocked out HP tabs because they are effectively discontinued. Finally, I knocked out Kindle and Nook because they (primarily) only serve the US market. What’s better: a potential market of <300 million or up to 8 billion? Easy decision ūüėČ

There are 3 key issues to manage when porting between ios, android and Windows 8:

  1. Scaling. This includes everything related to changing the size, shape and position of your graphics to make the game look and play properly on the target platform. It includes resizing images up/down, and resizing or repositioning graphics to accommodate a change in aspect ratio.
  2. Code (APIs/plugins). This includes anything to do with trying to get other 3rd party software to work with your core game software. The main types of APIs or plugins for games will be in-game advertising, social networking, external storage, or any other additional features.
  3. Code (compilation/development environment). This includes anything to do with how easy it is to compile the JavaScript code in to a game that works on the target platform, and generally how easy it is to use the tools that various vendors provide (e.g. the Eclipse IDE) for writing the core game code.

 
So here are my findings:
 

Mobile Device/OS

Scaling

API’s/Plugins

Development Environment

Apple ios      
iPhone 3G Same as iPhone 3G РiPhone 4. Even the most basic of JavaScript game code will not compile on iPhone 3G. You effectively cannot support this platform. Uses xCode. See left.
iPhone 3G+ Same as iPhone 3G РiPhone 4. May have higher resolution on iPhone 4 so some images may need to be made larger. Same as iPhone 3G РiPhone 4. See left.
iPhone 5 Different aspect ration and resolution to all other devices. Requires significant layout changes. Potentially some issues with ios 6, but nothing major yet. Mostly the same as iPhone 3G РiPhone 4.
iPad Same as iPhone¬†3G – iPhone 4. Has higher resolution so images need to be made larger. Mostly the same as iPhone¬†3G – iPhone 4. Same as iPhone¬†3G – iPhone 4, but iPad apps need to be compiled as a separate ‘version’ to iPhone apps due to different app stores for Apple phones and tablets.
Google Android      
<2.2 No difference on android between phones and tablets so scaling always an issue due to number of different device screen sizes and aspect ratios. 9-pacth PNGs sometimes help. Serious issues with early android versions’ handling of sound and storage. You effectively cannot support this platform. Uses Eclipse. See left.
2.2-2.3 As above. Some issues related to android not fully supporting scrolling DIVs, non-square glow effects etc. Some issues with handling of sound and storage, but can be worked around (takes research and time though). See left.
3.0+ As above. No major issues found. No major issues found. Very mature development environment comparable to Apple iPhone 3G – 4.
Microsoft Windows 8      
x86 Will need to cater for every possible monitor resolution and aspect ratio. One workaround is fixed size/aspect ratio (e.g. 1024×768) with borders for larger screens. However, see right. Code that compiles for Windows RT simply will not compile for x86. Microsoft support very poor in explaining why. Uses Visual Studio 2012. However, see left.
RT Currently fixed resolution / aspect ratio of 1366×768¬†makes it simple to layout. However, this is likely to change in future. Still has a few teething problems. PhoneGap support only recently introduced. Deployment to Windows 8 store a nightmare! Very immature compared with Apple and Google.
Phone Too early to tell if resolutions / aspect ratios have been standardised, but given it’s an ‘open’ platform device manufacturers will make a variety of different screens which will present the same challenges as the x86 version. See above. Requires separate license fee and codebase.

I will soon be including the following data to the above table to further help other developers in decision making:

 

  1. Market size. This will be the installed base of devices on that platform, or number of devices out there that people are actually still using.
  2. Competition. I’ll define this as number of apps in the respective app stores, broken down by utility apps vs. games.
  3. Growth rate. I’m not a big fan of crystal ball gazing, but I’ll gather some data points on the forecast sales of devices. I’ll also try to factor in the cannibalisation of existing platforms due to upgrades (e.g., in theory, some proportion of iPhone 5 sales means a number of iPhone 4’s will no longer exist due to breakage). The number may not be very large as most old devices are usually given to friends or relatives if they still work.
  4. Monetisation. A tricky one, but I’ll attempt to gather data on dollars spent per day per device. I may have to end up using daily app store sales x average app store prices / installed handset base as a proxy for this one.

Comments are closed.