Footstep Problems

When programmers are asked to implement footstep audio, there are obvious requirements and no-so-obvious ones. Do your footstep solution have what it takes to solve all of them?

Step variations

The most common requirement is that the step sound should be cycled or randomized among several similar but not exactly the same sounds. Naive implementation can be as easy as stepClips[Random.range(0, stepClips.Length)] to pick one AudioClip from candidates.

But if you do that and listen to the result, there are some problems. For example, it doesn't sounds nice if it randoms into the same sound in a row! (The real nature got infinite amount of AudioClip and doesn't have this problem.)

In response to this, sequential picking may sounds better and correlates more with the feel of 2-foot if you have 2 sounds total.

Programmer may want to use an another kind of sequence, such as [A B A C] [A B A C] ... when you got 3 clips but you would like the feel of see-sawing between variations. Therefore, plugin must be able to provide any length of custom sequence.

What if you prefer the chaos of randomization rather than sequential in the case that you have got more AudioClip? Only that the same random in a row problem is in the way. How to fix this is simply remember the previous random and exclude it out of the next random. (With 2 clips, it turns in to see-saw sequential.) A more generic way is to think that "remember" as a size-1 exclusion queue. A plugin must provide an adjustable size of this queue.

Modular Footstep can solve these problems. In addition to random/sequential programming choices, the picked clip has even more option to scale its volume to a specific value or even randomize from a range. This is to bring it in line with its candidates, and provide even more variety with volume range.

Surface switch

All those steps variations settings are only local in one kind of surface. The plugin must be able to switch the surface mid-walk, and now we get a new set of candidates to randomized/picked sequentially from.

Many plugins offer to literally integrate with the surface (that has collision for walking on, etc.). Modular Footstep simply use a ScriptableObject as a representation of one surface type. You can change the surface via scripting anytime you want manually.

2 modes : Interval or step-by-step

An absolutely realistic footstep audio playing would be play one-shot at the moment the character's foot touched the surface! This is the basis of all the "animation/IK/terrain integration" that all other plugins but Modular Footstep are providing.

But many many genre or look of games won't require that level of realism. A simpler version would be playing each step in fixed interval. This interval perhaps can be changed in real time for more control.

In interval play, we need an offset/delay so it doesn't start the interval immediately. The reason is because when character walk it would first lift the foot without step sound, playing the step immediately would make the interval loop in wrong phase. The offset correct this and line up the interval more with the animation.

Modular Footstep's source supports 2 ways of playing, named interval play and one-shot play. Interval play involves calling start, update parameters while it is running, and stop. One shot play the step once, you are in charge of calling it repeatedly whenever you want.

The "integration" with any of animation or terrain (either Unity or your in-house one) is therefore you calling either start-stop interval or calling each shot. It's your choice.

This separation of 2 modes do increase specificness of the plugin, a bit aginst the modular concept of this plugin. (Because the one-shot mode can be used to implement interval mode if you try hard enough.) But interval mode has many optimization built in that justifies it being a separated mode. Such as the singleton interval scheduler able to run all stepping things in the scene saving you update loops.

Step-respecting API

An overly naive implementation is to loop 1 AudioClip containing several steps, or even a single step followed with some silence.

Not only that you can't adjust the interval anymore since everything is baked in the audio wave, if you stop it, it is very likely that it will be mid-step. Cutting out step audio like that immediately when player lift up walk button sounds very irritating!

We call something like this that the solution is not respecting that each step is an individual thing.

It is a bit more than that, though! When combined with mentioned interval mode, sometimes we need to "disrespect" the step.

Take this example : The player held down walk button in a cartoonish 2D platformer. Programmer think interval mode is enough, so just call start interval with appropriate offset to make it sync with visual. Whenever the player lift up the the walk button, programmer call "stop interval" with respect to step so the last lingering step audio is played to the end even if character on screen already stopped.

But what if instead of releasing the walk button, the player press jump while walking? The correct sound should be calling "stop interval" disrespecting the step! The cut off of lingering step sound, combined with one-shotting of the jump sound on that surface at the same time is the right sound.

Modular Footstep know these weird requirements, and has many API that can both queue up the change to be applied on the next step, or immediately take effect as you like!

Lifts

Recorded footstep of walk/run loop sometimes have more pronouced "lifts", such as when walking in tall grass. If you still use 1 AudioClip as "one step", the lift is either on the left or on the right of attack point of the audio. Neither is ideal, as stopping in wrong place can make it sounds like it is not respecting the step unit enough.

Once you decided to divide the walk loop into stepping down and lift up, the player script must be able to handle that kind of alternating play as well. The most ideal is so the downsteps and the lifts to have its own memory state. (e.g. Random exclusion that prevents the same lift clip to be picked aren't forgotten even though it alternates playing downsteps.)

Moving source or left-behind source

An even more absolutely realistic way of footstep play is the AudioSource must be spawned and dropped behind on the floor on every step. What we get from this effort is the realism on positional AudioSource vs. AudioListener, the steps came from the floor rather than working like we attach an invisible loudspeaker on the walker's shoes.

Modular Footstep has strong opinion on this one that it is overkill. The walk be it interval or one-shot is under assumption that there is only 1 source for that walker rather than spawned.

With that assumption, we have got several optimization possible in Unity such as stopping or not stopping that one source to cut off the audio as desired. Of course less source for Unity to mix down or not having to instantiate left-behind source is performance improvement on its own.

Attack calibration

Footstep's attack point in the clip is not necessarity right at the beginning of the clip. Walking in tall grass has a lot of ramping up before you hear the attack of the step.

If you play those clips naively, it will sounds like the step is a bit delayed from intended point. This can really be a problem combined with random variations where different clip has different offset where the attack is in the clip. Constant interval now sounds like the character hurt their legs and has irregular interval.

Solution is to move the clip backwards in time individually to line up the attacks. This is where "interval play mode" has advantage because it knows an interval ahead of time and can move backwards as much as interval allows.

For plugins that offer one-shot integration such as keyframing into the animation or play whenever collision to the surface is detected, it cannot move back in time anymore unless you really move back the calling point.

Non-audio footstep problems

Footsteps are also often related to animation, collision, terrain, and even step marks or dust particles.

I understand that those are needed, but Modular Footstep is a pure footstep audio scripting package. It intentionally not providing those things in order to make the API compact and modular.

Next

Now that you know all these intricacies, let's see how Modular Footstep solve them with FootstepBehaviour and a set of 4 resolving assets.