|
Wwise SDK 2019.2.15
|
Before deciding how to manage the banks in your game, it is strongly recommended that you read the following document carefully.
Understanding the Different Bank Management Methods
Introduction
In an attempt to be as flexible as possible and to meet the requirements of almost any type of game, Wwise introduces a new approach for managing the banks in your game. This new approach does not invalidate the usefulness of the original method, but simply gives you more control and flexibility so that you can better manage the requirements of your games.
The new approach offers three major improvements over the existing traditional method:
- You can populate your SoundBanks with not only events, but also structural content(sounds, Containers, Actor-mixers, and so on), Work Units, and folders.
- You determine what types of information will be included in the bank. This means that you can populate a bank with only media, structural data, event content, or any combination of the three. For example, you may want to create a bank that contains only the media associated with a specific event.
- You can include or exclude specific items from a SoundBank.
The main advantage of this new approach is that it allows media content to be split into multiple memory banks. For example, let's say the music for the entire game is started using one single event. Using the traditional method, you would have added the event to the bank, which automatically added all the corresponding in-memory sounds and pre-fetched media, including the pre-fetch for the song that only plays at the end of the game. Storing all the media in memory for the entirety of the game seems very inefficient. Using the new approach, however, you can better manage your memory by splitting the music media into multiple banks so that it would be loaded only when sounds are likely to be played.
By splitting the media into multiple banks, you can also prioritize the media that is to be loaded. For example, in an environment with limited memory, you will want to load only the most important media. Non-critical media could be stored in a separate bank that would be loaded into memory only when there was enough room. Previously, both critical and non-critical media files were contained in the same bank. If the bank was too large to load into memory, none of the sounds would play, including the critical ones.
Different Methods for Managing Banks
The following sections describe the different methods that can be used to generate and integrate the banks in your game. In a single game, you can use one or a combination of the different methods. Since every game is different, the method or methods you choose will depend on the specific requirements of your game.
The choices you make when creating your banks will have a significant impact on the amount of work that will be required to manage the audio assets in the game and will have a direct impact on the performance of your game. It is highly recommended that both the sound designer and audio programmer review this document carefully so that both are aware of the possibilities that are available. Working together, they should come up with a strategy that meets the specific needs of your game. Remember that all solutions will work, but the strategy you choose should take into consideration the memory usage, the I/O access, and the ease of integration in game. Each method has its advantages and drawbacks, so in most situations, it will be a question of balance between memory usage and ease of integration.
 |
