

Building Games for HTML5, Not with HTML5 - austinhallock
http://clay.io/blog/building-games-for-html5-not-with-html5/

======
willvarfar
I completely agree with this. Building HTML5 games - and you can get
competitive levels of graphics and so on - is a great way to be able to target
the Apple, Android and even the Chrome store. You can easily make a shim that
launches a WebView window.

It also allows for playing online as said.

WebWorkers, however annoying to debug, raise an interesting speed-bump to
cheating too. Here's a WebWorker wrapper script that lets you run (a single)
WebWorker in-process instead, for debuggability:
[https://github.com/williame/ludum_dare_27_snowden/blob/gh-
pa...](https://github.com/williame/ludum_dare_27_snowden/blob/gh-
pages/web_worker.js)

With the new Audio API and webRTC, plus the WebSockets, things are bright.

~~~
Kiro
How do people use Web Workers to prevent cheating? I would love to read more
about it.

~~~
willvarfar
Browsers run web workers in sandboxes and even normal debuggers built into
browsers have no visibility into them; this means fiddling around at the
JavaScript console is blind of any state you have in them e.g. a procedurally
generated world.

A determined attacker can debug the browser itself, or try and rewrite your
app to not use web workers, of course... Its just a speedbump. Its still
client side.

I use them - and try and work out how to debug them - for performance
smoothness reasons though. They are worth more for that imo and anti cheating
is very much a secondary thing.

Me getting down voted elsewhere for this opinion this week:
[http://www.reddit.com/r/programming/comments/1lnnvm/making_a...](http://www.reddit.com/r/programming/comments/1lnnvm/making_an_indie_desktop_game_part_i/cc10og6)

~~~
thorum
I wonder if Firebug & other tools will eventually support debugging web
workers, making this usefulness against cheating a temporary thing.

~~~
willvarfar
Yeah they soon will. Chrome is slightly ahead already.

I wish I hadn't said it noe; it was on the top of my mind, was all.

The much maligned web sockets are actually useful for keeping the game loop
light; I even generate meshes in them.

------
_random_
"Why write an iOS version of a game in Objective C, and the PC version in C?
Performance would be the only reason, but that’s becoming more and more of a
moot point."

Why indeed, when there is a multi-paradigm C# and MonoGame that give you a
combination of an actual modern language, decent performance and multi-
platform access.

------
hatu
"Your game doesn’t need to be in the iOS App Store or Google Play to be played
on mobile devices. That is a huge benefit. Sure, it’s good to have it in both
of those stores (and is easy enough to achieve), but the fact that it can be
played without requiring an install and the extra bulk of the stores is a big
opportunity."

I don't know if this is true though. Consumers expect the games to be in the
appstores. I don't know anyone who even knows they can play games on the phone
browser.

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

~~~
WayneDB
How would you feel about a "web games gallery" app in the store? It would just
be a catalog and launch the native browser to play games.

Do you think that would be a good idea for someone who wanted to evangelize
HTML as a games dev platform?

I'm not sure if it exists or if it would Apple's terms of service.

~~~
sirkneeland
or if it would ever be in Apple's interest to encourage the growth of cross-
platform ecosystems with no iOS lock-in.

(it's probably not)

------
commentzorro
Where's the pricing information. I hate it when a site hides it's pricing. My
immediate reaction is that it's too high. Then contact with the company to
find out is going to be fraught with listening to justification before I can
get prices and immediately rule them out as too high a percentage of expected
revenue.

~~~
austinhallock
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](http://clay.io/docs)

------
AndyKelley
Shameless plug - if you're looking to quickly prototype a 2D canvas-based
game, you might be interested in trying out my open source game engine.

[https://github.com/superjoe30/chem/](https://github.com/superjoe30/chem/)

------
junkilo
good article. haven't seen it mentioned before, so props to the author for
noticing that html5 is a distinct platform.

