Why developing an HTML5 game is too damn risky

I’ll preface this by saying that yes, I’m running Google Chrome Beta as my main browser, and yes, some bugs are to be expected from running a beta browser. That’s besides the point. So what am I complaining about?

Any small bug on any browser can instantly kill a product you’ve worked months or years on.

A few months back, the Chrome Beta had a bit of an issue. By a “bit”, I mean a massive issue that would’ve left Subbania dead in the water if I’d released it. What was the issue? Sounds wouldn’t loop or play more than once. This is one hell of a problem when you realize games are all about sound and graphics working together to make the player feel like he’s in a world. Having a damage sound effect trigger only once every 5-200 attempts makes a game unbearable, and it’s much worse when it’s completely inconsistent. I’d sometimes refresh and sound would work perfectly, only to be in complete silence 5 minutes later. Bugs are to be expected and it can be a pain in the ass to find them, but it’s a nightmare when everything that can go wrong will go wrong, and it’s entirely out of your hands and completely up to some other entity that doesn’t give a damn about your little app.

You might still say, “It’s a beta! Of course there’ll be bugs like this!” Yeah, but what if these make it past the beta phase and into a final release? Hell, this bug took about 3 weeks to patch. And what about those people that use the beta (e.g., me) and see the bugs and glitches as a result of your incompetence? Nobody’s going to say Google programmers are idiots, so all the blame goes on that little indie dev making a crappy little game. The most vocal people on the internet are the people with bad experiences, and it only takes those 5% of beta users to completely kill your product the day it launches.

That isn’t all. At the moment, there’s some bug in the beta version of Chrome that literally makes my game unplayable when going into certain levels. Memory usage swells to 800 MB for that tab in under 60 seconds and the game slows down from 60 FPS to 10 to 1. I don’t know what’s causing it. I literally woke up one day after having not changed my code in half a week, Chrome Beta updated, and my game was ruined. It works in Chrome 17 just fine, and my biggest fear is this bug somehow making it through the beta and into a final release. Then all hope is lost on the game I’d been working on for a year.

And this doesn’t even begin to go into the inconsistencies across browsers. Subbania in Chrome and Subbania in Firefox look like two completely different products.

Text and line rendering in FirefoxText and line rendering in Chrome
Firefox first, Chrome second. Note Firefox’s “fuzziness.”

My solution? Learn from me and don’t develop an HTML5 game unless you absolutely know all browsers will abide by web standards and never introduce bugs ever. It’s nice that all these browser vendors are getting their shit together and making more frequent releases to keep up with the rapidly evolving internet, but it also means more things will break more quickly and you can’t do anything about it.

Now, this isn’t anything against Javascript or HTML. I love Javascript as a language. It has its inconsistencies, but as a whole, it’s a beautiful language with tremendous flexibility and I’d love to use it everywhere. However, I can’t trust my browsers. I’ll consider development in Lua in the future.

This entry was posted in games, html5, javascript, Uncategorized. Bookmark the permalink.

