0
0

Hi.

I’m just trying to better understand how multiple parameters interact and the best approach to a certain problem. For lack of a better term I am referring to this as ‘nested paramters’.

I’ll start by describing what I’m trying to do.

We are implementing a footstep system where we will need to choose between different footstep sounds based on the surface that characters are walking upon. For this example let’s say there are three possible surfaces – dirt, wood, and metal.

Let’s also assume that within each of these three categories there may be other soundsets based on the speed at which the character is walking…such as slow walk on dirt, jog on dirt, fast running on dirt, etc. So in essence I am creating a matrix.

Originally I was thinking that the surface type will be dedicated to a parameter – i.e. 1=dirt, 2=wood, 3=metal. Can I then assign a second parameter to the same event, such as speed, to correctly choose between these further subcategories? Based on how the graphical paramter interface looks, it doesn’t seem like it would work, but correct me if I’m wrong.

The other, more obvious manner to accomplish this would be to have each surface type have it’s own dedicated event. And then within each of these events have a single parameter determine the speed.

I’m not sure which method is preferred (or even if the first method, with the multiple ‘nested paramters’ creating a matrix is possible). This matrix style would seem to be very compact, efficient, and would cover a lot of ground within a single event. Is this how most would approach this problem?

Any suggestions?

• You must to post comments
0
0

[quote="Flying Poo":35xqzu9p]Hi.

Any suggestions?[/quote:35xqzu9p]

This will provide you with your ‘matrix’:

1 event
1 layer
1 parameter for speed.

3 (or more) sound definitions for running sounds.

Each sound definition:
* represents a running speed (walk, jog, run, etc) and would be arranged from slowest to fastest on the Layer.
* contains mulitple sounds for each surface type
* use a play mode of ‘Programmer Selected’ which allows the programmer to selected the appropriate surface at runtime.

…the limitation I see with this method is, creating variation to a particular scenario (slow on dirt for example). You might be limited to volume, and pitch randomization.

Do you want a smooth transition between the speeds? If not, then separate running speeds could be events, with a parameter for surface.

Another (more expensive) way is too eliminate the ‘speed’ variable all together! If you make a left foot event and a right foot event and trigger the event, each time the step animation occurs..the speed of the footsteps sounds will change speed automatically! This way so only need to handle the surface as a parameter.

Anyone else got any ideas?

cheers,
Templar

• You must to post comments
0
0

As I read it, speed in FP’s example is not so much an issue of timing footfall sounds to variable-rate animation loops as it is a sonic distinction between the actual sounds of footfalls for multiple paces of gait. A slow, cautious footstep sounds radically different from that of a normal walking or running gait. As such, it is a given that separate event plays are triggered at each footfall down point in the movement animations.

The Programmer Selected mode as it exists today in part originates from a feature request to support this very case. [url:3g91090v]http://www.fmod.org/forum/viewtopic.php?p=26010&highlight=#26010[/url:3g91090v] I had additionally requested a selection index parameter to allow filtering sound definition playback candidates; for instance if the index parameter is 3, then only sound definitions assigned an index value of 3 would be eligible candidates to play randomly or sequentially. Hopefully Firelight will reconsider this someday; for now Programmer Selected is enough to implement the matrix you are proposing.

With game programmer support you can create a complex matrix selection event where one event layer has one sound definition containing all candidates. The programmer will create the matrix in code, assigning material and speed(gait) values for each wave in the sound definition. The wave list must always match the matrix in code. As the event plays, the game code gets a call from fmod to pick the wave and the programmers code can then do the random selection of all eligible wave candidates that match the current values for material and speed. This or some variation of it could accomplish what you seek. (For instance multiple sound definitions for speed, each with programmer selected for material.)

Unfortunately not everyone gets this level of game programmer support on a project, so the more features like this that can be data-driven, the better as the event system is all about empowering the sound designers and minimizing the need for programmer customization.

-jason

• You must to post comments
0
0

Thank you Jason and Templar,

Jason, you are correct in assuming my inquiry was not related to the synchronization of things. We already have it so individual footsteps play in sync with the animation. So when the character speeds up, so do his footsteps. And in many cases this will be sufficient, even for changing speeds. But as you mentioned, there are certain circumstances where simply slowing down or speeding up the frequency of the steps isn’t good enough. Creeping up on something requires a totally different sound than chasing something at full speed, and this is why a matrix would work well.

Your suggestions are great. We will hopefully try them out. I wasn’t quite sure what or how the ‘programmer selected’ option was to be implemented.

Any other suggestions welcome!

Thanks,

FP

• You must to post comments
0
0

you could also do this just with multiple layers and 2 parameters.

set each layer with multiple sound definitions for speeds, controlled by one parameter. (layer the sounds from left to right as low, med,high or whatever)

then add a volume effect to each layer, controlled by the material type parameter, and setup the volume curve on each layer so it is at unity for part of the range and at 0 for the rest of it, then do the same for the other layers but alternate where they are at unity. so the volume is controlling which layer is playing for the material type while the other parameter lets you select which sound is used based on speed.

i think this way is maybe easier to setup and test in the designer, but this solution is probably less memory and cpu efficient than doing with programmer sounds since you are essentially playing all of the sounds for each type at once and then just turning down the volume on the ones you don’t want.

• You must to post comments
Showing 4 results