Audiokinetic Wwise Knowledge Base

Using a game object pool seems to be a good idea at first glance.  You would reserve a fixed amount of object at startup thus fixing the amount of memory used by those objects.  It would ensure that your game never over-use objects.  However, things are not so simple.  Implementing a game object pool can lead to severe memory problems if not done properly.  The rule of thumb is to avoid using such a pool.  Here's why:

In the SDK documentation (section Sound Engine Integration Walkthrough » Integrate Wwise Elements into Your Game » Integrating Game Objects), it is said that game object retain some values:

For every game object, there may be an associated 3D position, a switch for every existing switch group, an RTPC value for each RTPC, and multiple values (for example a volume) that would have been set on a specific item (sound, actor-mixer, bus, and so on) for a specific game object. The Sound engine stores this information until the game object associated to these values is unregistered.

These values take some extra memory that is associated with the game object.  This is done because it is expected that when an RTPC or a volume is set on an object, you should not need to re-set them every time you post an event.  The only way to clear that extra memory is to call AK::SoundEngine::UnregisterGameObj.  Therefore, before returning an object to your pool, you should call UnregisterGameObj to clear the memory and then RegisterGameObj to re-allocate the base object.  Given that your code should already handle a failure of game object allocation (if you have more than your pool contains), it is less advantageous to even keep the basic game objects around when not in use.

Whether you plan to use a pool of game object IDs or have a way to make unique IDs, here are a few example of when to unregister a game object:

• In a RTS game, when a unit dies.
• In a FPS game, everytime the player swaps gun.  If the player has a handgun, it will play many handgun sounds for a while.  When switching to the knife, it is probably useless to keep around the history of properties and playlist of the handgun sounds.
• When changing levels
• Everytime a game object is re-purposed: for example a game object was associated with a NPC walking around.  This NPC disappears and another NPC appears elsewhere.  If you reassign the old object ID to the new NPC, you should unregister and re-register.
• When changing the ambiance.  Example: your character is outside and moves inside a room.  If you use the same game object ID, you should unregister to clear the outside-ambiance-sounds settings and re-register.  Or simply use a different game object.

Obviously, this is a general guideline.  Some game objects will never have any special properties set on them.  Some others will always have the same properties (a switch for example) set multiple times.  This won't make the memory usage grow.  Some game objects must keep that information for longer than others. 

It's a case by case decision for when to reset or not.  An example of a game object which is useless to reset would be the one for dialogue.  You set the volume once and play dialogue lines on it for the rest of the game.  There won't be any increasing memory usage on this game object.