Gaming in HTML5: the future is now(scirra.com)
scirra.com
Gaming in HTML5: the future is now
http://www.scirra.com/blog/56/html5-gaming-the-future-is-now
40 comments
Nice game! Runs smooth. Why do you reject non-Chrome browsers instead of doing feature detection?
No real reason. One man developer (who's on vacation right now), and we were heads down getting this to work on Chrome for a little under a month so he could make his vacation on time. :)
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!
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!
Google Chrome is available on almost all platforms, so if there is a good HTML5 game optimized for Chrome, people will install Chrome browser to play it.
HTML and JavaScript are a real step backward for getting games into the browser. Instead of having a bytecode (or virtualisation of machine code) that is designed for efficiency we get big APIs to do specific things thrown into the browser. Then everyone gets excited because the browser can finally do what the desktop has been able to do for years (without all the ludicrous overhead). But what about the applications that need raw CPU power? There's an unimaginative attitude these days that says that because we can implement some obvious-in-retrospect demo (like all these games are) that there's no need for efficiency. The design of the browser does a real disservice to programming.
I wouldn't say the entire industry is heading for HTML5. Yes, it is very capable, but, check out this demo: http://molehill.zombietycoon.com/
Flash's decision to drop mobile is probably because they're focusing more on Flash 11 and Molehill.
Flash's decision to drop mobile is probably because they're focusing more on Flash 11 and Molehill.
Agreed. And Molehill will be powering a majority of iOS games lonnnnng before WebGL games are playable in Safari.
and goodbye battery life.
Even the simplest HTML5 game find a way to use 90% of my CPU.
I've been working on an HTML5 game for a year (http://ektomarch.com/games) with Chrome as my primary development target. When it launched, I'd get about 1 hour of battery life on a full charge while testing. Now, however, I'm getting about 4 hours. Flash still brings my battery down to around 2 hours at max.
Google's really put work into making javascript perform as well as possible, and it shows.
Google's really put work into making javascript perform as well as possible, and it shows.
That's because many mobile browsers aren't optimised yet - I think that will be solved with time.
But I thought the future was now ;-)
I question whether it's really a matter of optimization. Even on the best modern desktop browser with the most modern JS runtime, JavaScript is going to run 5-10x slower than C. On top of that, consider increases in memory usage.
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.
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.
Yeah, some good points I guess. But the fact we make an engine lots of games use makes it a bit easier: if magical improvements in JS appear which require some tricky changes to take advantage of, we can do the hard work in our engine and all the games benefit from it. But yeah, probably will always be a bit slower. 2D games don't tend to have really complicated logic though.
> 2D games don't tend to have really complicated logic though.
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.
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.
Exactly. People think that because we can have some completely unimaginative stuff with ideas from the 1980's that HTML5 is ready to be the future of browser gaming. And then when presented with the problem of complex physics, the solution is of course to add a special extension to browsers to handle physics. It's no wonder the browser is decades behind the desktop with myopic thinking like this.
You're right physics uses a lot of CPU, but I don't think games not using physics are automatically not worth playing. Did you see this platformer? http://news.ycombinator.com/item?id=3192719
I don't think presenting a retro platformer (which, FWIW, crawls here in FF 8) really argues your case much. Why should developers go back to making simpler games to get adequate HTML5 performance when they could develop directly for the target platform and use the hardware to its full potential?
The article states that 'mobile browsers will catch up', but isn't this one of the areas where the OS creators are have a disincentive to improve the gaming ability of their browsers.
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.
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.
The problem with HTML5 games is that the game's source code is on your machine which means DRM is gone. Not only that but the problem for me is that my assets and my source is freely available to you to use in any way you want. You can take it and rehost it on your website and I lose any way of making a profit off my game.
I don't buy this to be honest, what's stopping you from stealing from any other game? Why have you singled out HTML5 as exclusively suffering from this problem?
Well, because the web, by nature, is open. Javascript is source, not some kind of bytecode. You can easily look at the source of any web page and do whatever you want with it (granted there are obfuscators available, but run it through a tidier and it's at least easier to work with than assembler would be).
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.
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.
I think you can argue that this is largely offset by the opportunity the web as a platform can offer you and your games.
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.
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.
>not some kind of bytecode
Have you ever tried to reverse engineer/figure out the details of any of google's compiled javascript?
It's pretty damn obtuse.
Have you ever tried to reverse engineer/figure out the details of any of google's compiled javascript?
It's pretty damn obtuse.
Other games tend to hide their assets into cryptic packages and file format (or they can even try to encrypt them). Not always impossible to bypass, but very annoying. It's a bit harder to do in html5, where you are supposed to use the standard formats for images/sounds, etc.
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 ?
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 ?
> 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.
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.
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.
Compiled code being decompiled and repurposed illegally is already a problem for people authoring software in Java, .NET and Flash. It would be dishonest to say that HTML5 won't suffer from this problem given that it makes it even easier to repurpose someone's hard work for your own ends.
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...
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...
Just want to throw in that our engine mangles the code with Google Closure Compiler 'advanced' mode, so it's probably really hard work to reverse engineer the code.
Is it just me or are we now basically at the stage we were with java applets about 12 years ago?
Yes, but no UDP sockets, which are absolutely essential for multiplayer games. It's ludicrous that a modern networking platform can forgo this essential component.
Google sure is good at guiding the conversation on these APIs. It used to be that everyone complained about Chrome's piss-poor audio implementation, but now people are complaining that Microsoft and Mozilla are 'slow to support' the Web Audio API 'standard' even though it looks like Google documenting their NIH mixer library after the fact instead of an actual market-driven standards effort.
You're right, Web Audio API isn't standard yet - edited the post to clarify.
To summarize: Here's a game that doesn't work on mobiles, doesn't work in IE or Firefox or any version of Chrome less than 15. Now that Adobe has caved to the various walled-garden app stores and given up hope for a share of the casual games mobile market, game developers will be stuck with our spaghetti Javascript and browser idiosyncrasies for the next decade or until the standards agency manages to raise Jesus and tie its shoes at the same time. So suck it up and deal with the fact that OO code and multi-platform development are dead, and we're so cool because we made a game in 3D that can almost be played at 2 FPS on a phone browser (but we'll let someone else figure out how to make phones 15x faster... it's right around the corner!)
And even when phones are 15x faster, people will expect games to be 15x prettier. Mobile browser games may one day carve out a low-tech niche of sorts, similar to how Flash games have carved a niche on the desktop, but they are never going to be in the same category as native games.
Of course. By definition, they can't be. But JS games also will always be a class below Flash games, because the language is sloppy and completely interpreted at runtime. The fact that people think it'll be a replacement just shows how much money computer-illiterate business school graduates living with their parents in Bel Air still have to throw around, taking power lunches and acting like they have a freakin clue what they're talking about. I've been working for these types of people since "Bel Air" was "Oakland Hills", "HTML5" was "E-commerce", and IE 3 didn't play nicely with Netscape. But the smell of bullshit hype stay the same.
So, since a a5's gpu is 7x better than an a4 (in one year) I'm thinking they'll be fast enough about the time user's 4s's contracts are up.
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.
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.
This is the wrong mindset. Just because you can implemented some specialised idea of video games that dates back more than a decade is nothing to be optimistic about. What about the next innovative idea? There are some things you need raw CPU power for.
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.