We have a lot of guns in our game, and they can be indoor or outdoor, suppressed, unsuppressed, etc.
We have laid it out like this, from top to bottom, assuming you double click your way into the next event each time:
-Top level event to sort between occluded and unoccluded (parameter sheet)
-distance sorting event that sorts between close/medium/distant (parameter sheet)
-gun collection event that has all the guns as individual parameters (parameter sheet)
-sorting event for suppressed/unsuppressed, the two options being parameters (parameter sheet)
-outdoor/indoor parameters, where finally the actual audio assets are played from
So the actual audio is on the 5th event “layer” down
What I am wondering is whether this is the most performant solution, seeing as it’s specific, and it isn’t having to decide what to play back until it’s all the way at the bottom?
The alternative would be to have fewer layers, with more multi instruments together with conditions telling them to only play beck when this and that parameter is set. My assumption is that this is LESS performant, since it’s calling up every mumti instrument and asking “are your conditions met?” for each one.
We treat the events and parameters here like a specific “address” that guides Fmod to the one particular instrument we want played.
Hi,
Thank you for the detailed post.
Audio only get queued up when its conditions are met not when checking those conditions. So having multi lots of multi instruments is fine.
Here is an altenative example how you can have a single event housing all the different types of weapons using parameters:
You’d have multi instruments for the supressed/unsupressed and then using the other parameters to drive autiomations.
Ultimately, FMOD provides the options to build your events however works best for your use case so there is no wrong way to do it 
Hope this helps!
That top image is what we have going on. Then if you double click any of those there’s another similar event with two events in it: unsuppressed and suppressed.
Really the question is whether the CPU load of navigating multiple nested events is better or worse than navigating the trigger conditions of multiple stacked multi instruments.
Multi instruments are slightly more performat purly because they are simpler but not so much so it is worth chaging your worflow if event instrument solve your problem.
That’s super interesting!
So if I for example have a branching tree of event instruments, and we assume there are no effects, no automations etc on any of them, it would be MORE performant to pull all those multi instruments out of their end-point events, stack them all up on a single event, and use trigger conditions to tell them when to play back?
Slightly yes, checking conditions is very cheap and the audio will not be loaded until it is triggered to play.
