I was doing this for a level of convenience, but I’m starting to realize that there are cases where this might not perform or behave ideally and I wanted to double check. Here’s my use case:
I have a simple elevator that moves up about the character’s height to the next level, and stays there until you use it again. Nothing about the art or anything needs an idle sound, but I did decide that it should have a different sound for up as it does for down.
Quick relevant tangent: Elsewhere we have objects that can be rolled, which roll as far as they can before hitting a wall. Before implementing FMOD we had a separate sound for rolling and for hitting something, but once FMOD was in I realized I could move the hit sound to the same event and just play it when it exits the loop when stop is called.
So for the elevator, I figured it would work to have the same format, except the loop isn’t for moving, it’s for sitting at the second level. So I figured it would be efficient to have just one FMOD event that plays the up sound when it starts moving, which ends when it gets to a loop region with nothing in it. Then for going back down it just exits that loop immediately and plays the downward sound. Exact same logic as something that rolls.
But I started thinking about certain situations where that implementation might break and I’m wondering if that approach is considered a bad practice for those reasons. They are:
- If the game is saved while the elevator is in the up position, when it is loaded again, will the event playback still be in the loop region and not have to start again? (preferably silently, but I don’t have a reason to expect that)
- Is there any significant performance cost to having something play silently far away that’s not needed anymore? I feel like there might not be since FMOD already handles the voice count in a really intelligent way, and it’s playing actual silence, so I doubt that system would have any issue deciding it’s not important.
- If that part of the level is unloaded by our culling system, does FMOD provide an easy way to save the entire state of that event instance to be recalled back later when it is turned back on? But that’s the thing, it’s not actually “turned back on”. It’s been removed entirely, so actually it’s essentially doing everything that it does when instantiated from scratch on an empty game object. All the components are added fresh in their default state, and all its previous properties are then set to what they were before. Or at least that’s what we’re programming the system to do. Does the FMOD API include anything that can handle that saving and reloading of all properties for us or at least some of it?
Are these the best practice related reasons that I should just use two events, one for up and one for down? The only reason I’m asking questions (that could easily not even need to be asked in the first place) about something so simple if I just did with two events is because I’m kind of trying to learn the ways that are best to do by default every time. And one thing that I do know is usually a best practice is:
“When deciding between more than one way to achieve the same result and all else is equal, pick the option that uses fewer events.”
At least that’s what I’ve been told. But I’m realizing now that I only ever just accepted it since it makes intuitive sense. So maybe the real question here is: is opting for a lower event count when everything else doesn’t matter actually a best practice? And why or why not?
If event count doesn’t matter unless it involves more source assets (it doesn’t in my case), then I’m going to forget about those questions above and just use two events, but yeah, this is really about knowing the best way to do this for every time I do it in the future. After all, it can cut the event count in half for everything that needs this implementation.
Sorry for such a long post, but thank you.