The State of Open Web Games - HTML5 Games Most Wanted

Game Development Reference

In-Depth Information

The limitation of the HTML5 audio element is that its purpose is really to play single audio files, like

background music within a game. It isn't suitable for sound effects, particularly if they are fast paced and if

there are many of them to play at once.

To solve this, the Audio Data API (Mozilla) and Web Audio API (Chrome) have been introduced to allow

for much more fine-grained audio functionality. With these data APIs, you can create sounds from

JavaScript, you can edit audio on the fly, you can play more than one channel of audio at a time, and you

can retrieve data about the audio in real-time as it plays.

Unfortunately, the audio data APIs solutions aren't yet housed within a single specification, and as such,

you need to accommodate both slightly different Mozilla and Chrome proposals. My hope is that in the

near future common ground will be found for a single audio data API to be born from.

Real-time multiplayer gameplay with WebSockets

If you're thinking of creating a multiplayer game, then before now you would either have put up with the

latency involved in constant AJAX requests, or you would have moved to Flash. Neither option is ideal.

What's cool is that since 2011, this is no longer the case, WebSockets have now arrived in all the major

browsers (yes, including IE10) to allow for real-time bi-directional communication between the browser and

a server.

But why is bi-directional real-time communication important for games? Well, this means that you can now

literally stream data to and from a player's browser in real time. One obvious benefit to this is that it saves

bandwidth by not requiring constant AJAX requests to check for new data. Instead, the WebSocket

connection is left open and data is instantly pushed to the player or server as soon as it is needed. This is

perfect for fast-paced games that require an update every few milliseconds. On top of this, the bi-

directional nature of WebSockets means that data can be instantly sent both from the server to the player

and from the player to the server at the same time .

Store data locally with IndexedDB, Local Storage, and other APIs

Many games require data to be stored on the player's machine so that it can be retrieved at a later date—

things like save-game data or cached graphical assets. Until recently, the only way to do this has been to

store data on a web server and put up with the latency, or to use things like cookies and only store very

small pieces of data.

Fortunately, there are now a variety of solutions that solve various aspects of this problem. The most

common are IndexedDB, Local Storage, as well as the various File and FileSystem APIs. The first two

allow large quantities of data to be stored in a structural way within a player's browser, with IndexedDB

even allowing files to be stored. The File and FileSystem APIs allow a game to access the player's OS file

system using JavaScript, letting you save and retrieve files much larger than would be permitted in any