IN THIS CHAPTER
Blockbuster games combine a rich story, beautiful graphics, smooth playability, mood-inducing background music, and startling sound effects. Mobile game designers must get used to working around severe limitations on all of these elements. But of all the sacrifices a MIDP developer must make, no other component is quite as inadequate as music and audio effects. MIDP sound support is virtually nil.
That being said, many phone operators are beginning to introduce extension APIs with excellent sound capabilities. Check out Chapter 23 for a full overview of the Siemens API.
Most early MIDP devices were not originally intended as gameplaying or digital entertainment machines. While it may seem ironic that a telephone doesn't come with built-in audio hardware, that is sadly often the case.
The latest batch of phones and other devices, however, are much more impressive. Many phones now have the capability to play fancy ring-tones, chirpy sound effects, and even MP3 music files.
Even the simplest phone, however, usually has the capability to emit a few simple beeps and blips. These sounds are triggered as part of the phone's user interface—whenever you select a menu option, whenever an alert dialog pops up, or if an alarm is triggered.
MIDP allows you to use its Alert class to invoke simple system sounds. The Alert class, discussed in Chapter 13, “High-Level Graphical User Interfaces,” is used when a game needs to display an important dialog box notification. Alerts are typically used to present information about the game, such as instructions, credits, and so on. Sometimes an alert box will pop up as a gameplay warning, or even as a user-friendly way of catching a programming error.
MIDP lets you define various types of alerts using the AlertType class. Some phones attach unique sound effects to each of these alert types.
These types are
Information—. Communicates some sort of non-crucial data to the player. The associated sound is usually very short and subtle. This sound can be played several times throughout the cycle of a game to express some sort of common game event.Confirmation—. Confirms a user's actions. The associated sound is usually succinct but noticeable.Warning—. Warns the user about a potentially dangerous operation. The sound is often sharp and of a long duration. In general, it makes sense to play a warning sound during major game events, such as when the character is about to die or when the game is over.Alarm—. A very noticeable sound intended to alert the user about a predefined event. Alarm sounds can last for a very long time. Games should use such a sound rarely.Error—. Alerts the user that something erroneous or problematic has just occurred. The associated sound is generally short but grating and negative.
The AlertType—class doesn't have any public constructor. To use it, you can grab one of five static objects: AlertType.INFO, AlertType.CONFIRMATION, AlertType.WARNING, AlertType.ALARM and AlertType.ERROR. Each of these objects only has one method: playSound(), which plays the defined alert sound. The method takes an instance of the Display class as a parameter.
For example, if we wanted to spice up the car game we have been developing, we can add a short sound effect (Info) whenever the user collides with another car; a blaring horn (Error) when the car's energy drops to zero, and a long wail (Alarm) when the game is over.
Listing 18.1 shows a modified version of the checkCollision() and checkFinishLine() methods.
Example 18.1. Modified Versions of checkCollision() and checkFinishLine() Methods
private void checkCollision()
{
if (enemyList.collide(player))
{
player.setEnergy(player.getEnergy() –
COLLIDE_ENERGY);
AlertType.INFO.playSound(Display.getDisplay(
midlet));
}
if (player.getEnergy() <= 0)
{
running = false;
AlertType.ERROR.playSound(Display.getDisplay(
midlet));
}
}
private void checkFinishLine()
{
if (Float.getInteger(line) > Cache.height)
{
running = false;
finished = true;
AlertType.ALARM.playSound(Display.getDisplay(
midlet));
}
}
Unfortunately, the sound capabilities of today's Micro Java devices leave a lot to be desired. Future versions of MIDP will definitely focus much more on rich and varied effects, background music, and other audio features.
In the meantime, there are many vendor-specific extensions by companies like Siemens enabling more impressive grooves.