Table of Contents
The following paragraphs provide tips and best practices that can help you better manage the Events in your project.
Before changing the name of an Event, verify how the Events have been integrated into the game. If Events have been integrated using strings containing the name of the Event or IDs from the Wwise_IDs.h header file, changing the name will require additional programming to be able to use the Event.
You can use Work Units and Virtual Folders to organize the Events in your project. Dividing your Events into multiple Work Units can be very useful when several people are working in the project at the same time. For example, each team-member can create their Events in their own personal Event Work Unit. Dividing up your Events into different Work Units should not affect your productivity or workflow, but by doing so, you can avoid merge conflicts that can be both frustrating and time-consuming to fix.
You can use the SoundBank definition file to track which Events have already been integrated into your game, which ones are missing, and which ones still need to be created in Wwise. The audio programmer can generate the list of Events from the game and then you can import the definition file into Wwise. You can use the information in the log file to match up the Events in game with those created or missing from Wwise. For more information on SoundBank definition files, refer to Populating a SoundBank by Importing a Definition File.
Event information is stored within the Default Memory pool of the sound engine. To avoid using too much space within the default memory pool, you can stop, pause, and resume sounds programmatically using the
ExecuteActionOnEvent() function in the Wwise SDK. Instead of creating Play/Stop Event pairs, you can create a single Play Event with a call to ExecuteActionOnEvent to stop the sound. If you need to pause and resume the sound, you don't need to create separate events, you can simply use the same function to execute the pause and resume Actions. This can significantly reduce the number of Events within your project and can free up some valuable space in the Default Memory pool. To give you additional control, you can also specify fade out times when stopping, pausing, or resuming sounds programmatically. For more information about the ExecuteActionOnEvent function, refer to the Wwise SDK documentation.
For most natural sounds, pitch actually fluctuates or changes for a time until it reaches its steady state or 'sustain' level. To create this effect, you can use a pitch envelope. Wwise does not support pre-programmed pitch envelopes, but you can get close to that behavior by creating an Event with multiple consecutive Voice Pitch Actions. Each Set Voice Pitch Action in the Event could adjust the pitch over a period of time following one of the predefined curves in the Action properties. Of course, the last Action in the sequence would probably need to be a Reset Voice Pitch in order to get the game object to its original state.