Sound event call architecture


I am making a multiplayer game.

There are 10 players and 50 bots on the map.

Everyone has a weapon in their hands. Each weapon has a sound of a shot, a sound of trying to shoot without ammo, a sound of reloading, a sound of picking up.

Should I make an EventEmitter for every weapon and sound type? 60 EventEmitters on scene is this normal?

I have an idea to make 1 EventEmitter for the weapon, but set up each Event as a Scriptable Object beforehand, or as a field in a prefab. Those. there are 4 events with sounds for one weapon, and they will use 1 EventEmitter. Will they interfere with each other?

Fundamentally, the StudioEventEmitter script is designed to handle the creation and lifetime a single instance of an event, and is somewhat limited in applicability as a result. As such, using a single emitter for four separate events will cause them to interfere with each other, yes.

You could create an EventEmitter for every weapon and sound type, but obviously that’s quite a hassle, so I’d recommend creating a custom script to handle playing all sounds for a given weapon instead. From the brief description of your project that you’ve given, I’d suggest the following:

  • Four exposed EventReference member variables to plug your desired events into in the Inspector
  • EventInstance variables to store your event instances so that you can access them
  • Generic functionality to manage creation, playback, release, updating/attaching 3D attributes, parameter adjustment, etc. of your event instances
  • Public methods (e.g. PlayGunshot(), PlayReload(), etc.) to play sounds, to be called from whichever scripts are handling your weapon functionality

Obviously you know your project better than I do, so some of this may not be exactly applicable, but this will allow you to generalize event playback across your weapons, and still save EventReferences in relevant prefabs without having multiple EventEmitters on every weapon.

Regarding generic functionality, you won’t need to implement all of the capabilities of event management and interaction - if you’re not going to be tweaking parameters or using callbacks, then you don’t need to add that functionality to your script. That said, the StudioEventEmitter script was also designed to be an example of directly interacting with the FMOD API, so it should serve as a useful reference alongside the FMOD Unity Scripting API Reference, FMOD Unity Scripting Examples, and the FMOD Studio API Documentation.

Hope this helps!

1 Like

To be honest, until we have interesting gameplay for at least 30 minutes, gameplay mechanics are a high priority.

I will make the sound in the most stupid way, each sound has its own EventEmitter.

And then, when the game is better, I will return to this forum, re-read your message, understand more deeply and do everything according to your advice.

Thanks for helping me decide) I’m glad that FMOD has feedback. Make a discord, I’ll join!

1 Like