Game Development Reference
In-Depth Information
Tool design.
The tool consists of two main components. One part is integrated into
the game and consists of any required functions and data needed to communicate
the audio state to our external GUI tool. The other part of the tool is the external
GUI tool, which displays the information sent from the game. Information on the
game's audio state is sent once per game tick to the GUI tool via a buffer. The
GUI tool sends back any commands from the sound designer to the game during
this data exchange.
Implementation details.
The user-interface portion of the tool should be created
as a separate Windows (or other OS) GUI application. This application is run on
a PC while the game is running. During this process, it communicates the audio
state to the GUI tool via a buffer, which is written to once per frame. This buffer is
then sent to the GUI tool via a network connection. The GUI tool can be put into
a listen mode, and when the game boots up, it will establish a connection to the
tool. It can then proceed to send information on the audio state as the game runs.
Similarly, any commands issued by the designer through the tool are sent back to
the game along the network connection. This design provides the most flexibility
and keeps the game screen clear of obstruction. If the platform running your game
cannot communicate via a network to a PC, then the user interface should be built
into the game.
The game-side portion should interrogate the sound engine and send updated
information on the following to keep the GUI tool up to date:
which sound events are being played and their settings;
the names of all sound categories and their settings;
the names of which sound packs are loaded and what their sizes are.
The hardware platform running your game will have a limit on the number of
simultaneous sounds that can be played. Therefore, we are able to make the GUI
tool's list of playing sound events a fixed-size array with a matching number of
elements. As the number of sound packs and sound categories will be variable, it
would be best to have these use a dynamic structure, such as a linked list.
Modifications to the game to support debugging.
When we play a sound, we
will typically pass the sound event we want to play an instance of into the sound
engine, along with any playback parameters, such as the sound's position. We then
receive from the sound engine a handle to that instance of the sound event. We
will need to make modifications to the play sound function so that only sounds
belonging to categories permitted by the designer are allowed to play. This is so
the sound designer can enable or disable sound categories in the GUI tool while
debugging. We show a sample piece of code in Listing 11.1 that tests if a sound
event is allowed to play.
