

Gaming in HTML5: the future is now - AshleysBrain
http://www.scirra.com/blog/56/html5-gaming-the-future-is-now

======
eabandit
We ported our 2D Android/iOS game, "Bouncy Mouse," to HTML5/WebGL. It's on the
Chrome Web Store
([https://chrome.google.com/webstore/detail/cgdllcbmneiklcmbec...](https://chrome.google.com/webstore/detail/cgdllcbmneiklcmbeclfegccdjholomb))
and doing great.

With WebGL, the performance seems great, and the graphics and effects look
sharp too. Audio was definitely an issue, and more work needs to be done there
by browser makers. Using WebkitRequestAnimationFrame over setTimeout helps
battery life and performance a lot.

If you're interested, you can check it out here –
<http://chrome.bouncymousegame.com/> – I'm thinking about doing a post about
our experiences making this game for mobile and for web, and some of the
economics behind game-making as well.

~~~
superted
Excellent stuff, my kids simply loved this game! Looking forward to the blog
post.

~~~
eabandit
Thanks! Guess we should work on a post, then. :)

------
Egregore
Google Chrome is available on almost all platforms, so if there is a good
HTML5 game optimized for Chrome, people will install Chrome browser to play
it.

~~~
noduerme
Funny, that's pretty much what they said about Flash.

~~~
Egregore
There are 3 competing browsers, which will press Chrome to be in shape, flesh
was a monopoly.

------
anotherthrwaway
HTML and JavaScript are a real step backward for getting games into the
browser. Instead of having a bytecode (or virtualisation of machine code) that
is designed for efficiency we get big APIs to do specific things thrown into
the browser. Then everyone gets excited because the browser can finally do
what the desktop has been able to do for years (without all the ludicrous
overhead). But what about the applications that need raw CPU power? There's an
unimaginative attitude these days that says that because we can implement some
obvious-in-retrospect demo (like all these games are) that there's no need for
efficiency. The design of the browser does a real disservice to programming.

------
kin
I wouldn't say the entire industry is heading for HTML5. Yes, it is very
capable, but, check out this demo: <http://molehill.zombietycoon.com/>

Flash's decision to drop mobile is probably because they're focusing more on
Flash 11 and Molehill.

~~~
noduerme
Agreed. And Molehill will be powering a majority of iOS games lonnnnng before
WebGL games are playable in Safari.

------
Jyaif
and goodbye battery life. Even the simplest HTML5 game find a way to use 90%
of my CPU.

~~~
AshleysBrain
That's because many mobile browsers aren't optimised yet - I think that will
be solved with time.

~~~
kevingadd
I question whether it's really a matter of optimization. Even on the best
modern desktop browser with the most modern JS runtime, JavaScript is going to
run 5-10x slower than C. On top of that, consider increases in memory usage.

Mobile hardware is likely to keep getting better, but it's not magically going
to make HTML5 games run well on mobiles. For that to happen, a few things are
needed:

Magical improvements in JS runtime performance to bring JavaScript closer to
native languages. You can at least count on JavaScript to continue getting
faster, but there may be a wall somewhere. You may also have to rewrite your
JavaScript to use new features and libraries to approach native performance,
which isn't free.

Reductions to the amount of work mobile JS runtimes need to do. Right now all
the JS for your HTML5 game has to be loaded, parsed and compiled on every run,
and doing that is pretty slow on a mobile CPU.

JavaScript and related libraries (like WebGL and Canvas) need to provide good
support for concurrency so that you can utilize the multiple cores available
on bleeding-edge mobile devices. Clock speeds on individual cores of mobile
devices are not likely to reach desktop heights and if you look at desktop
trends, even if they do, they won't ever get much higher. Right now, you've
got web workers, but they're too limited to be of much use in games
(especially if you care about power consumption).

Improvements to power consumption in mobile HTML5 implementations. Even if you
can barely hit 60FPS with your pure-javascript algorithm in a mobile browser,
it's going to drain your battery a lot faster than a native app that's running
5x faster and letting the CPU/GPU sit idle when they have no work to do.

~~~
AshleysBrain
Yeah, some good points I guess. But the fact we make an engine lots of games
use makes it a bit easier: if magical improvements in JS appear which require
some tricky changes to take advantage of, we can do the hard work in our
engine and all the games benefit from it. But yeah, probably will always be a
bit slower. 2D games don't tend to have really complicated logic though.

~~~
udp
> 2D games don't tend to have really complicated logic though.

Your demo asteroids game certainly doesn't, but what about a 2D game that's
actually worth playing? Things like physics or flocking algorithms are going
to be very expensive in JS.

~~~
AshleysBrain
You're right physics uses a lot of CPU, but I don't think games not using
physics are automatically not worth playing. Did you see this platformer?
<http://news.ycombinator.com/item?id=3192719>

~~~
udp
I don't think presenting a retro platformer (which, FWIW, crawls here in FF 8)
really argues your case much. Why should developers go back to making simpler
games to get adequate HTML5 performance when they could develop directly for
the target platform and use the hardware to its full potential?

------
pedalpete
The article states that 'mobile browsers will catch up', but isn't this one of
the areas where the OS creators are have a disincentive to improve the gaming
ability of their browsers.

Unlike desktop where you have the option of just installing another browser,
aren't you locked into the installed JS engine on both iOS and WP7? I'm not
sure about Andriod.

------
ntkachov
The problem with HTML5 games is that the game's source code is on your machine
which means DRM is gone. Not only that but the problem for me is that my
assets and my source is freely available to you to use in any way you want.
You can take it and rehost it on your website and I lose any way of making a
profit off my game.

~~~
TomGullen
I don't buy this to be honest, what's stopping you from stealing from any
other game? Why have you singled out HTML5 as exclusively suffering from this
problem?

~~~
udp
Well, because the web, by nature, is _open_. Javascript is source, not some
kind of bytecode. You can easily look at the source of any web page and do
whatever you want with it (granted there are obfuscators available, but run it
through a tidier and it's at least easier to work with than assembler would
be).

It's not that you can't steal games from other platforms, it's just that
targeting HTML5 makes it ridiculously easy. I think the web being "open" is a
great thing, but obviously it's a genuine concern for people who distribute
games. There's already a big problem in the Flash circles of strange Chinese
portals stealing a game and sticking their logo on it.

It's not just about the code, either - all the assets (images, sound) pretty
much have to be readily available in an unobfuscated format.

~~~
TomGullen
I think you can argue that this is largely offset by the opportunity the web
as a platform can offer you and your games.

Theft of assets is definitely an issue. We've actually been targeted ourselves
by someone stealing and reselling our product. It's a pretty upsetting and
difficult situation so we sympathise with the concerns.

What we learnt from our experience however is the thief was largely
incompetent and didn't actually pose as much of a risk as we thought he would
to our operations.

I think often the same can apply for theft of assets, it's upsetting that
someone steals in in one swoop without any thought and appears to be making
money from it, but most of the time they are struggling to make anything at
all from your work. If someone more successfully is stealing from you there
are a lot of options to take it further if it becomes economically viable. For
the majority of developers though I don't think it's as big a concern as many
people think it is. Although I'm sure there are some good counter examples and
arguments against this.

------
jiggy2011
Is it just me or are we now basically at the stage we were with java applets
about 12 years ago?

~~~
anotherthrwaway
Yes, but no UDP sockets, which are absolutely essential for multiplayer games.
It's ludicrous that a modern networking platform can forgo this essential
component.

------
kevingadd
Google sure is good at guiding the conversation on these APIs. It used to be
that everyone complained about Chrome's piss-poor audio implementation, but
now people are complaining that Microsoft and Mozilla are 'slow to support'
the Web Audio API 'standard' even though it looks like Google documenting
their NIH mixer library after the fact instead of an actual market-driven
standards effort.

~~~
AshleysBrain
You're right, Web Audio API isn't standard yet - edited the post to clarify.

------
noduerme
To summarize: Here's a game that doesn't work on mobiles, doesn't work in IE
or Firefox or any version of Chrome less than 15. Now that Adobe has caved to
the various walled-garden app stores and given up hope for a share of the
casual games mobile market, game developers will be stuck with our spaghetti
Javascript and browser idiosyncrasies for the next decade or until the
standards agency manages to raise Jesus and tie its shoes at the same time. So
suck it up and deal with the fact that OO code and multi-platform development
are dead, and we're so cool because we made a game in 3D that can almost be
played at 2 FPS on a phone browser (but we'll let someone else figure out how
to make phones 15x faster... it's right around the corner!)

~~~
extension
And even when phones are 15x faster, people will expect games to be 15x
prettier. Mobile browser games may one day carve out a low-tech niche of
sorts, similar to how Flash games have carved a niche on the desktop, but they
are never going to be in the same category as native games.

~~~
noduerme
Of course. By definition, they can't be. But JS games also will always be a
class below Flash games, because the language is sloppy and completely
interpreted at runtime. The fact that people think it'll be a replacement just
shows how much money computer-illiterate business school graduates living with
their parents in Bel Air still have to throw around, taking power lunches and
acting like they have a freakin clue what they're talking about. I've been
working for these types of people since "Bel Air" was "Oakland Hills", "HTML5"
was "E-commerce", and IE 3 didn't play nicely with Netscape. But the smell of
bullshit hype stay the same.

