HTML and CSS Reference
In-Depth Information
Q.load(['blockbreak.png','blockbreak.json',
'paddle.mp3','block.mp3'], function() {
Q.compileSheets('blockbreak.png','blockbreak.json');
Q.scene('game',new Q.Scene(function(stage) {
stage.insert(new Q.Paddle());
stage.insert(new Q.Ball());
Next, make sure you have the necessary files: .mp3 and .ogg files in audio/ . Although the load method
mentions files ending in .mp3, the engine will automatically substitute the extension based on what's supported
on the platform you are on.
If you fire up the game in a desktop browser, you should now have basic sound effects for when the ball hits
blocks and the paddle.
As mentioned in the last section, for mobile devices, this simple, straightforward mechanism isn't going to
work. You'll add sound for mobile in the next section.
Building a Sound System for Mobile
I would like nothing better than for the code in this section to become obsolete; it's hackish and does things no
game should have to do just to play some simple sound effects. Unfortunately, it's also the only option that's
currently available to HTML5 game developers building mobile games. It's not a great solution: Sound effects
on iOS aren't synced-up well on iOS, and preloading sounds isn't allowed. Android has similar restrictions.
Until the Web Audio API is available for mobile devices, sound support on mobile will be limited.
Using Sound Sprites
So what's the solution? Sound sprites. Much like image spritesheets, audio sprites work by putting multiple
sounds into a single audio file, separated by gaps of silence.
If you want a standalone library for doing this, there is the Zynga jukebox library, on GitHub at ht-
tps://github.com/zynga/jukebox . It is a library for playing sounds on mobile devices and works in the same way
as the code you add to Quintus does. Jukebox is designed to play on the widest range of devices possible, has
been tested all the way back to Android 1.6, and includes a Flash fallback for older Android devices. The code
in Listing 25-2 is targeted only at recent iOS and Android devices.
To make audio sprites work, on the first user interaction with the game (such as a touch of the title screen) the
sound system starts preloading a single sound. When the sound is playable, the engine starts playing the sound
at an initial position in the sound file, which contains only silence. The system then sets a timer to keep looping
over the initial silence portion of the sound.
The reason it keeps looping over the sound is that iOS enables automated chaining of sounds: When one
sound ends, you can start the next one without user interaction. However, it doesn't enable you to arbitrarily
start playing a sound when there are no other sounds playing.
This means the single audio sprite sound file needs to always be playing, even if what it's playing is just
silence.
To actually trigger a sound effect, the system fast forwards to the spot in the audio file where the effect is po-
sitioned and then sets a timer to go back to playing silence as soon as that sound has finished playing. Because
 
Search WWH ::




Custom Search