austinhallock's comments

We have it for recommending games on http://clay.io. Opted to just use the easy-deploy version on AWS: https://aws.amazon.com/marketplace/pp/B00ECGJYGE

It was pretty straight-forward to implement and has a nifty backend to it as well for managing the algorithms.

Interesting side note is Jack made the game for the js13kGames competition (and won). The entire codebase is less than 13kb compressed.

He won last year with http://spacepi.clay.io

Also http://html5gameengine.com if you're looking for a list of engines. It's limited to the more popular, actively maintained engines and has reviews, links, etc... for each.

This comment is a bit off topic as the post isn't about Clay.io, rather games in general.

However, to answer your question, we take a 20% cut on any transactions made through selling games or our in-game payments API. If you're using our Advertising API we take 10-30% (depending on where the game is being played). Everything else (leaderboards, achievements, etc...) is free to use. This info is displayed here: http://clay.io/docs

The point I'm trying to make there is consumers can still find your game through those apps like WeChat, and through shared links on Facebook, Twitter, etc... The same way people typically find and consume other forms of content.

What needs some work is making those games stickier in the sense that the person will play it again. That requires saving it to the home screen which probably not enough people are familiar with - and is a bit of a pain on Android.

I like the approach Firefox OS has taken with saving/installing apps and hopefully Apple and Google follow suit. As is, I think iOS's "Add to Home Screen" is fine. Android's like I said, could be improved.

The other thing that needs a bit of work is HTML5 performance in the webview. On iOS at least, game's don't perform as well as when they are played in Safari (since the webview doesn't use the Nitro JS engine) - hopefully that changes soon.

You had me at Hello. Actually, you had me at the loading screen - so clean and slick.

Done

Done - should work now. Ex. http://html5gameengine.com/details/4

Added :)

That info is in the "More Details" section. With that said, do you still think it should go in the main table? Was trying to keep it from being too cluttered.

Did you by chance open it up while the browser window was small, then resize the window?

I would be lying if I said that's not a small part of it, because it is.

But what's much more important to us is having HTML5 games in general move forward, and that starts by getting more folks (especially students) developing games with the technology versus Flash or Unity. If HTML5 "fails" for games, Clay.io no longer exists.

We gathered as much as we could for prizes, but the main issue was with securing more sponsors. Clay.io in its current state is 3 undergraduates at the University of Texas - we don't have funding at this point, so we have to be a bit scrappy.

Not for building the games themselves, but Clay.io hopefully won't drive you nuts on the higher level features like user accounts, leaderboards, achievements, payments, etc...

http://clay.io/docs

From the studios I've spoken with, the big reason is they don't see the reward as higher than the risk, so they opt to use Unity instead. One hit HTML5 game and this could all change - that just hasn't happened yet.

That's just the demo game I had to work with (given the time restraint of the PennApps hackathon), unfortunately it performs slow on iPhones and iPads. That demo game was made with Construct 2, a drag-and-drop game engine - they do make an effort for performance, but as shown by this game, it's a difficult task with all the additional bloat of that type of game engine.

The controller library itself has good performance on iOS since that's obviously one of the main targets of something like this.

This was me taking a game that completely didn't work on touch devices, and making it work - hence the "Spacebar to start". That functionality was mapped to the "B" key. I'll add that note into the documentation, thanks for pointing it out!

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

Good idea, done! Thanks for the feedback :)

Another option: http://johndavidfive.com/inpoot/

Here's a demo video: http://www.youtube.com/watch?v=6oBf-Rlm5_Y

This is true. I do think there is value in taking a less is more approach however.

Maybe I'm weird, but http://grab.by/dXiq just seems overwhelming to me and is a turn-off.

Also, as far as I know, OpenID 2.0 doesn't pass the username/name/picture (correct me if I'm wrong), so there is some extra work involved in getting that info from each individual provider (assuming they even provide it like Google does)

Interesting, thanks for the info! Big difference between http://grab.by/dXi6 and http://grab.by/dXia in terms of how much focus is put on Facebook, but that plays a bigger role than I'd imagine (24% -> 70%). Of course, the audiences are a bit different as well