At any moment in a game, you can have many objects playing at the same time, even to the point where the number of objects surpasses the limit set by the project team. To effectively manage the number of objects that are played, you must determine how many can play simultaneously, and which ones take priority.
In Wwise, there are three main properties that can help you determine which objects will be played at any point in the game:
-
Playback Limit - A limit to the number of instances that can be played at any one time. (This does not include any virtual voices.)
-
Playback Priority - The importance of one object relative to another.
-
Volume Threshold - A certain volume level below which objects are not played.
By setting limits, assigning priorities, and specifying a minimum volume level, you can effectively and creatively manage the many objects in your game while respecting any memory limitations that have been put upon you.
![[Note]](/images/2017.2.10_6745/?source=Help&id=note.png) |
Note |
|---|---|
|
In addition to the three techniques mentioned above, your programmer can also define a memory threshold for one or more of the sound engine's memory pools. When the Memory Threshold is enabled, the sound engine periodically checks that the percentage of memory being used is below the specified threshold. If it goes over the threshold, the sound engine will start dropping sounds with lower priorities to free up space for the higher priority sounds. For more information on the Memory Threshold, refer to the Wwise SDK documentation. |
Let's say you are composing music for a game that will have very restricted bandwidth. You have been told you can have no more than four voices playing back at once. In this case, you could set the Playback Limit of your top-level parent object to four. Each of your Music Segments will contain no more than two tracks, so when the pre-entry and post-exit parts of each track are played during a transition only two voices are taken up. This way, if two segments are playing at the same time, you will still only be within the four voices playback limit.
 |
If, however, a Stinger is triggered by the game during a transition, you will surpass the maximum of four streams.
 |
When the number of voices surpasses the playback limit, Wwise looks at the playback priority of each music object to see which one to stop playing. In this case, you would probably set the Stinger segment to a lower priority to ensure that the “regular” music continues to play. If, however, all five objects in this example had the same priority, you can choose to kill the newest or the oldest instance.
The following illustration shows how you might set up your Interactive Music Hierarchy along with the values you may assign for Playback Limit and Playback Priority in a case like this.
 |
For more information about music objects and building your Interactive Music Hierarchy, refer to Chapter 23, Building the Interactive Music Hierarchy.
Cette page a-t-elle été utile ?
Besoin d'aide ?
Des questions ? Des problèmes ? Besoin de plus d'informations ? Contactez-nous, nous pouvons vous aider !
Visitez notre page d'AideDécrivez-nous de votre projet. Nous sommes là pour vous aider.
Enregistrez votre projet et nous vous aiderons à démarrer sans aucune obligation !
Partir du bon pied avec Wwise