Don't Blame the Platform, Blame "The Game"

June 23, 2012

Very recently, a friend of mine referred me to this article in which Wooga (developers of Pocket Island) outlined 3 technical 'limitations' of HTML5 (on mobile devices) that, to their opinion, prevented their game from being succesful. I must admit that, as an HTML5 Games developer, that article left a bit of a sour taste in my mouth.

In essence, what they said was that:

  • HTML5 Games took a long time to load
  • Users expected HTML5 Games to behave exactly like native apps
  • HTML5 Games on mobile devices had many problems reproducing sounds

Their premise was that these limitations prevented their game from being a 'hit'. What's even worse, the article states that "Despite the fact that Adobe seems intent on killing Flash, for many game developers, Flash is still a necessity".

As an HTML5 evangelist, I feel obliged to debunk some of these points and misconceptions.

I'd like to start by saying that all I mostly read about, talk about or write about is HTML5 Games, and only heard of "Pocket Island" when Wooga open sourced it (thanks to an article submitted to Hacker News). This basically demonstrates that they didn't market it that well. If I, an HTML5 Games "aficionado", didn't heard of it, imagine the rest of the public.

The second thing I'd like to suggest is that you make a reasonable guess as to how many flash games are available on Facebook. Take your time. What's your guess? 500? 1,000? According to this article on Quora that number is around 3,000, give or take. Okay then, now let me ask you: How many of those games are succesful? 30? 50? 100? Whatever that number happens to be, you don't see the ~96.67% of the unsuccesful games blaming Flash (or whatever other technology they happen to be using) for their failure, do you? Even if you focus on 'conventional' (native) games only a very small handful of them are succesful, and you don't see them blaming the Unreal Engine, Unity3D or CryEngine, etc. either.

Third, Flash doesn't run on iOS. Period. If you want your game to run on all platforms using a single codebase (that's PCs, Android AND iOS) HTML5 is your sole option. Flash is a no-go from the start.

I'd like to share a little story. Some time ago, while I was working at Minor Studios (a subcompany of Minor Ventures) I had the chance to talk with some of the lads behind a company called Swivel (another subcompany of Minor Ventures) that was nothing short of revolutionary. Before anyone started talking about the term 'Big Data', they not only perfectly understood that concept but also made a brilliant implementation that allowed to combine several datasets of huge amounts of information and tried to figure out how to compare and present them in very concise, unified, simple and easy-to-understand charts, to make sense of it all. The service was free, the team behind it was full of incredibly smart and brilliant folks, the codebase was maintainable and extremely performant and it all worked like a charm and yet... it never took off like they expected to and started to bleed money. Some time after, to my dismay, they closed up shop.

Swivel

The reality is that, sometimes, products and services are not appealing to most of the public (the ones that really matter). It doesn't have to do with the team, it doesn't have to do with the idea, and it absolutely, positively doesn't have anything to do with the platform. Whether you like it or not, that's just the way things are.

"Perhaps the market is not ready for HTML5 Games"

That's something that's being said every now and then which I always found (excuse me for my french) utterly stupid. "The Market" doesn't care how things are made, what they all care about is if it's appealing to them or not (there are many variables at play here, too many perhaps to be discussed under the scope of this article). Go to the Chrome Store and install "Angry Birds", or browse to the "Cut the Rope" homepage, or try PopCap's "Bejeweled" WebGL port. Now be honest, if you had never heard of HTML5 and were unable to right click on the page, would you be able to guess how those games were made? No, you wouldn't. And that's perfectly okay. What's important is not which technologies are behind each product, but rather, if said product runs well and is appealing. Almost always, the technology behind a product or service is not an indicator of the succesfulness of such product or service. Take Facebook for example, for many years I've heard Java and .NET proponents laughing at the low performance of PHP and how 'crappy' it is and yet, Facebook is one of the most succesful Internet companies ever made, and needless to be said, they rely almost entirely on PHP to support their backend infrastructure (albeit with some tweaks and additional tools & frameworks).

The reality is that the market doesn't care about these things because, truth be told, they are ignorant of the technologies behind each product or service. In essence, what this means then, is that if your product fails is not because of the platform, but because of the product itself. I know, it's a tough pill to swallow, but it's a bit arrogant to blame the platform for your own product's shortcomings.

However, I completely understand that if you come from a traditional game development background, some approaches used in HTML5 Game Development may seem weird and unintuitive. The reality is that to develop great gaming experiences that work perfectly well across devices and platforms you'll need to resort to a lot of hacks. And I really mean, a lot.

I may have to admit though, that audio playback on mobile devices is a somewhat problematic experience. Tools such as Zynga's Jukebox or using audio sprites might help to alleviate some of these problems, but nevertheless, it doesn't solve them completely. To this day, we're still unable to reproduce 2 sounds simultaneously on iOS. But if we know that we're going to have these limitations before we start developing our product, we might also design a graceful degradation that allows us to go around such problems and allows us to keep an overall satisfactory experience.

But what about the rest? It seems to me that both problems could be solved as easily as properly informing the user that the game will take some seconds to load (there's no need to load everything at once, this is the web after all). Once we have finished downloading everything, we can let the Application Cache and storing assets using Local Storage take care of the rest.

Then, finally, we can instruct the user how to add our application to their homescreen (iOS - Android) by properly presenting instructions on how to do it and the icon of our HTML5 Game will show up right next to the icons of other native applications installed on that device, like they expected to.