Gaming in HTML5: the future is now
scirra.com
scirra.com
With WebGL, the performance seems great, and the graphics and effects look sharp too. Audio was definitely an issue, and more work needs to be done there by browser makers. Using WebkitRequestAnimationFrame over setTimeout helps battery life and performance a lot.
If you're interested, you can check it out here – http://chrome.bouncymousegame.com/ – I'm thinking about doing a post about our experiences making this game for mobile and for web, and some of the economics behind game-making as well.
There were a few things that were working in Chrome only when this was coded. For example, Opera stable didn't have WebGL support at the time. But, in general it works great on Firefox too. When my colleague is back from vacation, we'll get it working on all the browsers (except IE, since there's no WebGL support there). Thanks for the comments too!
Flash's decision to drop mobile is probably because they're focusing more on Flash 11 and Molehill.
Mobile hardware is likely to keep getting better, but it's not magically going to make HTML5 games run well on mobiles. For that to happen, a few things are needed:
Magical improvements in JS runtime performance to bring JavaScript closer to native languages. You can at least count on JavaScript to continue getting faster, but there may be a wall somewhere. You may also have to rewrite your JavaScript to use new features and libraries to approach native performance, which isn't free.
Reductions to the amount of work mobile JS runtimes need to do. Right now all the JS for your HTML5 game has to be loaded, parsed and compiled on every run, and doing that is pretty slow on a mobile CPU.
JavaScript and related libraries (like WebGL and Canvas) need to provide good support for concurrency so that you can utilize the multiple cores available on bleeding-edge mobile devices. Clock speeds on individual cores of mobile devices are not likely to reach desktop heights and if you look at desktop trends, even if they do, they won't ever get much higher. Right now, you've got web workers, but they're too limited to be of much use in games (especially if you care about power consumption).
Improvements to power consumption in mobile HTML5 implementations. Even if you can barely hit 60FPS with your pure-javascript algorithm in a mobile browser, it's going to drain your battery a lot faster than a native app that's running 5x faster and letting the CPU/GPU sit idle when they have no work to do.
Your demo asteroids game certainly doesn't, but what about a 2D game that's actually worth playing? Things like physics or flocking algorithms are going to be very expensive in JS.
Google's really put work into making javascript perform as well as possible, and it shows.
Unlike desktop where you have the option of just installing another browser, aren't you locked into the installed JS engine on both iOS and WP7? I'm not sure about Andriod.
It's not that you can't steal games from other platforms, it's just that targeting HTML5 makes it ridiculously easy. I think the web being "open" is a great thing, but obviously it's a genuine concern for people who distribute games. There's already a big problem in the Flash circles of strange Chinese portals stealing a game and sticking their logo on it.
It's not just about the code, either - all the assets (images, sound) pretty much have to be readily available in an unobfuscated format.
Theft of assets is definitely an issue. We've actually been targeted ourselves by someone stealing and reselling our product. It's a pretty upsetting and difficult situation so we sympathise with the concerns.
What we learnt from our experience however is the thief was largely incompetent and didn't actually pose as much of a risk as we thought he would to our operations.
I think often the same can apply for theft of assets, it's upsetting that someone steals in in one swoop without any thought and appears to be making money from it, but most of the time they are struggling to make anything at all from your work. If someone more successfully is stealing from you there are a lot of options to take it further if it becomes economically viable. For the majority of developers though I don't think it's as big a concern as many people think it is. Although I'm sure there are some good counter examples and arguments against this.
Have you ever tried to reverse engineer/figure out the details of any of google's compiled javascript?
It's pretty damn obtuse.
On the other hand, since you're using HTML5, it's not too hard to make your product a service. When you do that, you can hide all your important code on the server instead of the client and thus make it much harder to steal. Of course, that makes it much harder to play said games on a mobile...
That, alone, is not really an issue. I suppose you could do the same as native games. If a demand is there, an API or libraries to do that will appear.
The source problem seems harder to change, short of rolling your own javascript VM and precompiling everything. And if the source is readable, the "obscure file format" technique breaks down.
In practice, though, can someone make something out of loads of minified javascript ? Or is it equivalent to reading deassembled C ?
How do you propose to obfuscate images and audio in a way that's going to work across all browsers and can't be easily circumvented (and it obviously can't be security through obscurity if it's to be used by more than one game).
> In practice, though, can someone make something out of loads of minified javascript ? Or is it equivalent to reading deassembled C ?
Minified Javascript would be very easy (unless the minifier renamed everything, but even that isn't too bad). Javascript compiled with something like Google's Closure Compiler would be a lot harder, but still a lot easier than disassembled C.
The assets are much more of a problem than the code - although not being able to compile the code means if you do find a way to obfuscate the assets, your deobfuscation code is going to be out in the open.
Of course, that's assuming there aren't any javascript-on-the-phone performance enhancements to be had. Also, it's assuming apple will someday open up webgl on the phone.