This depends on your game’s unique requirements, which you know far better than we do.
That being said, from what you’ve said, I suspect you will find option A to be superior. This is partly for performance reasons, partly because it should simplify the creation and maintenance of your project, and partly because it gives you more power and flexibility.
To understand why it impacts performance, you need to know one thing: In order to play an event, the FMOD Engine must first load all the sample data that that event’s instruments reference*. That includes all the assets in the event that won’t play this time but might be played by a later instances of the same event, because the FMOD Engine has no way of knowing in advance which of those assets this particular instance of the event will need. Thus, if an event references a very large number of assets, it will take longer to load before playing and will require more memory when loaded than an event with only a small number of assets.
Creating a large number of bark events that contain only a small number of assets each therefore results in far fewer resources being consumed at run time than a single bark event that contains all of your bark assets would.
To understand why it impacts the amount of work and maintenance you’ll have to do, you only need consider the extra effort required to create a parameter, maintain a table of which parameter values correspond to which barks, and have your game’s code reference that table at run time.
An event that plays one asset and does nothing else is extremely easy to create. All you need to do is drag the asset (or multiple assets, if you want to create multiple events at once or make one event that selects one of several assets to play at random) onto the events browser and select the appropriate options from the dialog that appears. By contrast, creating an event that selects from multiple different assets requires the creation of a parameter and the careful positioning of multiple instruments; you may only have to do it once, but “it” is a bigger task than creating a large number of much simpler events would be.
From the programmer’s perspective, there’s very little difference between creating and playing an instance of a different event depending on what bark you want to play, and creating and playing one instance of an all-purpose bark event and setting its parameter. Either way, you’re telling an event to play and specifying which specific bark to use. The latter method does consume more resources and requires longer load times (as I mentioned above) but in terms of the code complexity required, it doesn’t make much meaningful difference.
To understand why it impacts the power and flexibility you have… You’ve already worked this out:
You’re entirely right: Having just one event means that every instance of that event will use the same routing, and you’d have to put up with all the limitations that that entails. Having a whole bunch of bark events will mean you can route every bark into an entirely different group bus, if you want - or something less extreme, such as routing all the barks associated with a specific character into the same bus so that they can all recive the same processing.
To sum up… Putting all your barks into one event probably means poorer performance, less flexibility, and more work for you.
I can’t be certain, though, because every game is different. Perhaps you have plenty of room in your resource budget, and so don’t mind the increased overhead, or perhaps you’re loading all of the sample data associated with a bank well in advance of when the event is played and so won’t actually suffer increased resource costs. Perhaps you prefer the simplicity of a streamlined routing structure and don’t need the increased flexibility that individual bark routing brings. Perhaps you’re using one of the two methods for avoiding high resource costs given in the footnote*. I have no way of knowing.
*There are actually two ways to make the FMOD Engine only load the specific assets you want an event instance to play this time.
The first is to use event instruments. These cause the assets associated with a particular referenced event to only be loaded if the relevant event instrument is triggered, but this benefit comes with two significant caveats: It’s more work to set up and maintain, and it introduces a small amount of latency between an event instrument being triggered and its associated assets beginning to play. It’s therefore rarely better than the alternative.
The second is to use programmer interments. These do not directly load any assets; instead, when a programmer instrument is triggered, it generates callback and prompts your game’s code to supply a path to an audio asset (either an asset in an audio table or a loose file on the player’s drive) to play. This allows you to create a single, simple event to play all of your game’s dialogue while allowing your game’s code a great deal of control over what asset plays, making it an extremely popular instrument for dialog.
