4 ms·

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

by yoklov 15y ago

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.

quinnirill 15y ago
> 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 https://github.com/jussi-kalliokoski/audiolib.js ) and sink.js ( https://github.com/jussi-kalliokoski/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.
JackC 15y ago
> 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?

by yoklov 15y ago

quinnirill 15y ago

> 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 https://github.com/jussi-kalliokoski/audiolib.js ) and sink.js ( https://github.com/jussi-kalliokoski/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.

JackC 15y ago

> 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?