15 Responses to Why developing an HTML5 game is too damn risky

  1. This is a really annoying problem and I remember a version of Chrome that didn’t render DOM entities if they moved using left/top too frequently. It was solved using CSS3 and later the bug was fixed in Chrome but it nevertheless is a problem that is essentially out of your hands bar patching it yourself.

    However I disagree with your statement that we shouldn’t bother making games in HTML5 it until it’s fixed. It should be the opposite. The more people that make HTML5 games means browser developers will prioritize bugs that affect these games. Too really push a technology you need developers to use it regardless.

  2. richtaur says:

    Totally valid and understandable complaints. We talked about this kind of stuff in our podcast HTML5, the Bad Parts. While the inconsistency in implementation sucks I feel like it’s just par for the course in the web world. I’ve been a frontend for years (I’m used to working in IE6, for example) and I think consistency has improved significantly.

  3. Hardeep says:

    This seems a bit ridiculous… I’m sorry but you’re complaining that a beta browser doesn’t work properly with an unfinished spec?

    Ok then…

    Besides the fact that any development framework can experience things like this. Unity, XNA, .NET, etc… they’re simply more mature at this point.

  4. Sean Murphy says:

    Having built an HTML5 game engine from the ground up over the past year, I’ve come to find out that often when a bug appears out of nowhere or due to an update, it is almost certainly because of reliance on non-standard or experimental behavior. The second biggest cause is due to relying on seemingly-consistent timing of your rendering loop. Firefox is particularly bad about this but every other browser, even IE8, handles rendering in a consistent way if you really understand what is going on.

    For example, your fuzziness can eliminated using the image-rendering CSS tag with either optimizeQuality or -moz-crisp-edges. Also make sure that none of your drawImage calls are being done between pixels as this will cause the image to be interpolated and fuzzified. Always round your drawing coordinates.

    Im not saying there aren’t problems but with as much time as I’ve spent with writing a game engine for canvas, I’ve found more of ten than not that my problems tend to come from me missing something or relying on experimental behavior.(usually unknowingly).

  5. Todd says:

    Great post. It seems to be a typical response to HTML5 from game programmers – interest, frustration and eventual rejection if you are trying to do anything halfway complex.

    If you are looking at Lua, check out our open source Moai framework at getmoai.com

  6. Pingback: Response to: Why developing an HTML5 game is too damn risky

  7. Pingback: Why developing an HTML5 game is too risky - Monday By Noon

  8. Pingback: Why developing an HTML5 game is too damn risky | ektomarch. | Php App Engine

  9. Pingback: Why developing an HTML5 game is too damn risky | HTML5 Game Development

  10. jim says:

    So I’m guessing you don’t have any tests for your code?

    Why build your game to the latest version of Chrome, how does that make sense?

    Sorry but you sound like you don’t know what your doing and whining that your stuff is borked, look at your own dev process first.

  11. fiblye says:

    @ Jim
    I do, and I’m not “building for” the latest version of Chrome–I use the beta so that I know what possible issues I may face and have time to handle them. If something makes it through the beta and into the final release, it will never be a surprise for me.

  12. jim says:

    So regressions in Chrome beta are causing you all these problems?

    I really think you should just leave the beta alone and focus on your game, and don’t try and use the latest unstable features. Your just making work for yourself worrying about the wrong thing, focusing on the bleeding edge of a single browser isn’t the way forward, focusing on whats available now on all browsers seems more productive. This isn’t limited to HTML5, same on all multi OEM platforms.

    Look forward to seeing your finished game.

  13. Wan says:

    It’s an interesting article, but I prefer Louis Stowasser’s conclusion much more.

    Plus, this kind of problems is a major reason in the favor of using game frameworks: when dealing with the web, frameworks are not only here to provide features, but also ensure that your work will be compatible with most browsers.

    Given how HTML5 implementations are subject to changes, it’s the job of the framework developers to make sure they are able to quickly update if something is broken. So, if feel like it’s impossible to make consistent-enough games with HTML5, your conclusion should rather be “HTML5 game frameworks are not mature enough yet”, or “HTML5 implementations change too fast for frameworks to stay up-to-date”. But I don’t think either is true… as long as you don’t want to support beta browsers.

  14. dany69burton says:

    You sound like a very bothered young man. Why don’t you stop using the beta version of chrome if it keeps wrecking your stuff?

  15. fiblye says:

    HTML5 and Javascript were very different back then and there really wasn’t much of a standard implementation. Even testing it on stable versions it had unexplainable issues that would go away with the next version, and even to this day I’ll do an occasional test of Subbania and come across very strange issues that were never present before. For example, about a year ago there was extensive sprite flickering in the game, but I didn’t notice any last week.

    And I’m not bothered anymore. 🙂 I’ve learned that developing games in such a volatile environment isn’t a good idea. I switched to Lua like I’d planned and life’s been good ever since.

Leave a Reply

Your email address will not be published. Required fields are marked *