Christian Heilmann

One reason why HTML5 gaming is limping along

Thursday, January 26th, 2012 at 10:49 pm

TD;TR: Converting games to HTML5 is hurting the cause. We need more games written in web technologies.

OK, I might be a bit late to the party but the latest “web version” of Angry Birds, “subtly” advertising this time not itself but Wonderful Pistachios was the talk of the day on some of my mailing lists.

The main thing was that it requires Chrome to run. This is nothing new, but I really enjoyed the ingenious way of testing for Chrome in the first place:

if (Modernizr.testProp('-webkit-box-shadow')) {

So the CSS box shadow (which will soon be deprecated with the vendor prefix in Chrome) is the main identifier. Not bad. So let’s hack around the detection with:

var l = document.createElement('link');l.rel = 'stylesheet';
l.href = '';

Which leads us to a JSP file that detects on the server side and writes out a lot of inline webkit only code OK, never mind.

I am less annoyed that this is Chrome only. It was never claimed that this game runs everywhere (other than the Angry Birds released on Google IO). I am more annoyed about the bad performance the game has in Chrome and Safari on this Macbook Air. And I know the reason for this: conversion instead of dedicated development.

A look back in time – games on Commodore 64

As I have mentioned before, I used to work on some games on Commodore 64. In its heyday there was no way to have a game without writing it by hand – in assembly language and knowing what all the chips do. Perusing the memory map and the ROM allocations was part of the game of writing one.

When computers got more ubiquitous and better in terms of sound and graphics a lot of companies started building games on the other machines first – Amiga mostly. And to make extra money and sell even more copies, they also made C64 versions as conversions afterwards. These were most of the time shoddy at best and weren’t tested much. The C64 was the machine that is not where the money was made – the new hardware was the one to support.

The thing that got lost – and later on even more so – was the tinkering with the hardware and finding tricks to work around limitations. Out of the box the C64 had 8 sprites and a resolution of 160×200 pixels in 16 colours or 320×200 in 2 colours per 8×8 pixels. Using interrupts (executing code whilst the screen was painted by the TV or monitor) people came up with multiplexers that allowed for hundreds of sprites. With overlaying techniques we produced 256 colors at a interlaced 640 pixel resolution and so on.

A few of those tricks made it into the conversion tools from the “higher” computers to C64 code, but most were deemed too costly and time consuming and didn’t make sense to do any longer.

HTML5 gaming without the web stack?

This is happening now with “HTML5” games, too. Angry Birds is done with Google Web Toolkit, converted from Java I presume. It is made to work quickly and not show off what a web game can do, but instead how easy it can be to convert a game from Java to the “web”. And when that fails to bring the results it should, then we limit the web to one browser. And even fail at that as Angry Birds – in this case created to promote Chrome as a HTML5/games platform – doesn’t work on my Chrome book – the hardware dedicated to the browser.

Seeing this makes me frustrated, and it causes a lot of sniggering up to outright laughter from the Flash community. And they have all the right to. Flash games perform well, and showed that they can be easily changed and rebranded and extended when you build them the right way.

The HTML5 game engine vanishing act

Of course there are great minds on the case already and a lot of people build great demos and JavaScript frameworks to build HTML5 games in the technology rather than converting to it. The interesting thing about that is that every games engine released open source very quickly gets bought and un-opensourced and then vanishes from sight. The optimist in me thinks that this means there is great stuff afoot. The cynic in me sees the talent behind and the engines rotting away in a corporate environment as they were seen as a threat instead of an opportunity.

What HTML5 gaming needs to impress

I would love to see more real web games. Built in open technologies, with source available (or not, this is a nice to have) and really using the web. A web version of Angry Birds to me wouldn’t have a very long loader and ask me to sign in to Google to use it. It would be snappy and load the levels on demand, storing the ones I played and the next one locally in my browser while I am playing the current one. It would also allow me to build my own levels and share them on Twitter to see if I can build awesome stuff in the game that other people enjoy. All of this would be a total pain to make work on a mobile and a 3G connection, but is very much fine in a browser on a laptop with a good connection.

In other words, HTML5 games should be fit for the environment and use it to its strengths.

What about WebGL?

WebGL is an awesome opportunity for game developers to get into web gaming without needing to learn a new skillset. It is pretty obvious that an openGL developer could take it up much easier than a web developer would. Right now, WebGL is great for demos, but we have the issue of hardware access. If the biggest sound of the game is the fan of your processor and video card then this diminishes the experience. I for one never started gaming on PC as every new game coming out told me I need to buy new hardware in order to play it. This is not what I could afford. And this is not what we should force onto people on the web. A web app saying I need a certain browser or that my video card is not good enough to use it is not much better than the old “best viewed in IE4 with 800×600 pixels”.

We should think less World Of Warcraft and more Doodle Jump when it comes to HTML5 gaming.

Maybe I am a dreamer, and this is so not how the games market works. That is fine, though. A new market could emerge that takes the best of offline gaming and online experiences. But, we need to make that happen.

Share on Mastodon (needs instance)

Share on Twitter

My other work: