Game Development Reference
In-Depth Information
Sound-pack loading zones should similarly be rendered as geometry to show
whether the sound pack is loaded or not. They should follow a color scheme to
indicate if the sound pack is loaded or not. It should also display the name of its
associated sound pack.
The sound properties for surface materials should also be made available for the
sound designer to investigate. This can be achieved through the implementation
of a simple picking system, whereby the sound designer can use either a mouse (or
some other interface) to select a surface in the game's environment and see what
sound properties have been assigned to that surface. For example, there may be a
wall with a dirt texture, but that material has accidentally been given a metal sound
property, so any impacts with that surface will be using their metal variants. To
implement this we must perform a ray-cast from the cursor position onscreen into
the collision mesh of the world geometry. We then retrieve the collision material
belonging to the polygon underneath the cursor and display the sound material
parameter on the game's screen.
11.2.3 Playback Logging
This tool is mostly used for tracking bugs occurring within the game's audio system.
Sometimes a bug may be dicult to reproduce, as it relies on some subtle interaction
between the player and the game environment. An example of this is when a sound
does not play. This could be caused by accidentally unloading the sound pack
holding the audio data used by that sound event.
What the tool must provide. A solution to this problem is to construct a replay
log of all sound commands that were executed by the sound engine over the course
of a play session. This can be done by logging each command before it is passed to
the sound engine and storing the command into a log buffer. Periodically, this log
buffer is then flushed out to a file.
Your game should provide a boot option so that the logging tool can be active
as soon as the game starts. Enabling or disabling the tool should be prohibited
while the game is running, as important events may be missed from the log. Your
game should also supply a replay mode, where only the sound commands that were
logged are executed by the sound engine.
As with the visualizer tool, the user interface for this tool is minimal. When
the tool is activated, it can display its interface either onscreen or as a separate
GUI application. The interface should allow the sound designer to set a logical
breakpoint within the log file. This differs from a code breakpoint, in that it will
pause the game and launch any debugging tools required. This is done by marking
the last command logged as a breakpoint. When this breakpoint is reached during
playback, the game pauses.
Search WWH ::




Custom Search