Followup - Previous ScriptableObjects Post

I just wanted to make a quick followup to my last post where I was trying to demonstrate an interesting way to use ScriptableObjects. I was trying to make an Audio System that all my other game logic would tightly depend on. So when the game starts, it would pool a bunch of AudioSource game objects. And all things that would play numerous sound effects at a time would call a static function to use one of those pooled objects. And the objects would exist across all scenes in Unity. So if there is an issue that one object causes with the AudioSystem, and results in various other objects having audio issues, which may be hard to debug and isolate.

So after some thinking, I came up with a new way to go about doing the same thing that is a lot less centralized. This is my implementation.

Basically, Each object that wants to be able to play multiple sounds will make its own mini pool of sound sources to use. And you can pick how large the pool is. So now, if there is an issue, it’s isolated to the object that uses it.

The only reason I really made this MonoBehaviour is because I want to be able to play sound effects in rapid succession. And a SoundSource can only play one sound at once (which can be useful at times). So I made some simple logic to manage a small group of sound sources.

So If we ever have some item that makes many sounds very quickly, the sounds can play without cutting each other off (unless we exceed the total maximum voice limit).
For other things that don’t necessarily play sounds rapidly, I can still use a single sound source.

For example, kobolds and other npc’s can only ever make one “mouth sound” at a time. So it makes sense to just stick with a simple sound source. But the footstep sounds will definitely need more than one sound source.

Anyway, this is all I wanted to say. Thanks again for reading!

Previous
Previous

Set Size Based on Text Metrics (in Unity Engine)

Next
Next

ScriptableObjects Will Ease Your Sorrows