
The Future of Games on the Web - robhawkes
http://12devsofxmas.co.uk/post/2012-12-26-day-1-the-future-of-games-on-the-web
======
xiaoma
This is the third holiday season in a row I've seen blog posts about the
future of games on the web on HN that effectively ignore flash. Each year,
flash portals such as Kongregate.com have grown into even larger juggernauts,
even growing on a percentage basis on Alexa
(<http://www.beautyoftheweb.com/touchgallery#/contrejour>). And each year,
I've seen various examples of "incredible" html5 games put forward that would
have difficulties even getting 3.5 stars out of 5 on kong or newgrounds.

This is beginning to feel like a ritual HN ceremony!

That isn't to say, JS-based games aren't progressing. They are for sure. Most
notably on a platform the article didn't mention-- facebook.

~~~
kevingadd
We recently launched a HTML5 port of a console/pc game
(<http://www.newgrounds.com/portal/view/606067>) on Newgrounds and it was
interesting to compare/contrast with the experiences my friends have had
launching their Flash games.

There's a huge amount of inertia to overcome - lots of people with old
browsers unwilling to upgrade, old computers that simply can't run games, and
incredibly broken configurations (whether due to bad browsers, bad plugins or
bad drivers) where simple HTML5 audio/rendering can crash the browser or
reboot the machine. When we first put it up we got lots of complaints and our
average review was closer to 3 stars, despite doing tons of testing up-front;
eventually by sorting through the issues one by one we got it to the 4 stars
you see now. Despite this, Flash games of comparable quality get higher
scores, more views, and more revenue (nobody is willing to pay to show ads in
HTML5 games; for Flash games there are entire ad networks).

So I guess what I'm saying is that you're mostly right.

On the other hand, a few people I know who make a living off flash games have
said that sponsorships are fewer and further between now, and that ad revenue
is decreasing. I don't know whether this represents an overall decrease in the
value of in-game ads, or whether Flash's reach is diminishing.

~~~
xiaoma
The big money is definitely in in-game consumables and virtual goods now. I'd
say add revenue has probably been declining every year since at least 2007,
but a top 100 game earns far more now than in the past.

This talk was pretty enlightening: <http://youtu.be/Ekz466sDprg>

------
jiggy2011
I think the issue (as touched on in the article) is that devs don't want to
make "browser games" so much as they want to make games. The main advantage of
being able to render within a browser window would be to provide a quick
playable demo. When you play an imersive game you want the whole screen
because it is taking your full attention.

When it comes to games I'd prefer just to manage everything within Steam or
via desktop shortcuts, whether it is written in C++ , C# or JS is an
irrelevant implementation detail for the player.

Of course by providing an installer for popular OSs that just fires up chrome
in fullscreen mode could easily solve this problem.

Another (possible) issue is that most game devs like to keep their source
private and include DRM. JS doesn't lend itself so well to that type of
approach.

~~~
debacle
It's very easy to create a game that runs on the JVM, and because of the
library maturity, after a very early point it becomes easier to continue in
the JVM.

~~~
jiggy2011
I would guess that JS runs on more platforms than the JVM, especially
including WinRT and iOS.

~~~
debacle
Well, yes. It's very likely that my TV's menu system is some variant of
JavaScript.

But the important things support the JVM.

~~~
jiggy2011
I don't think you have support for the JVM on ipads , Xbox360 or Windows RT
(so surface etc).

JS in theory at least should be supported on anything with a relatively modern
browser.

------
wslh
The author forgot one of the greatest and multiplatform frameworks: Cocos2D
for HTML5[1] and Cocos2D with Javascript bindings [2]

[1] <http://www.cocos2d-iphone.org/t/js-tests/tests/>

[2] <https://github.com/zynga/jsbindings#readme>

------
chill1
I like the concept of user generated content. I haven't been that into games
in a very long time at this point, but from what I remember of playing the few
MMORPG's that I did play, they always seemed to fall down when it came to
making the game world truly respond to user input. What I mean by this is,
what if the game world's state was as responsive to your input as say... a
forum, or blog comments section, or even a social website?

Well, anyways... I checked out the first game in the article's list of "great"
HTML5 games (Contre Jour: <http://www.contrejour.ie/#fbid=N0F1LHvfzzM>). It
was pretty good. Seemed to have relatively unique, interesting game mechanics,
nice visuals, and I liked the music.

~~~
RyanZAG
There are quite a few people working on the user-generated web game content -
me included! :) I'm putting together something of a rogue-like mmorpg with
players being the prime movers of the game world.

Article rang true for me, since it's exactly what I'm doing! Hyperlinks to
areas of the game world, RESTful API for directly accessing the game world,
client support from Android, etc. I also know of a few others doing similar
work, so I think web gaming has a pretty bright future.

~~~
malandrew
The idea of hyperlinks for games is pretty cool because it opens up
possibilities not previously (or at least often) considered.

One of my favorite real examples is Scott Schiller's use of hyperlinks in his
Survivor C64 game. He used hyperlinks to encode the entire level so you could
then tweet the levels you create via short URLs and others could take that
level, modify it and retweet it.

I'm curious if hyperlinks could even be used to create meta games. i.e.
everyone makes different versions (equivalent to add-on packs) for a base
game, where the hyperlink encodes the state of the current player and passes
that state along to another level of the game created by another player.

------
austinhallock
Great article Rob! We're trying to help games on the web progress towards a
few of those points you mentioned with Clay.io [1].

Using URLs to link to in-game content is an interesting idea, something I'll
play around with in the next few days and see about getting that as another
feature of our API.

Persistent data on all devices is fantastic - of course, we need more HTML5
games that work well on each device. The two main issues I've seen developers
run into with getting their games on mobile are 1) the performance in mobile
web browsers (the latest Safari is pretty good, but most games still have a
tough time) and 2) handling user input - developers are able to take full
advantage of a keyboard on desktops and limiting to touch is a big change
(though it seems a lot of devs forget about the accelerometer). If the
developer has tackled those issues, we're here with the data storage feature
of our API to allow for easy implementation of that idea. [2]

