I’m after the best way to stop/pause an event between music pieces.
Currently, I’ve setup a series of events - one event for each location, with all the music for each location in its respective event.
For each event, I have a parameter ‘progress’ which defines where we are in the level, so in the screenshot here, when the progress parameter changes from Grayle Mansion to LiftAppears, we transition to the LiftAppears sting.
The problem I have now, is that this marks the end of that particular sequence. The music shouldn’t continue until the player enters the lift, at which point the Grayle Lift Start piece should play. But of course the playhead in FMOD carries straight on after LiftAppears and eventually plays Grayle Lift Start, regardless of whether the player has entered the lift or not.
So my question is: What’s the best/neatest way to implement a system like this, where I need to stop or pause the music timeline at certain points?
Instinctively, I’m tempted to add a looping region of silence with a transition to the next cue, which is only activated when the ‘progress’ parameter changes to ‘Grayle Lift Start’. Is this holding pattern loop idea an elegant solution or a hacky misuse of FMOD?
Is there something ready-made for situations like this?
Or - is this something better addressed at the code level? Maybe I should have one event for each complete piece of music rather than one event per level, even though that would mean hundreds of events rather than 15.
Ideally I’d like everything to be as functional/workable in FMOD as possible so I can test everything there in a self-contained environment.
Your instinct is correct. Logic markers with conditions are designed for this purpose, and are an effective tool for the job. For a simple example of logic markers being used in this way, look at the “Music/Level 01” event in the “examples.fspro” project that comes included in every copy of FMOD Studio.
You could also achieve the same behavior though other methods (sustain points, for example, or using multiple events as you suggested), but logic markers with trigger conditions are much more flexible when used to define complex musical sequences such as those used in your game.
Is there any general sense of where separate events would make more sense than having the whole level/location in one event, with multiple looping sequences, stings, and looping silent pauses?
I’m presuming the more ‘dynamically interactive’ the music is across the level as a whole (eg, it’s possible to transition from music loop 17 to music loop 2, despite there being multiple silences/pauses in between those loops) , the more sensible it is to have all of that music in a single event?
Whereas if, for example, halfway through the level, the music comes to an end as you walk through a door which makes the first half of the level inaccessible. The music starts up again as you enter a room. In that case, would it make more sense to have the music for the first half of the level as one event, and the second half of the level as a separate event?
There are four conflicting and interrelated pressures that you should take into account when determining how to split your audio up into events.
The first is resources.
Events that use a lot of large assets consume more memory and take longer to load than events that contain one short asset, and events that contain a lot of tracks and effects require more CPU time than events that contain none. There is therefore a benefit to splitting your game’s audio up into as many events as possible.
The second is behavior.
An event is a unit of defined content and behavior, and that means that if you want one piece of audio content to interact with another piece of audio content, those two pieces of content have to be in the same event. There’s a benefit to making events that contain pieces of content that are related, even if that relationship is “these things should never play at the same time.”
The third is manageability.
If there’s two instruments that always need to be triggered together and always share a location when they do, it’s probably worth building them into the same event. Making them into one event instead of two will reduce the amount of code required to call them, and reduce clutter in FMOD Studio’s browsers. On the other hand, combining multiple pieces of unrelated content into an event makes the project harder to navigate, understand, and use in-game, so making a project easy to understand, navigate, and manage requires you to strike a balance. The best guideline is to think in terms of, well, “events:” Distinct happenings within your game’s world or UI that cause something audible to happen. If two things happen in the same place at the same time for the same reason, or share a cause-and-effect relationship, making them part of the same event will usually make them conceptually easier to manage.
The fourth and final pressure on how your game’s content is divided into events is your development team’s structure.
FMOD’s documentation occasionally talks about “the sound designer” and “the audio programmer” as if they were two different people, but that’s not the only way a team can be organised. In some teams, they’re the same person, while others might have multiple sound designers, each responsible for different parts of the game’s audio, or audio programmers that have other responsibilities outside of audio programming. Knowing how your team is structured and divides up labour is important, because the way content is divided up into events affects how much work different members of your team will have to do.
It’s easy, for example, for a sound designer to create a very large number of events, or to otherwise crate events that require a lot of input from the game to function correctly. This puts a burden on their audio programmer to write code that creates and plays instances of those events, and makes it more likely that subsequent changes to the game’s sound design will require the audio programmer to make changes to the code. By contrast, if a sound designer creates events with complex behavior and internal logic that only require minimal input about the game state to work properly, the audio programmer will not have to do as much work handling and maintaining your game’s audio - but if they ever want to make changes to how the game’s audio behaves, they’ll have only limited ways they can do that by using code, and so will have to get the help of a sound designer.
Exactly how roles are defined, and how easily different team members can work together, both vary hugely from team to team, so the effect that they have on how your events are designed can vary.
Every game has unique requirements and a unique development team, so there is no one “best way” to divide up your project into events. The only option is to weigh up the concerns I mentioned above, and do whatever seems best for your game.
Thanks Joseph - this is hugely helpful, and it broadly describes the path we’ve taken with the music design & reinforces the reasoning behind it. Thank you for taking the time to explain this in such depth - I hope other people find it as useful as I have!
