Hacker News new | comments | show | ask | jobs | submit login
The Future of Games on the Web (12devsofxmas.co.uk)
42 points by robhawkes 1607 days ago | hide | past | web | 30 comments | favorite

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.

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.

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

Flash lost when Adobe gave up on mobile. There are going to be a billion tablets within a few years. What's more important is how rapidly these tablets are advancing.


Also, consider Firefox and Chrome get updated every 6 weeks; that's around 500-700 million users getting fresh updates. Sure, "HTML5", that catch-all buzzword, needs a bit more work before it can match the current Flash, but it's pretty clear where people should be placing their bets.

There are a ton of flash games on the app store. If anything, Adobe has a stronger presence in mobile with CS6 than it did before! You probably just don't realize it because flash compiles to "native" apps.

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.

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.

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

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

But the important things support the JVM.

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.

I think it is easy to under-estimate how much difference it makes when your game is on a URL and is running with now download and install.

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

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.

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.

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.

It's probably worth noting that Contre Jour was originally an iOS game. The HTML5 version is a port of the original. (Not to take anything away from it!)

It's also by far the best looking of the bunch!

Play A Tale in the Desert.

Most MMORPGs don't know how to handle user input because users are basically trained as destructor bots rampaging the landscape by the game itself, and the designers haven't figured out how to move away from that. ATiTD moved away from it successfully.

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

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.

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 ?

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.

You can't protect your assets in a Flash game either.

In general, your assets are only protected by copyright.

no. the future is cloud gaming, like Gaikai.

"The Future of Games on the Web"


"The Future of Games is the Web"

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

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

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.

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.

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

Agreed. The difficulty creating HTML5 apps is the reason they'll never be popular. (Unless this issue is addressed.)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact