>And what about those people that use the beta (e.g., me) and see the bugs and glitches as a result of your incompetence?
This line discredited the whole article for me. Firstly, you're writing a video game inside a browser. This is like making a space ship that does surgery. You've got two complex systems working together of course there will be bugs.
Also why on earth would you expect the browser to play the game exactly the same over the course of time. Every update to iOS or android introduces new bugs into the system. I don't understand where you come of saying that an update should never break anything ever.
Canvas is massively different across browsers. Its your job to figure out the difference and account for it. The spec isn't even finalized yet.
I honestly expected the author to touch on some important issues like the fact that your game is naturally open source. But this seems more like a frustrated developer expecting too much from a platform.
Honestly, people "stealing" my source code isn't that much of a worry for me. People already have ten million dollar games cracked and distributed before they're released, and honestly, I don't think somebody taking my code would change much. If they try redistributing it, I still have legal rights to it whether or not they got uncompiled code.
My biggest problem is that you can have a completely working project that's literally broken overnight with a silent update. Operating system updates generally require the user to knowingly upgrade and there's always the implied risk of something strange happening. Developers can easily publicly announce incompatibilities with certain OS updates on their download page to warn new users, while an HTML5 game requires you to test every single release of every browser ever, and since everybody uses a slightly different version of a slightly different browser, it only takes one glitch for one person for your entire market to be scared off.
I never said I didn't anticipate things going wrong, but that when things do go wrong, it can completely out of control in the browser world. My development of games in HTML5/Javascript has been 98% pure bliss, but the thought of a single dangerous bug making it past the testing phase gives me nightmares. I knew what I was getting into and it was primarily a test of "can I do it?", but it doesn't mean I can't complain. ;)
> I honestly expected the author to touch on some important issues like the fact that your game is naturally open source.
Small correction, your source is readable, but it isn't "open source" - "open source" means available under and open source license (which your code is not, unless you actually do that).
Your source also doesn't need to be readable - you can obfuscate it, to the point where it is as readable as native binaries - disassembleable in theory, but only by experts.
Been there, it's no fun. I spent last year making an HTML5 game. On the day we delivered the final beta, a silent Chrome update caused an error and all of our sprites started losing their z-index and thus flickering like mad. But only in Chrome, in the newly released version. I had to tell the publisher to use Safari or Firefox while we figured it out... Which was not what they wanted to hear.
That said, I enjoy developing for the platform and think the huge benefit in audience size for social games makes life on the bleeding edge worth the pain. These are the early days. It'll settle down.
Regarding other technical problems: I've had that issue too with Chrome beta, using csstransforms caused my textboxes to be unclickable(but still tab-able). My solution was to downgrade to the normal Chrome version and hoped it'll be fixed by the time it hit stable.
Chrome has bugs and so do all the other browsers - not sure it is fair to single it out here in this post.
Overall, sure, browsers have bugs and it is a tricky platform because of that. But, it also reaches far more people than any other platform. That's a tradeoff, if it makes sense for you, make a game for it, if not then don't.
Just a heads up, look in to using the Web Audio API on Chrome instead of the <audio> tag. It's far better and pretty bulletproof in my experience, if missing one or two features <audio> had.
I haven't heard of the Web Audio API, so forgive me if this sounds ignorant, but isn't this the kind of thing that should piss off anyone who's interested in consistent web-standards across all browsers?
Aren't browser specific API's the kind of thing that led to IE becoming such a hated piece of software?
These all sound like problems that can occur on any system, let alone browser-based, html5/javascript games (and often do occur in cross-platform games). I fail to see a problem here.
DISCLAIMER: I work for an html5/javascript gaming company.
That is clearly not true, when does a game that worked one day to stop working the next day on for any native desktop program, or on a mobile or console platform?
The only conceivable time that I could imagine it happening is when my phone does a major version update, which happens a maximum of once in the entire phone's lifetime, is very visible to me (it would be clear to me that it isn't completely the developer's fault), meanwhile chrome updates every week silently. If any website works one day and not the next I would always assume the developers had pushed a bad build.
How about when an OS ships an update? A library you're using (you didn't write that whole audio and gfx layer yourself, did you?) ships an update? A crippling bug gets exposed in some API you use? This is by and large not the first time we've run into problems like this before--is the Internet's memory so short that DLL Hell is a forgotten concept? Any time you rely on any third-party code anywhere you run the risk of something working one day and not the next, just by virtue of an update.
You explicitly are talking about historical issues which are mostly resolved. When you deploy an application that uses Direct X you target exactly one version, and you will never be using a different version of it unless you as the developer choose for it to happen.
OS shipping updates causing games to break is a pretty rare thing, several orders of magnitude less likely to occur than a browser shipping with a change in behavior of an HTML5 feature.
The risk clearly does exist everywhere, but its mostly a solved problem on Windows, and it's certainly a solved problem on Xbox. It's a monthly issue in browsers.
Historical issues for who, exactly? The way it was solved was to keep a copy of every DLL ever released on your system--I don't exactly call that solved; it's more like treating a cold with medicine that stops you from coughing (you're no longer coughing, but you're still sick). You can't really expect to use that solution for all possible situations.
It's absolutely unacceptable to keep around support for every version of HTML and JavaScript and CSS ever, especially when some of the versions are contradictory. The real solution is to make a clean break, learn from your mistakes, and do it better the second time around. Unfortunately, that means losing a lot of content if you can't automatically update it to new formats.
As for being a solved problem on one specific and unchanging platform, that's like saying networking is a solved problem so long as you stick to TCP/IPv4 and never have more nodes than you can have addresses. That's not a solution, it's a cop-out. Requirements change, specifications change, and most certainly, performance characteristics change.
As for being a solved problem on windows, the solution is just as bad as the problem--the difference is where the pain point lies. On my w7x64 machine, the windows folder takes up somewhere around 15gb of space (I don't have it handy to check the exact amount). That is absolutely unacceptable for an OS without any applications installed.
As for being a "monthly" issue for browsers, how frequently do you think it was an issue for major OS vendors until the specifications were finally more-or-less set in stone? Because I assure you, it did not happen overnight.
You are literally describing a solution, it might be a solution that you don't like but it is a solution that makes it so developers don't have to worry about random things breaking for no reason. AFAIK the solution is to have the applications install the version of the dll that they use, if Windows is 15gb with no applications (which seems like an exaggeration to me) then I think that is largely incidental.
> for major OS vendors until the specifications were finally more-or-less set in stone
Again explicitly invoking historical events.
> It's absolutely unacceptable to keep around support for every version of HTML and JavaScript and CSS ever, especially when some of the versions are contradictory
That is totally fine, but it makes browsers something that no developer other than bleeding edge early adopters and crappy social media game developers can reasonably support.
No one cares if they are as painful as desktop development was 15 years ago, developing for 1997 desktops isn't an option today, my entire point is that developing games on the web today are like developing games in 1997 which is awful. In 1997 you had no other choice; the options are any of a dozen mature platforms (desktop, mobile apps, consoles, handhelds) or else trying to juggle about 6 wildly incompatible and buggy browser environments where all of them are either too old to even support features that you want, or else a moving target that is changing literally every week in a way that is transparent to the user, which means you get blamed for the breakage when you could have done nothing to avoid it.
Isn't this true of any platform? Apple can (and does) pull the rug out at any time. Microsoft has a history of being responsive to devs, but they're certainly not immune from bugs. And Linux and Android are so fragmented in hardware and software, that all bets are off when it comes to user experience. (I'm aware that this is a sweeping generalization.)
Ultimately you have to factor in not only the quality of the platform, but also the responsiveness of the company and devs who maintain the platform. And the good news is, Google and Mozilla are usually pretty responsive. But platforms have to move slow to prevent destabilizing their other citizens, and sometimes your project gets caught in the middle. So it goes.
This line discredited the whole article for me. Firstly, you're writing a video game inside a browser. This is like making a space ship that does surgery. You've got two complex systems working together of course there will be bugs.
Also why on earth would you expect the browser to play the game exactly the same over the course of time. Every update to iOS or android introduces new bugs into the system. I don't understand where you come of saying that an update should never break anything ever.
Canvas is massively different across browsers. Its your job to figure out the difference and account for it. The spec isn't even finalized yet.
I honestly expected the author to touch on some important issues like the fact that your game is naturally open source. But this seems more like a frustrated developer expecting too much from a platform.