

Why developing an HTML5 game is too damn risky - fiblye
http://ektomarch.com/blog/?p=36

======
ntkachov
>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.

~~~
fiblye
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. ;)

------
robterrell
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.

------
hyperturtle
Maybe you can try to library for sound. SoundManager 2 does html5 sound and
falls back to flash. <http://www.schillmania.com/projects/soundmanager2/>

Apparantly there are issues with looping
(<http://www.schillmania.com/projects/soundmanager2/demo/api/>) but it points
to (<http://www.flickr.com/photos/schill/4499319436/>) as a way to fix sound
loops.

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.

------
azakai
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.

------
AshleysBrain
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.

~~~
bradford
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?

------
freedrull
Uh yeah, of course html5 sound is awful. I'm hoping projects like
areweplayingyet.org will gain traction to help solve this.

------
lord2800
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.

~~~
esrauch
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.

~~~
lord2800
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.

~~~
esrauch
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.

~~~
lord2800
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.

~~~
esrauch
> Historical issues for who, exactly?

Historical issues for developers like me.

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.

------
lukifer
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.

------
T_S_
Surprising conclusion at the end: "I’ll consider development in Lua in the
future." Interesting.

