Wwise Help

Divide your project into smaller Work Units. If your projects are large and you keep all your project data in the Default Work Units, you will not only slow down Wwise's response time, but the members of your team will need to merge every time someone makes a change, which can greatly increase the chance of merge problems and conflicts. By dividing up your project into smaller chunks using Work Units, people can work more efficiently, can access information more quickly, and can work on different areas, which can reduce the possibility of merge problems.

Assign responsibility for global Default Work Units. It may be a good idea for one person to manage or at least be aware of the changes that are being made to these project elements.

Manage global project elements effectively. When you rename or delete a global project element, such as a State or Game Parameter, be aware that you might be modifying many other objects within your project, including all the sound objects and Containers that are using these elements. When you save and check in these changes, you might be affecting a number of different project files that other people are working on. To limit the impact of this type of change, you should define the global project elements as early as possible and then try to avoid making changes to them after that. If changes are required after the initial setup, you should do the following:

Check the project file status. Before you begin working on a Work Unit, use the File Manager to verify which files are read-only. If you change a Work Unit that is read-only, you will not be able to save that particular file within your project.

Back up your local files regularly. Although the files in the central repository may be part of a scheduled back-up plan, the copies on your local machine are not. To prevent data loss, it is a good idea to back up your project files on a regular basis, especially if you have made significant changes to the files.

Generate an Integrity Report before checking in. Before checking in a particular Work Unit, it is a good idea to generate the integrity report to make sure there aren't any project errors. If errors exist, you can quickly resolve them and then check the Work Unit in.

Sync before new work sessions. You should sync your project files with the server before starting a new work session so that you have the latest modifications.

Close Wwise before syncing. Before syncing your project files with the server, you should close Wwise to prevent the possibility of losing information. If Wwise is open, a copy will remain in memory. When you sync, the files on your disk will be modified, but the older version of your project will remain in memory. If you save the currently opened project, you can overwrite the changes of others that were saved to your disk.

This only applies if you are not using a source control plug-in. When you sync using a source control plug-in, you are automatically prompted to reload the latest version of the project.

Submit often. If you have large changes that affect other members of your team, you should submit your project files often to the server so that others can benefit from the changes you are making. If you wait too long, you also increase your chances of conflicts. By submitting smaller, targeted changes, it will be easier to revert to an older version of the project if necessary and easier to resolve conflicts if any arise.

Add useful comments. When you commit or check-in your files, make sure to fully describe the changes that you made.

Understand your source control system. Before using a source control system to manage your Wwise project files, you should have a good understanding of how it works. Knowing the intricacies of your source control system can help you avoid problems and create an effective and efficient production pipeline.

Become familiar with the Wwise project XML structure. Spend some time familiarizing yourself with the XML structure of the Wwise project files before merging your files. In some circumstances, you may have to update the XML. If you don't understand it correctly, you may break your project. If you do modify the XML, make sure to open the project in Wwise before checking the files back in to your source control system. This will ensure that the changes you made to the XML are valid and what you wanted.

Encourage frequent and open communication. In any team environment, it is key that you communicate openly and frequently with the other members of your team. Frequent and open communication can result in fewer conflicts, less time merging files, and a more efficient production pipeline. For example, before making changes to a Work Unit that affects other members of your team, you should ask them to check in their changes and wait for your word before syncing and resuming their work.

Before deleting any files that are marked Unused in the Usage column of the File Manager, it is good practice to close and re-open the project to make sure the information is completely up to date.

SoundBanks are configured in Work Units in the SoundBanks tab of the Project Explorer. The Work Unit files are in the <project>\SoundBanks\ directory, and are XML files with the extension .wwu. You can reduce the frequency of changes to these files by populating them with objects such as Containers instead of, for example, individual Sound SFX.

Generated SoundBanks are created by Wwise, by default in the <project>\GeneratedSoundBanks\ directory. They are binary files with the extension .bnk. Since they can always be generated from the project, we recommend you exclude them from source control. See Using Wwise with your source control system.