Note: The use of PrepareEvent is incompatible with LoadBank, using in-memory data. |
Method 1: One "All-in one" Bank
When using this method, all event content, sound structure data, and media files are stored in one bank that is loaded into memory at the same time.
This method will apply if:
- The game has a limited amount of audio assets.
- The game has plenty of free memory.
Of course, most games generally don't have memory to waste, but this technique has the major advantage of being very simple to use and to maintain. The main reason for using this technique is to have the entire Wwise project integrated in the game in a minimum amount of time.
How's it done:
In Wwise
- Create one SoundBank, and name it appropriately.
- Load the bank into the SoundBank Editor and then drag the following items to the "Add" tab:
- The "\Actor-Mixer Hierarchy\Default Work Unit"
- The "\Events\Default Work Unit"
- The "\Interactive Music Hierarchy\Default Work Unit" (Only required if using interactive music)
- The "\Dynamic Dialogue\Default Work Unit" (Only required if using dynamic dialogue)
Note: The check boxes under the Events, Structures, and Media columns are all selected by default. This is good because, for this method, we want everything to be included in the bank. 
Tip: The advantage of adding complete work units to a bank instead of individual project elements is that you'll never have to re-edit the bank to reflect changes made to the contents of the work units. This is because Wwise maintains an active link between elements in a SoundBank and those in your project. If changes are made to the work units in your project, your SoundBanks are updated automatically. If you use this approach, a new set of SoundBanks can be generated by simply clicking the Generate button. Note: In a new project, only the default work unit is available. If more work units are created, these work units should also be added to the banks as required.
- After all the work units have been added to the SoundBank, you can generate it and then copy the generated bank folder to the game application.
In Game
Since there is only one SoundBank for this game, you can simply load it when initializing the game. Of course, the sound engine must be correctly initialized first.
Additional Notes on this Method
Pros:
- Easiest way to maintain the content of the banks from the sound designer point of view.
- No need to recompile the game when changing the content of the banks since the game always loads the same bank.
- No complex in-game loading and unloading of banks.
- No need to track in-game which sounds are available or not.
Cons:
- Inefficient usage of memory because all events, structures, and in-memory media for the entire game are loaded at all times.
|
Tip: Even though this method is a good way to quickly and easily integrate the audio in your game, don't wait until the end of the project to switch to a method that makes better usage of your game's memory. |
Method 2: Multiple Complete Banks
This method will apply if:
- The game or its audio content can be split into multiple sections.
This method works well for single player games, where all possible sounds are only driven by the current location of the player in the game. By splitting the audio content into multiple banks, you can manage memory more efficiently than the first method, yet still benefit from a relatively easy integration of audio in your game.
How's it done:
First, you must determine how to split up your banks. For example, you may decide to split up your banks as follows:
- One general bank containing all the events that can occur at any point in the game. This bank would be loaded into memory at all times.
- One bank per level, or one per environment. For sounds that depend on the actual location of the main character.
- And possibly some additional banks, depending on the requirements of your particular game.
In Wwise
- Create the banks you will need for the game and then name them appropriately, for example, "CommonEvents", "Level_1", "Level_2", and "Level_3".
- Group your events into folders in Wwise. Create one folder per bank and then drag each folder into its corresponding bank. By adding folders to your SoundBanks, you can avoid having to edit the contents of your SoundBanks every time a new event is added to your project. When the contents of your folder change, the SoundBank automatically gets updated.
- Add all events to their respective banks. This step is only required to add events that fall outside the original folders, if any. If an event needs to be in multiple banks, then simply add it to the required banks.
- Generate the banks and copy the generated bank folder to the game application.
In Game
In the game, simply load the right bank at the right time. For example, the game could load the general bank at the beginning and then load the other banks based on the player's actual location in the game. Note that some games will need to have enough memory to load more than one "level" at a time, to allow for transitions between levels.
Additional Notes on this Method
Pros:
- May require a lot less memory than the "All-in one" bank technique.
- Very easy to integrate in game.
Cons:
- Not well adapted for online or event-based games, where the audio requirements are driven by more than just simple facts like the main character's location.
- May cause some audio source duplication loaded in memory, because banks can contain duplicated data.
- May increase the total space of the banks on disk because different banks may have similar content.
Method 3: Micromanaging Media
This method will apply if:
- The game has a large number of in-memory media assets.
- The media requirements are difficult to predict in advance by the sound designer.
- The project uses switches and states to determine which sound will play for a specific event.
- Sounds can't easily be split into defined sections.
How's it done:
Games can be very complex and the triggering of sounds can be based on a variety of different factors, including game textures, the time of day, the movement of game objects, and in some cases the actions of other players for online multiplayer games. In an event-based or object-based environment, sounds could, for example, be loaded into memory based on the proximity of some other game objects. Every game object could have a list of banks that must be loaded when they are within a given range or simply because they exist.
Also, switches and states can determine which sounds are played. When an event playing such sounds is added to a bank, all possible media is automatically added to the bank as well. For example, you may have a single event called "Play_Footstep". This event will play the appropriate sound based on the current texture of the ground, which is specified by changing the switch. Although this works well, it can be a waste of memory keeping the sounds "footstep_sand.wav" or "footstep_winter.wav" ready in memory when the gameplay is happening inside a building in London.
To avoid wasting memory in this case, you can add events and/or sound structures to a bank and then specify which corresponding sounds will be included in the bank. If, for example, we take the footstep sounds on different textures, we could create the following banks:
- The "EventBank", which would contain the "Play_Footstep" event and structure.
- The "Winter_Footstep_bank", which wound contain the media for the footsteps that only occur in some part of the game (winter).
- The "Desert_Footstep_bank", which wound contain the media for the footsteps that only occur in some part of the game (desert).
- The "Common_Footstep_bank", which would contain the media for the footsteps that can occur anywhere (wood, concrete, and so on).
In Wwise
To re-create the previous example:
Let's say you have three different textures in your game (snow, sand, and concrete). In Wwise, you have a switch container, that plays one of three random containers, based on the switch "ground_texture". Each of the three random containers has four variations of the footstep sound on a given texture.
- Create a bank called "EventBank" and load it into the SoundBank Editor.
- Drag the "Play_Footstep" event to the Add tab of the SoundBank Editor.
- Deselect the "Media" check box for this event, but leave the Events and Structures check boxes selected.
- Create the three other banks, one for each texture.
- In each bank, drag the random container associated with this texture.
Note: It would work as well if instead of drag and dropping the random containers we would drag and drop each of the sounds individually. But the advantage of using the containers is that all the sounds in the container will automatically be added in the bank instead of having to make all the changes manually if the container's content changes. - Deselect the "Events" and "Structures" check boxes for each of the three texture banks, leaving only the Media type checked.
- Generate the banks and copy the generated bank folder to the game application.
At this point, we have four banks. One that contains the event and the structure data related to the audio that is to be played, and three others that contain only media associated with a particular ground texture.
In Game
Additional Notes on this Method
This was only a very specific example of one of many possible things that can be done using this technique. Since it is possible to decide sound by sound and event by event what will be included in every bank, you have complete control over the contents of each bank. Although you could create a separate bank for each sound in your game, this would be very difficult to maintain as every new sound would require new code to load the bank at the right place in the game. The goal for each game is to try and find a good balance between granularity and ease of integration in the game.
|
Tip: If you are interested in a sound by sound loading scheme, look at using either the PrepareEvent API, the PinEventInStreamCache API or the SetMedia API, instead of LoadBank. |
Pros:
- The best option to optimize memory usage.
- Gives you full control over what media is loaded at any point in the game.
Cons:
- Requires a lot of communication between the sound designer and the game programmers to determine which bank must be loaded, and when.
Method 4: Preparing Events
This method will apply if:
- A very small level of granularity is required for media to keep the memory usage low.
- You do not want to worry about splitting your media assets into banks.
What exactly is a prepared event? When calling the PrepareEvent function, the system analyses the event and makes sure that all the structure and media related to this event are loaded into memory. If they are not, the system will automatically stream from disk the missing information. An event is prepared until it is explicitly unprepared.
How's it done:
This method requires that you explicitly exclude media from the SoundBank that contains the metadata (the structures and Events). The structures can be part of a separate SoundBank if desired. However, the granularity for loading structures is per-bank, so it often makes sense to include them in the same SoundBank as the Events.
When building SoundBanks that will use the PrepareEvent mechanism, the required Event and structures must be found in at least one SoundBank, and the media must be accessible as loose files in the file system. If the media referenced by a bank is not included in any other bank, the CopyStreamedFiles tool will assume that it will be used with the PrepareEvent API and will copy the loose file to the output directory.
Prior to preparing an Event, the Event itself must have been loaded into memory from one SoundBank (using LoadBank()). This is required because the Event contains information about the dependencies required to prepare the Event.
In Wwise
- Create a SoundBank called "Events" and load it into the SoundBank Editor.
- Add some of the Events in your project to the "Events" SoundBank, or simply add the Event Work Units.
- Deselect the "Media" check box, leaving the "Events" and "Structures" check boxes selected.
- Generate the SoundBanks. When you generate a SoundBank that has one or more references to loose media, you will get a warning message: Media referenced by <structure> in SoundBank <bank> not found in any SoundBank. You may right-click on this message and add it to the ignore list.
- The loose media referenced by the SoundBanks will, by default, be copied to the same output directory as the SoundBank using the CopyStreamedFiles tool.
- Copy the generated bank folder (along with loose media) to the game application.
|
Note: The structure data contained within a single bank can't be split at run time. Therefore, if you are using AK::SoundEngine::PrepareEvent, and the structure data from a separate bank is required, all the structures within that bank will be loaded at once. For this reason, you may want to split the structure content in your project into multiple banks, to minimize the amount of unnecessary information that is loaded into memory. |
In Game
Additional Notes on this Method
Keep in mind that calls to AK::SoundEngine::PrepareEvent must be considered as I/O functions calls. In the previous example, we used blocking functions. You can use other overloads of the function AK::SoundEngine::PrepareEvent to make them non blocking calls, and then revive the completion notification through a separate callback.
Pros:
- Bank generation process is simple.
- Level of granularity for media is very small.
- Maintain a low overall memory usage.
- Easy to automate the process.
Cons:
- Potentially increases the number of reads and seeks on the disk as the media assets will be loaded one by one.
- Less control over the total amount of memory used.
- Not ideal for interactive music.
Method 5: Preparing Events and Game Syncs (Switches and States )
This method will apply if:
- A small level of granularity is required for media to keep the memory usage low.
- You do not want to worry about splitting your media assets into multiple banks.
- You have events in your project that play different sounds based on switches or states.
- Your project contains interactive music that plays music based on switches or states.
This method is basically the same as the previous method (Method 4: Preparing Events), but with more control over the media that gets loaded when events are prepared. With this method, only the media associated to both the events that are prepared and the game syncs that are currently active is loaded into memory.
Let's say you have a simple project with two events: "Play_Maincharacter_FootSteps" and "Play_Monster_Footsteps". Each event plays a different switch container that plays different random sounds based on the ground texture under the moving character. The switch group name is "GroundTexture" and has three possible states: "Snow", "Concrete", and "Sand".
The switch container hierarchies in Wwise will look like the following:
Switch_Container_Footstep_Main_Character
- Random_Container_Sound_Snow_main
- Sound_Snow_main_1
- Sound_Snow_main_2
- Sound_Snow_main_3
- Random_Container_Sound_Concrete_main
- Sound_Concrete_main_1
- Sound_Concrete_main_2
- Sound_Concrete_main_3
- Random_Container_Sound_Sand_main
- Sound_Sand_main_1
- Sound_Sand_main_2
- Sound_Sand_main_3
and
Switch_Container_Footstep_Monster
- Random_Container_Sound_Snow_Monster
- Sound_Snow_Monster_1
- Sound_Snow_Monster_2
- Sound_Snow_Monster_3
- Random_Container_Sound_Concrete_Monster
- Sound_Concrete_Monster_1
- Sound_Concrete_Monster_2
- Sound_Concrete_Monster_3
- Random_Container_Sound_Sand_main
- Sound_Sand_Monster_1
- Sound_Sand_Monster_2
- Sound_Sand_Monster_3
In this example, we have 18 sounds (6 groups of 3 sounds) that can potentially be loaded into memory.
You could use the method Method 4: Preparing Events , but you won't get a level of granularity smaller than 6 sounds loaded in memory per event. You could use the method Method 3: Micromanaging Media to get a better level of granularity, but you would have to create 6 different banks for this simple project (the number of banks increases quickly in real project). Then, when a monster appears, you would have to check to see what textures are possible and then load the appropriate banks.
With the current method, all you have to do is specify which events and game syncs are possible and then only the appropriate media will be loaded. As with PrepareEvent, all the media must be available as loose files in the file system.
How it's done:
In Wwise
- Create a bank named "Events" and load it into the SoundBank Editor.
- Drag the 2 events to the Add tab of the SoundBank Editor.
- Deselect the "Media" check box, leaving the "Events" and "Structures" check boxes selected for both events.
- Generate the banks. When you generate a SoundBank that has one or more references to loose media, you will get a warning message: Media referenced by <structure> in SoundBank <bank> not found in any SoundBank. You may right-click on this message and add it to the ignore list.
- The loose media referenced by the banks will, by default, be copied to the same output directory as the SoundBank using the CopyStreamedFiles tool.
- Copy the generated bank folder (along with loose media) to the game application.
In Game
- Load the "Event" bank before the two events are required by the game.
- When possible ground textures are nearby, activate the game syncs.
- Activate the Concrete texture at all times.
- Prepare the main character footstep event at all times.
|
Note: The structure data contained within a single bank can't be split at run time. Therefore, if you are using AK::SoundEngine::PrepareEvent, and the structure data from a separate bank is required, all the structures within that bank will be loaded at once. For this reason, you may want to split the structure content in your project into multiple banks, to minimize the amount of unnecessary information that is loaded into memory. |
|
Note: The order in which you call AK::SoundEngine::PrepareEvent and AK::SoundEngine::PrepareGameSync is not important. Each time the state changes, the media pool is updated by crossmatching the events and the game syncs. |
Additional Notes on this Method
Pros:
- Bank generation process is simple.
- Level of granularity for media is very small.
- Maintain a low overall memory usage.
- Easy to automate the process.
- Only useful media gets loaded.
Cons:
- Potentially increases the number of reads and seeks on the disk as the media assets will be loaded one by one.
- Less control on the total amount of memory used.
- Activating a game sync can cause high streaming bandwidth when a lot of events are prepared that require new data to be loaded.
Was this page helpful?
Need Support?
Questions? Problems? Need more info? Contact us, and we can help!
Visit our Support pageTell us about your project. We're here to help.
Register your project and we'll help you get started with no strings attached!
Get started with Wwise