HTML and CSS Reference
In-Depth Information
Audio
There have been teething troubles with HTML5 and audio. The situation has improved drastically in recent times,
with more browsers implementing Web Audio API. On most mobile devices it was the case that sound sprites would
need to be used—a single audio file containing all the game sounds. The sprite is constantly played, with the playhead
being moved to the relevant time point, enabling playback of the required sound. This works to a degree, but when
you have put your all into making a great game, the last thing you want is to settle for single-channel audio.
The logical decision path for which audio method to deliver to a user has to favor multiple-channel audio above
all else.
Funfair Freak-Out
implements all three methods, as described in Figure
14-7
.
Web
Audio API
available
?
No
No
No
Flash
available
?
Mobile
Device
?
Yes
Yes
Yes
Web
Audio API
available
?
Yes
No
Luxuriate in
Web Audio
API
Use Flash
audio
playback.
Use sound
sprite
Figure 14-7.
Audio rendering decision tree
In addition to sound sprites and Web Audio API, a third option is available for desktop: Flash playback. Okay, this
sounds like it is going against the grain of open standards, but we are building user-facing products here. The primary
concern should be the quality of the final outcome. So, on desktop the ubiquity of Flash and its audio capabilities
means that it has to come ahead of sound sprites on the priority list.
Asset Sizes
It is easy to get carried away with adding more and more graphics to a multiplatform HTML5 project. Who is going
to argue with a little eye candy? On desktop we arespoiled—the browsers all have a pretty high memory allocation
per page. This isn't the case on most mobile devices. Across the many projects that I have seen, problems have
begun when the asset set starts to clock in at more than 10MB. The issues range from full browser crashes to
graphics disappearing.
