Game Development Reference
In-Depth Information
Tool design.
A SoundLog class is created on the game side, which keeps a short
array of the last few commands issued to the sound system. Every so often, this
log is flushed out to a file.
A SoundReplay class is also created on the game side when we are playing back
a log that was previously generated. This class reads in the log file previously
written out and will call the sound system with each command entry.
How to create the playback log.
All commands called on the sound engine must
be logged so that the sound system can be accurately replayed. This should include
all commands being sent to the sound engine, such as sounds being started and
stopped and volume changes, as well as all system commands, such as any changes
to the listener's position or orientation, any loading or unloading of sound packs,
and any reverb areas being activated or deactivated.
The game also requires a replay mode to be added. While in this mode, the
log file is read in, and the commands are executed. Commands from the game are
ignored while in this mode. Commands coming in from the log file, however, are
still played.
Listing 11.7 shows a few simple modifications to the previous example play-
sound function in order to support playback logging and replaying from the log
file.
The commands being logged require the type of command issued along with the
data used by that command being logged. We also need to store how long the game
SoundInstance * SoundSystem::playSound( SoundEvent * event,
Params & params,
unsigned int owner_id,
bool
from_log )
{
if ( SoundReplay::isReplaying() && !from_log )
{
return;
}
if ( SnapShot::isAllowedCategory( event->m_category ) )
{
SoundInstance * inst = SoundEngine::play( event,
params,
owner_id );
SoundLog::logPlaySoundEvent( event,
params,
owner_id,
inst);
return inst;
}
return null;
}
Listing 11.7.
Sample showing how to add logging to sound calls.
