HTML5 as a gaming platform(blog.avd.io)
blog.avd.io
HTML5 as a gaming platform
http://blog.avd.io/posts/html5-games
30 comments
Current mobile browsers, yes, very much so.
But I think Chrome for Android 4 (which I believe will replace stock Android browser eventually), IE10 for Windows 8 phones / tablets, and Firefox on B2G will change this. I've seen B2G already running mobile web games smoothly on Android hardware.
But I think Chrome for Android 4 (which I believe will replace stock Android browser eventually), IE10 for Windows 8 phones / tablets, and Firefox on B2G will change this. I've seen B2G already running mobile web games smoothly on Android hardware.
True enough, it will get better.
Old mobile browsers will be to html5 games what IE6 was to web devs.
Old mobile browsers will be to html5 games what IE6 was to web devs.
That's unlikely, mobile device lifecycles are way shorter than those of desktop computers. Even native game developers often don't target mobile devices that are outdated.
Many smartphone users are prevented from upgrading their firmware/OS. So even if the device lifecycles are shorter, developers cannot ignore legacy devices. If we look at the current Android stats for top entertainment app users:
Android 2.3.3+ = 50.79 % Android 2.2 = 23.87 % Android 2.1 = 7.22 % Android 4.0.3 = 1.42 %
As a developer, am I really going to only target my html5 or native app for 4.0.3?
p.s. Sorry for the delayed reply. :)
Android 2.3.3+ = 50.79 % Android 2.2 = 23.87 % Android 2.1 = 7.22 % Android 4.0.3 = 1.42 %
As a developer, am I really going to only target my html5 or native app for 4.0.3?
p.s. Sorry for the delayed reply. :)
I would bet on javascript games for 2 reasons:
1. In a short timeframe, tools that convert html 5/js code base to IOS and Android will be good enough for most of casual gameplay type (match 3, tower defense, one button gameplay, etc.).
2. The web will slowly move from a primary game consumption platform (billions of flash games being played every day!, thousands of small studios living from their flash work), to a marketing platform for mobile games.
With one html/js code base, small indies will be able to push instantly to the web and app stores. They will keep selling sponsorship of theirs games to portals like kongregate and armorgames on the web, get their games expose to millions of visitors, build an audience and promote their app store offering in the meantime.
Win win for portals and game developers.
1. In a short timeframe, tools that convert html 5/js code base to IOS and Android will be good enough for most of casual gameplay type (match 3, tower defense, one button gameplay, etc.).
2. The web will slowly move from a primary game consumption platform (billions of flash games being played every day!, thousands of small studios living from their flash work), to a marketing platform for mobile games.
With one html/js code base, small indies will be able to push instantly to the web and app stores. They will keep selling sponsorship of theirs games to portals like kongregate and armorgames on the web, get their games expose to millions of visitors, build an audience and promote their app store offering in the meantime.
Win win for portals and game developers.
I will always bet on JS as well.
The games you're talking about here, however fall in to the category of casual games described in the article. So for more featured games, we'll have to wait a bit longer and mature the platform as we go, but eventually we'll get there.
Good point about the same code base. I forgot to mention this in the article, but the reason the programmers say "HELL NO" is that maintaining two different code bases is a nightmare. (Semi-)automatic porting is easier and cheaper.
But that might shift in the future, we might be looking at a time when the only version you need to make is the web version, even for non-casual games.
The games you're talking about here, however fall in to the category of casual games described in the article. So for more featured games, we'll have to wait a bit longer and mature the platform as we go, but eventually we'll get there.
Good point about the same code base. I forgot to mention this in the article, but the reason the programmers say "HELL NO" is that maintaining two different code bases is a nightmare. (Semi-)automatic porting is easier and cheaper.
But that might shift in the future, we might be looking at a time when the only version you need to make is the web version, even for non-casual games.
But that might shift in the future, we might be looking at a time when the only version you need to make is the web version, even for non-casual games.
Unless your game requires or will requires heavy duty CPU and lot of RAM. In which case, you would need to wait several generation before a phone can run your game.
Think of FPS shooters of today, except the resource spending is inverted from the art department to the software side. Instead of racing for the biggest and greatest graphic, they aim for the most complex and detailed world as possible. Instead of gameplay being only 40 hours long game, it is measured in years.
That is the kind of game I am working on.
Unless your game requires or will requires heavy duty CPU and lot of RAM. In which case, you would need to wait several generation before a phone can run your game.
Think of FPS shooters of today, except the resource spending is inverted from the art department to the software side. Instead of racing for the biggest and greatest graphic, they aim for the most complex and detailed world as possible. Instead of gameplay being only 40 hours long game, it is measured in years.
That is the kind of game I am working on.
Phones need serious improvement to run these kinds of games anyway, we're probably looking at at least half the time it's going to take for these games to run with the web technology stack on the mobile to get it running even natively on the mobile. So for mobile, the wait is on, no matter what.
It's going to take a while, but our toolkits need sharpening as well, so I'm not expecting a non-trivial web game to emerge very soon. But the platform is growing in the right direction.
You got me interested, what kind of a game are you working on? Sounds like my kind of a game.
It's going to take a while, but our toolkits need sharpening as well, so I'm not expecting a non-trivial web game to emerge very soon. But the platform is growing in the right direction.
You got me interested, what kind of a game are you working on? Sounds like my kind of a game.
A cross between simulation and RTS game. You're supposed to build up a colony and manage your society. The details are not too abstract, as all units you see will have individual names and the details of your infrastructure are pipes, conveyor belts, workshops, electrical lines, generators, and so on.
You could say it's a "dwarffortress" except the details are totally different. For example, chopping down trees will not kill dwarves, but it does in my game. Production and logistics in my game is a lot smarter to prevent players from worrying about managing food production so that they can worry about more interesting things.
It's a very ambitious project for sure, and I am not expecting to complete the game until many decade latter. I am in this project at about 4 Kloc of code, yet a completed RTS game is about 40 Kloc. Mine will be bigger than this.
The main challenge in doing this project is whether or not I have the ability to slog it out for several decades and the ability to resist temptation to rewrite the whole codebase at once.
You could say it's a "dwarffortress" except the details are totally different. For example, chopping down trees will not kill dwarves, but it does in my game. Production and logistics in my game is a lot smarter to prevent players from worrying about managing food production so that they can worry about more interesting things.
It's a very ambitious project for sure, and I am not expecting to complete the game until many decade latter. I am in this project at about 4 Kloc of code, yet a completed RTS game is about 40 Kloc. Mine will be bigger than this.
The main challenge in doing this project is whether or not I have the ability to slog it out for several decades and the ability to resist temptation to rewrite the whole codebase at once.
Make sure to make a fuzz about it when it's ready to be played, I sure have to give it a shot!
[deleted]
Most HTML5 games i've seen seem to be more proof-of-concept. Is there a good example of a HTML5 game which is a proper product and which generates revenue?
Have a look at this game made in JS (be warned that the framework is closed source):
http://playbiolab.com/
http://playbiolab.com/
I was hoping for a more technical article - the core techs for HTML5 gaming aren't quite from what I can tell. WebGL and the Audio APIs in particular seem on shaky ground for the moment... it seems there are still rather major security and performance problems to deal with.
Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages. Any sort of real time multiplayer really kinda needs UDP to work efficiently. P2P is also fairly important for certain applications and is in a similar state.
Anyway, not that this means to give up hope completely, just of disappointing there aren't many visible efforts to address these issues on the horizon.
Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages. Any sort of real time multiplayer really kinda needs UDP to work efficiently. P2P is also fairly important for certain applications and is in a similar state.
Anyway, not that this means to give up hope completely, just of disappointing there aren't many visible efforts to address these issues on the horizon.
> I was hoping for a more technical article
Sorry to disappoint, there are a lot of more technical articles out there, I wanted to look at this more from the perspective of the process of making games than a more detailed technical overview.
> the core techs for HTML5 gaming aren't quite from what I can tell. WebGL and the Audio APIs in particular seem on shaky ground for the moment... it seems there are still rather major security and performance problems to deal with.
The alleged WebGL security issues are mostly solved now. WebGL has about as much security issues as anything to deal with graphics, a computer can crash because of CSS 3D transitions almost as much as it can because of WebGL.
As for Audio APIs, open security issues are mostly to do with user permissions. The worst thing you can do currently is break the ears of the user and make the application unresponsive. You can do as much without audio APIs: var a = new Audio(); a.src = 'noise.mp3'; a.play; while(1);
As for the maturity of the APIs, WebGL offers most of the capabilities of OpenGL, except for a few quirks like Texture1D not being supported, more strict limits in construct sizes and referencing arrays (for some types you need to use constant value indices, unlike in normal OpenGL).
Audio APIs are in a weird spot now, we have two proposals, one from Google and one from Mozilla. Both have their virtues, and they offer solutions to a bit different problems. But at W3C Audio WG we are working on making these things better, so that eventually we'll get audio APIs across all browsers.
> Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages. Any sort of real time multiplayer really kinda needs UDP to work efficiently. P2P is also fairly important for certain applications and is in a similar state.
This is indeed a huge weak spot, but it's hard to achieve securely. Making solid APIs for P2P connections, spanning more use cases than video streams would unleash open a galore of new doors, so I do hope WebRTC will bring forth a good solution.
Sorry to disappoint, there are a lot of more technical articles out there, I wanted to look at this more from the perspective of the process of making games than a more detailed technical overview.
> the core techs for HTML5 gaming aren't quite from what I can tell. WebGL and the Audio APIs in particular seem on shaky ground for the moment... it seems there are still rather major security and performance problems to deal with.
The alleged WebGL security issues are mostly solved now. WebGL has about as much security issues as anything to deal with graphics, a computer can crash because of CSS 3D transitions almost as much as it can because of WebGL.
As for Audio APIs, open security issues are mostly to do with user permissions. The worst thing you can do currently is break the ears of the user and make the application unresponsive. You can do as much without audio APIs: var a = new Audio(); a.src = 'noise.mp3'; a.play; while(1);
As for the maturity of the APIs, WebGL offers most of the capabilities of OpenGL, except for a few quirks like Texture1D not being supported, more strict limits in construct sizes and referencing arrays (for some types you need to use constant value indices, unlike in normal OpenGL).
Audio APIs are in a weird spot now, we have two proposals, one from Google and one from Mozilla. Both have their virtues, and they offer solutions to a bit different problems. But at W3C Audio WG we are working on making these things better, so that eventually we'll get audio APIs across all browsers.
> Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages. Any sort of real time multiplayer really kinda needs UDP to work efficiently. P2P is also fairly important for certain applications and is in a similar state.
This is indeed a huge weak spot, but it's hard to achieve securely. Making solid APIs for P2P connections, spanning more use cases than video streams would unleash open a galore of new doors, so I do hope WebRTC will bring forth a good solution.
If you are looking for a technical article check Cubiq'a excellent series of articles on the subject. http://cubiq.org/hexagame-the-making-of-an-html5-game As a bonus you can play with the source code as it's all open source.
>Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages.
WebRTC is supposed to have a proposal for this at some point, though currently it only has video conferencing specified.
WebRTC is supposed to have a proposal for this at some point, though currently it only has video conferencing specified.
WebRTC will in fact have TCP and UDP sockets with arbitrary content, so it will be great for games.
Personally I'd love to see more of this. I've been casually trying to help HTML5 Canvas as a gaming platform get off the ground for some time now. It's sort of a hobby at this point.
I've answered a little over 10% of all Canvas questions ever asked on StackOverflow, which has lead me to writing a few tutorials on Canvas-related issues that people come up with.
As a current side project I'm developing a set of HTML5 Canvas games that I plan to open source so that others can have some good examples and tutorials to start making their own Canvas games. The current status of that is in my profile page.
Soon I also hope to release a little booklet of all the Canvas performance issues I've come across and solutions for them, but sheer busy-ness may delay that more than I'd like.
If anyone is having issues with their 2D Canvas game development, especially performance issues that you are running in to, I'd love to hear from you!
I've answered a little over 10% of all Canvas questions ever asked on StackOverflow, which has lead me to writing a few tutorials on Canvas-related issues that people come up with.
As a current side project I'm developing a set of HTML5 Canvas games that I plan to open source so that others can have some good examples and tutorials to start making their own Canvas games. The current status of that is in my profile page.
Soon I also hope to release a little booklet of all the Canvas performance issues I've come across and solutions for them, but sheer busy-ness may delay that more than I'd like.
If anyone is having issues with their 2D Canvas game development, especially performance issues that you are running in to, I'd love to hear from you!
Performance, yes, that is probably the biggest issue you are going to have with HTML5 in my experience.
I'm doing nothing more than pushing a set of tiles around a canvas element, and there are irregular hiccups where the animation loop (a simple setInterval callback) stops for a frame before starting back up again.
Granted, the stuff I'm doing is pretty simplistic, and I haven't tried to optimize for performance yet (or code around the stutters), but it's not an encouraging place to start from as a hobby game developer, let alone someone trying to make a living from it.
I'm doing nothing more than pushing a set of tiles around a canvas element, and there are irregular hiccups where the animation loop (a simple setInterval callback) stops for a frame before starting back up again.
Granted, the stuff I'm doing is pretty simplistic, and I haven't tried to optimize for performance yet (or code around the stutters), but it's not an encouraging place to start from as a hobby game developer, let alone someone trying to make a living from it.
One of the biggest issues I see is that per-pixel manipulation is incredibly slow. Also, information on the best double buffering techniques would be nice too.
The last time I tested SVG on Chrome (five months ago) it was very buggy: moving certain shapes left a trail behind, trying to visualize large graphs with d3 (two months ago) crashed the browser. I need to retest this but my feeling was that we are not there.
Keep up the good work!
I'm a rank amateur when it comes to game development, however I've written a few games, and have been working on one in HTML5 (in addition to having made a few 'test games', which were really just proofs of concept). I've found that the HTML5 Canvas has been great for my needs. It's certainly not at the point where it can compete with desktop games, but trying to make it do that seems absurd (is the browser really the right place for games like Mass Effect?)
That said, writing games in HTML5 is much harder than on other platforms, for example:
A) As the post mentions, the Audio APIs are embarrassingly bad. There is, as far as I can tell, no way which you can cause a sound to play (programmatically, I've never really tried to use the actual <audio> element) in a cross-browser compatible way without having to manually code for the different APIs. One would think that Audio, one of the poster children for HTML5 would have some standardization.
B) Chrome/Safari (and probably IE too) refuse to rescale anything without interpolating it (e.g. no pixelated effects without manually resizing the imagedata). Firefox offers a mozImageSmoothingEnabled property on the canvas element which allows for effects like this, but unless you're developing solely for Firefox, you're out of luck.
C) If you have a large enough canvas and you get the imagedata for it, Firefox can throw an exception because it's bigger than the largest allowed array. This can be solved by manipulating the image data on a smaller canvas and drawing that canvas on a bigger one, but it's still an annoying inconsistency.
Those last two, while minor quibbles, are indicative of the kinds of problems I've run into several times while working with HTML5. Each browser handles everything in a different way, and as far as I can tell, none of them care how the others work. This means that you must test every piece of code you write on every browser you wish to support. Obviously, this has a significant negative impact on development time, and can make some games prohibitively difficult.
On the other hand, there are platforms like Java or Flash (or Unity, so I've heard), where you can write once and expect it to work identically everywhere (even on out of date browsers). That must be nice.
That said, writing games in HTML5 is much harder than on other platforms, for example:
A) As the post mentions, the Audio APIs are embarrassingly bad. There is, as far as I can tell, no way which you can cause a sound to play (programmatically, I've never really tried to use the actual <audio> element) in a cross-browser compatible way without having to manually code for the different APIs. One would think that Audio, one of the poster children for HTML5 would have some standardization.
B) Chrome/Safari (and probably IE too) refuse to rescale anything without interpolating it (e.g. no pixelated effects without manually resizing the imagedata). Firefox offers a mozImageSmoothingEnabled property on the canvas element which allows for effects like this, but unless you're developing solely for Firefox, you're out of luck.
C) If you have a large enough canvas and you get the imagedata for it, Firefox can throw an exception because it's bigger than the largest allowed array. This can be solved by manipulating the image data on a smaller canvas and drawing that canvas on a bigger one, but it's still an annoying inconsistency.
Those last two, while minor quibbles, are indicative of the kinds of problems I've run into several times while working with HTML5. Each browser handles everything in a different way, and as far as I can tell, none of them care how the others work. This means that you must test every piece of code you write on every browser you wish to support. Obviously, this has a significant negative impact on development time, and can make some games prohibitively difficult.
On the other hand, there are platforms like Java or Flash (or Unity, so I've heard), where you can write once and expect it to work identically everywhere (even on out of date browsers). That must be nice.
> is the browser really the right place for games like Mass Effect?
It's not now, but it will be soon.
The browser is the right place for games where the benefits (arguably: low friction, ease of installation, cross-platform development, everyone knows javascript) justify the costs (arguably: worse performance, lack of client-side storage for large assets, users like owning things, rapidly shifting platform, lack of peripheral access, less sophisticated audio, no UDP).
So in practice, the browser is the right place for games with low enough CPU, graphics, data, and I/O requirements. But that target is moving really fast -- partly because computers keep getting better, and partly because Google et al. are working really hard to squeeze the layers between Javascript and bare metal as thin as possible.
So you could imagine a wavefront following about ten years behind us: the browser is currently the right place for games that would have been state-of-the-art in [2002] or before. Plus or minus ten years.
You might ask, why would we put Mass Effect in the browser even when we could? If I can get really wild-eyed for a minute, I think the answer is that the browser is trying to become Neil Stephenson's Metaverse. It's the place where everyone and everything comes together in one geography. Do apps run on the server or the client? Is content user-generated or developer-generated? Is this a file system or a database? Is the API the product? Is the mobile web just the regular web? We're putting more and more complicated apps on the web because that's where they're linkable, hackable, bookmarkable, tweetable, mashable -- because if you ask me to download your thing and install it on one particular device, it's like asking me to leave the whole world and join you in your private copy, where you guard the entrances and exits and the only stuff is the stuff that you built.
OK, that was pretty nuts. But see if you can make it less nuts rather than shoot it down -- is there something fundamental we're trying to do when we put anything and everything within the frame of the browser?
It's not now, but it will be soon.
The browser is the right place for games where the benefits (arguably: low friction, ease of installation, cross-platform development, everyone knows javascript) justify the costs (arguably: worse performance, lack of client-side storage for large assets, users like owning things, rapidly shifting platform, lack of peripheral access, less sophisticated audio, no UDP).
So in practice, the browser is the right place for games with low enough CPU, graphics, data, and I/O requirements. But that target is moving really fast -- partly because computers keep getting better, and partly because Google et al. are working really hard to squeeze the layers between Javascript and bare metal as thin as possible.
So you could imagine a wavefront following about ten years behind us: the browser is currently the right place for games that would have been state-of-the-art in [2002] or before. Plus or minus ten years.
You might ask, why would we put Mass Effect in the browser even when we could? If I can get really wild-eyed for a minute, I think the answer is that the browser is trying to become Neil Stephenson's Metaverse. It's the place where everyone and everything comes together in one geography. Do apps run on the server or the client? Is content user-generated or developer-generated? Is this a file system or a database? Is the API the product? Is the mobile web just the regular web? We're putting more and more complicated apps on the web because that's where they're linkable, hackable, bookmarkable, tweetable, mashable -- because if you ask me to download your thing and install it on one particular device, it's like asking me to leave the whole world and join you in your private copy, where you guard the entrances and exits and the only stuff is the stuff that you built.
OK, that was pretty nuts. But see if you can make it less nuts rather than shoot it down -- is there something fundamental we're trying to do when we put anything and everything within the frame of the browser?
> There is, as far as I can tell, no way which you can cause a sound to play (programmatically)
I suggest you give my audiolib.js ( https://github.com/jussi-kalliokoski/audiolib.js ) and sink.js ( https://github.com/jussi-kalliokoski/sink.js ) a shot, they're designed to abstract away the differences between the "competing" Audio APIs, allowing you programmatic access to as deep as the sample level and providing abstractions such as filters, reverbs, delays, etc. For browsers with no Advanced Audio API, there's an inferior fallback using the <audio> elements.
> On the other hand, there are platforms like Java or Flash (or Unity, so I've heard), where you can write once and expect it to work identically everywhere (even on out of date browsers). That must be nice.
I've heard good things about Unity, and it seems to be a great toolkit for game development. However, write once, works everywhere is a pipedream, really. Even for something as simple as a document website, taking all the possible input methods and screen resolutions, etc. into account is hard work. This is where the mentioned technologies fall short and the web stack shines. If you really need to care about that, it's up to you.
I agree with your sentiments about the B and C to great extent. Also the performance of imagedata is absurdly bad. The interpolation issue is, well... I think I'll write another blog post soon, about how ZOH interpolation may sometimes be the best quality option.
I suggest you give my audiolib.js ( https://github.com/jussi-kalliokoski/audiolib.js ) and sink.js ( https://github.com/jussi-kalliokoski/sink.js ) a shot, they're designed to abstract away the differences between the "competing" Audio APIs, allowing you programmatic access to as deep as the sample level and providing abstractions such as filters, reverbs, delays, etc. For browsers with no Advanced Audio API, there's an inferior fallback using the <audio> elements.
> On the other hand, there are platforms like Java or Flash (or Unity, so I've heard), where you can write once and expect it to work identically everywhere (even on out of date browsers). That must be nice.
I've heard good things about Unity, and it seems to be a great toolkit for game development. However, write once, works everywhere is a pipedream, really. Even for something as simple as a document website, taking all the possible input methods and screen resolutions, etc. into account is hard work. This is where the mentioned technologies fall short and the web stack shines. If you really need to care about that, it's up to you.
I agree with your sentiments about the B and C to great extent. Also the performance of imagedata is absurdly bad. The interpolation issue is, well... I think I'll write another blog post soon, about how ZOH interpolation may sometimes be the best quality option.
I've been playing around with Canvas2D and now WebGL (via ThreeJS) for a little over a year for my pet project 88etag (https://github.com/lucaspiller/88etag). It's a clone of an old 2D space RTS I used to waste many hours playing.
Personally the biggest issues I've come across is the poor performance of the interface code between Javascript and the rendering layer. If anyone has any tips for how to avoid these they would be highly appreciated.
Personally the biggest issues I've come across is the poor performance of the interface code between Javascript and the rendering layer. If anyone has any tips for how to avoid these they would be highly appreciated.
HTML5 is critically dependent upon hardware acceleration. So anything that can't be hardware accelerated wherever the games are running will be slow. If your drivers are bad it will be slow. The next step will be people creating ridiculously complex JIT setups just to get back somewhere near native throughput. Note that is _throughput_, not latency. Every layer of abstraction adds more unpredictable pauses and non-reproducible glitches. All so people can slap together the next Angry Birds clone with zero technical artistry.
The sad part is that once converted to HTML5 these games won't be able to run on many (most?) mobile devices. Current mobile browsers are too slow or non-standard to run HTML5 based games. The exception is iOS 5 powered devices (iPhone/iPad) since the browser now includes hardware acceleration for both HTML5 canvas and CSS3 animation transforms.
For more details, see Spaceport.io's recent HTML5 animation performance tests: http://spaceport.io/spaceport_perfmarks_report_2012_3.pdf