I’m wondering if I could get some advice on the best way to go about implementing this!
So, the idea is when the player is at 10% health, an alarm sound effect will go off, and the music will go up in tempo and pitch over a half a second or so (like a sort of revving up).
This next part is an idea to try out, but is less certain that we’ll actually implement it: from 5% and lower, the tempo and pitch will keep rising until the player dies (or doesn’t, in which it’ll go back to the base state).
I suppose my issue is, I’ll need to add some sort of way to do a delay (in case a player passes under 10% for only a small amount of time) or a cooldown (in case a player passes above 10% for only a small amount of time) to avoid quick drastic changes in and back.
I’ve tried implementing this with both a continuous parameter and an automation curve on the Stereo Out pitch (with a command instrument to get the alarm to go at 10%) as well as with a labeled parameter and an AHDSR curve going into the “Danger Zone” that’s set in Unity (also with a command instrument to get the alarm to go off when switching into the Danger Zone). These function, granted without the delay/cooldown element.
I’m wondering whether one of these two implementation techniques makes the most sense here, and how to go about putting the delay/cooldown element in, or if there’s perhaps another way to do this that would make more sense. Thanks so much for your help!
Hi!
To better help you out, can I get a little more info on how your event is set up, and how you’re handling the transition between the standard music and the 10% health danger zone? Some pictures of the event, or video demonstrating it, would be great.
Absolutely! So, here are the two ways I’ve implemented it:
The first way is with a continuous parameter called City_Health that goes from 0-1, 1 being full health, and 0 being 0 health. I’ve used the parameter as a curve on the Master track’s Pitch property- it’s pretty small and kinda hard to see, but at 0.1 the pitch goes up a bit, and then it does so again right when we’re close to 0.
The second way, and the way that I feeeel like would be easier in terms of doing a delay sort of thing but honestly am not sure, is using a separate labeled parameter called City_ZoneChange with two labels, Normal and Danger Zone (which is linked to 10% health and under). There’s an AHDSR on the Master track’s Pitch property, and then automation using the parameter on the AHDSR’s sustain. Right now everything else is on default values, but the idea is to be able to use the attack and release to control the timing of the ramp up and ramp down when we go into and out of the Danger Zone (if that makes sense to you- there might be better ways to do this!)
These both seem to work, but I’m unsure of how to add in a delay sort of thing (as in, only change the parameter if we’re 10% or under for X seconds, and vice versa, only change back to normal if we’re above 10% for X seconds) so the audio won’t go back and forth in a short period of time. There likewise might be an entirely different way to do this plus the delay aspect that I haven’t thought of- I’m totally flexible in terms of the best way to implement this! If it’s possible to keep it in fmod that would be great, but if it makes more sense to do things in unity, that’s definitely possible too.
Thanks so much!
Thanks for the extra info!
Handling a cooldown on the engine side of things would probably be “simpler” on paper, but I definitely understand the desire to abstract as much of the run-time audio logic away as possible to handle it design-time in the FMOD Studio project, since that abstraction is Studio’s main purpose.
Implementing a cooldown purely on the FMOD side of things is possible, but depending on your workflow and project structure may not be trivial. The most practical and customizable way to do it is by using event instruments to play a timeline with a command instruments after an amount of time, which updates a health state parameter.
For example, if you were to have 3 discrete health states, you could do something like the following:
- Create a “Player Health” continuous parameter, that represents the current value of the player’s health
- Create a global “Health State” (which I have called “LowHealth”) discrete parameter with 3 values, which will represent the OK, low health, and danger zone health states
- Create 3 “cooldown” events, one for each health state, with a command instrument placed on a timeline that sets the “Health State” parameter to the corresponding state after a certain amount of time:
-
Create an “Player Health” event with a parameter sheet for the “Player Health” parameter, and enable “Persistent”
-
Place each of the “Cooldown” events on the sheet in their respective health ranges, and make sure they all have “cut” enabled and have a inverted trigger condition set to their corresponding “Health State” paremeter value:
Using this setup, when the “Player Health” parameter is set to a value that is in a different health state range via the API, the corresponding cooldown event in the “Player Health” event will trigger:
- If the cooldown event plays long enough reaches its command instrument, it will update the “Health State” parameter’.
- If the player’s health moves out of that health state before the cooldown event reaches its command instrument, the cooldown event will untrigger due to “Cut” being enabled, and the health state will not be changed.
From there, since the “Health State” parameter is global, you can automate the pitch on your music events using it. You can ramp the pitch smoothly by also modulating the pitch with a “Seek” modulator (2.03 only).
Here’s a video demonstrating this setup:
This is admittedly a little complex to describe by text, so please let me know if you have any questions or run into any issues adapting it for your project!
You are the beeeest this absolutely works! Thank you so much, I really appreciate it!
1 Like
No problem! Feel free to let us know if you have any other questions, or run into any issues.
