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.