The Future of Games on the Web

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 (<a href="http://www.beautyoftheweb.com/touchgallery#/contrejour" rel="nofollow">http://www.beautyoftheweb.com/touchgallery#/contrejour</a>). 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.<p>This is beginning to feel like a ritual HN ceremony!<p>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.

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.<p>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.<p>Of course by providing an installer for popular OSs that just fires up chrome in fullscreen mode could easily solve this problem.<p>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.

The author forgot one of the greatest and multiplatform frameworks: Cocos2D for HTML5[1] and Cocos2D with Javascript bindings [2]<p>[1] <a href="http://www.cocos2d-iphone.org/t/js-tests/tests/" rel="nofollow">http://www.cocos2d-iphone.org/t/js-tests/tests/</a><p>[2] <a href="https://github.com/zynga/jsbindings#readme" rel="nofollow">https://github.com/zynga/jsbindings#readme</a>

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

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].<p>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.<p>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]<p>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].<p>[1] <a href="http://clay.io/home" rel="nofollow">http://clay.io/home</a> [2] <a href="http://clay.io/docs/data" rel="nofollow">http://clay.io/docs/data</a>

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.<p>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.<p>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.<p>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 ?<p>A second question will be how can you make money from a game that can be easily copied ?

no. the future is cloud gaming, like Gaikai.

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.<p>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.<p>- 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.<p>So yep , it's proprietary , but i chose ease of dev , deployement and fast dev cycles over theorical open-ness and awesomeness.