Sounds Around the Pokemon World! Expanding the Adventure Experience with Sound Design! Part 3: Improve the Efficiency of Sound Implementation
This article is a note for the following presentation: https://cedec.cesa.or.jp/2023/session/detail/s6429a1da844ee
The usage of debuggers
Although the Wwise profiler is excellent at sound debugging, there is information that could not be displayed in it, such as:
- In-game coordinates of a sound
- Information of a sound before sending to Wwise
Gizmo
It is utilized to display coordinates and distance upon sound playing.
Objects
It is able to display all information of an AudioComponent such as:
- GameSync (Switch/RTPC)
- Motion
- Trigger range
BGMManager
Although interactive music could be done exclusively using Wwise, this time the BGM layer is managed by BGMManager. The BGM transition could be modified in detail:
- FadeIn/Out time
- FadeIn/Out Curve
- Delay Time
- Hold Time
- etc…
BGM-related bugs could be detected on the timeline.
History
This could be used to check the PostEvent history, and the object name can be filtered.
The debugging workflow when there is no sound played
Optimization with AudioGroup
It is difficult to use Actor-Mixer/Master-Mixer Hierarchy to perform playback limiting for Pokemon games. Even when the same sound is produced from the same type of Pokemon using the same WwiseEvent, it is better to have different priority settings for the player’s Pokemon, Pokemon in the field, and Pokemon in battle.
Therefore, the priority is set using GameObject groups. All types of events are placed in 3 categories: Player, Field, and Battle. Sounds in the Player AudioGroup will be guaranteed to play. If the number of sounds exceeds a specific value, some sounds in the Field AudioGroup will be removed.