As for interacting with the DOM, it's funny you mention that, just yesterday
we updated our homepage to have a mini-game in it (calling it a game is a bit
of a stretch though) that interacts with the DOM [1].

[1] <http://clay.io/home> [2] <http://clay.io/docs/data>

------
Shorrock
As someone who has been working for the better part of 2 years on a browser-
based game, I hope your predictions come true. In particular I've found the
blending of what's expected in typical web-apps and how games function to bo
some of the more interesting benefits of approaching development from this
angle.

The ability to seamlessly persist game state across devices is a powerful
construct that really enables you to play everywhere. While being a simply
useful mechanism, it also really helps users stay mentally engaged in the game
experience if they can access it at any time. This fact builds upon itself if
they can do so in small bite-sized chunks.

Additionally, the ease of acquisition of such games (we're using a DOM based
approach, however, Canvas also applies here) is also a big win. We've seen our
game gain tremendous traction in various offices where people wouldn't
normally play games as you a) don't need to install anything and b) can play
in 30 second intervals.

These two unique factors combined gives you a devious means to provide
compelling game experiences regardless of where you and what type of computer
you have access to.

------
octopus
I'm really interested in how you can protect your game assets, in a HTML5
game, to be stollen by a competitor ?

A second question will be how can you make money from a game that can be
easily copied ?

~~~
kevingadd
You can't. The necessary security measures (obscene DRM, essentially) would
never make it into a web standard, and there are way too many side channels to
secure.

To deal with your game being easily copied you basically do what flash game
devs do: basic rehosting protections (stops the laziest pirates), partnerships
with advertisers, in app purchases/required server connections, etc.

------
stewie2
no. the future is cloud gaming, like Gaikai.

~~~
justjimmy
"The Future of Games on the Web"

Not

"The Future of Games is the Web"

*And from his article, I interpret Web as Web Browser.

~~~
stewie2
Gaikai is in browser cloud gaming. it's certainly the future of games on the
web!

------
camus
js/html games are a pain to develop. I can develop a game much faster with ,
flash yes , flash and i'm going to stick with that.

Assets are handled , sounds are handled and i dont need to test it on 4+
browsers to see if it works. I get a dynamic strong typed langage, a drawing
soft and an animation soft , which is all i need to develop complex games.

\- Do i care about mobile ? i can release my game as an native iOs app or air
packaged app for android, i get exposure through app stores and can use native
device capabilites to enhance user experience.

So yep , it's proprietary , but i chose ease of dev , deployement and fast dev
cycles over theorical open-ness and awesomeness.

~~~
scott_w
It's a matter of tooling. Flash is a mature technology for game development,
whereas JavaScript is quite new in that area.

However, I firmly believe that things are improving. Adobe are buying
companies that build HTML5 and JavaScript tools.

Web browser compatibility is an issue; however it remains a development issue.
Building separate applications for each platform brings in other issues, such
as app store rules and visibility. Granted, this is a trade-off.

~~~
camus
> Adobe are buying companies that build HTML5 and JavaScript tools.

which ones? you're talking about appstore rules but phonegap purpose is for a
js app to be deployed like a native app,out of the browser.

> visibility :

an app on the app store is more visible than any app on a web site on mobile.
I have no exemple of any profitable html5 game , on the other hand there are
plenty ( machinarium )exemples sucessfull of unity or flash games.

Things may be different in 5/10 years , but i code for now and with stable
technologies.

