I ran some simple tests this morning across a small range of devices. I selected the most popular devices according to figures gathered by Google’s Analytics. The results are in some respects quite surprising. In others (iOS’ dominance) they’re not.
I don’t like Android for making HTML5 arcade games. I find it to be a deeply troublesome platform with all kinds of issues surrounding performance and response. But as a developer I can’t ignore it.
|Device||OS||Browser||Traffic %||Drawing||Touch Response||Touch.Move Response|
|iOS devices account for approx 50% of all traffic with iPad the standout device|
|Samsung Galaxy Y is the standout Android device in terms of popularity but still minimal volumes|
|Kindle Fire HD||Android 4.0 (Ice Cream Sandwich – modified)||Stock||< 0.5||OK||Good||Good|
|Samsung GT-I9300 Galaxy SIII||Android 4.1.1 (Jellybean)||Stock||0.89||Excellent||Excellent||Excellent|
|Samsung GT-I9100 Galaxy SII||Android 4.0.4 (Ice Cream Sandwich)||Stock||1.36||Good||Excellent||Excellent|
|Samsung GT-S5360 Galaxy Y||Android 2.3.6 (Gingerbread)||Stock||1.55||Good||Good||Fail !|
|LG LG-E400||Android 2.3.6 (Gingerbread)||Stock||1||Good||Good||Good|
|HTC Desire HD||Android 2.3.5 (Gingerbread)||Stock||< 0.5||Good||Good||Good|
The Samsung Galaxy S3 is a temperamental device. In almost every respect it’s a beautiful machine yet it seems to let itself down with the most basic of operations.
For example, I found that clearing the screen was an issue when using canvas.width = canvas.width (the screen remained either static or simply blank)
When I switched back to the context.clearRect() method it worked fine. I’m not sure if this a true reflection of the underlying error but it’s certainly a “bug” I can consistently re-create.
In some respects the screen clearing is academic to me these days. I find performance is still very high when drawing an entire screen full of background graphics. Drawing a full screen as the first draw operation on each frame is a heavy handed method of clearing the previous screen state and possibly not a best practise but for now effective.
I clearly have some problems in my code regarding the touchMove event on the Galaxy Y. The same OS on a different phone fires and handles the event without any problems.
An obvious question when reviewing figures like these is “just how relevant is the OS ?”
Are the early Android OS’ really relevant ? Surely Gingerbread has long been superseded on these phones.
Alarmingly the answer (according to my own stats) is not. Android 2.3.x is still by a country mile the most popular version of Google’s OS to play my games.
I had very much hoped that this wasn’t the case and that I could just assume that gamers with newer phones are able to upgrade and in fact DO upgrade.
I should add that on a number of the above Android devices I have Chrome and in some cases Firefox installed. All the games work beautifully in those browsers although web audio is still unsupported.
Firefox reliably supports IndexedDB fully in that it supports the onupgradeneeded() event.
Currently in the above scenario only iOS6 fully supports the HTML5 audio API. Interestingly the Kindle Fire HD passes all the tests for web audio support yet fails to play any sounds ! I’ve asked the question at Amazon and am waiting for a response. I can’t see any obvious glitches in my code but I will continue to pore over it.
I’m not sure it’s fair to draw any real conclusions from this short test.
All in all it was quite a satisfying little test if only to reassure me that the fact that these games run well on iOS is providing a great experience for the largest section of my user base.
Given how far we’ve come in 12 months I’m pretty sure that the top 10 phones in my analytics this time next year will perform all of these features beautifully and as HTML5 game coders we can just get on with making great games ! :-)