Whaaaat ? No post this week ? Let me fix this issue!
Today we are going to talk a little bit about sounds. I warn you: I’m not a sound programmer so maybe this technical article will exasperate real sound programmer!
> Sounds until now
Since the beginning of Seasons development, we don’t really care about sound part. The only sound pass we did was done by William during the 1st prototype conception. During this prototype, sounds were only 8 bits effects done with the excellent sfxr software.
To move on with the new prototype, we need new sounds (effects and background musics). The sounds need to be less “8 bits style” but more realistic!
> New kinds of sounds
We have two kinds of sounds: spacial sounds and ambient sounds.
The volume of spatial sounds change depending on the distance that separates them from the sound listener (a kind of microphone).
Ambient sounds are sounds you can hear everywhere with the same volume, independently of the sound listener position.
Here is a little recap with a diagram showing 2 levels. One of them has a spatial sound placed in it and the other one has an ambient sound. The levels are linked by a gate system.
As you an see, a spatial sound has 3 main characteristics:
– a position: this is where the sound is emitted
– an inner radius (in yellow). If the distance between the sound listener (microphone) and the sound position is smaller than the inner radius, then the sound is perfectly audible (100% of its maximum volume)
– an outer radius (in orange). When the distance between the sound listener and the sound position is between inner and outer radius, the sound is audible but not at maximum. There is an attenuation of the sound: the bigger is the distance, the lesser the sound is hearable. When the distance exceeds outer radius, the sound is not audible anymore.
Some software audio library handles spatial sounds. It’s the case of our actual audio library (irrklang). Unfortunately, the library doesn’t let us have a real control on when a spatial sound will be totally muted. The only parameter that we can tweak is an outer distance beyond which the sound is not reduced anymore.
By testing those “3D sounds”, it appears that they were audible from way too far.
So we had to use classical 2D sounds and let our engine tweaks volume and pan to make our own “3D sounds” by using “2D sounds”.
Ambient sounds specificities
Ambient sounds are regular 2D sounds audible from everywhere. However we limited an ambient sound to a given level. An ambient sound doesn’t survive when the player goes from a level to another.
An ambient sound always loops so we can use them to put an audio background in the level.
All this profusion of technical sentences is great, but a little video will be better to illustrate that stuff.
Just a warn before you proceed: all sounds are work-in-progress. And don’t search the stereo effect: the software used to capture the sequence encodes sound in mono!
Here is what you can see in this short video:
– a rainy ambient sound is playing (even if there is no rain FX, it’s a rough testing level)
– a sound crossfade occurs when the player goes from spring to fall
– the mill plays a sound that loops when it starts rotating
– the sound emitted by the mill is spatial. When the fox is far away, the sound is very low. At the opposite, when the fox is near the mill, the sound gets louder.
– when the fox is walking, some step sounds are played in a synchronized way
– when the fox goes from a level to another, a crossfade occurs and the ambient background changes.
> Backstage: Blender!
The most curious of you may want to know how it works in our “production pipeline”. Well, we wanted the system to be as generic as possible. All the magic is done in Blender (William’s favorite tool of all time). Let’s see how it works with both mill and fox.
At the top-left part of the picture is the 3D View where a red speaker symbol has been spawned. This little red thing is just an editing visual clue of where the sound is positioned and it’s not visible in the game.
Blender doesn’t handle sounds in the way we want, except in the Blender game engine (that we don’t use). To indicate that the little red speaker thing is a sound, we programmed an new Blender component called “SSSSound” (yeah that’s a lot of “S”). You can see that this component is applied to the red speaker at the bottom part of the picture.
There is a bunch of parameters in the component. Here you can see that the sound is a spatial sound audible at 8 meters from its position, and the maximum volume level is reached when we are 4 meters (or less) away from it.
The sound must be played only when the mill is moving. To specify this constraint, we need to have a “thing” capable of triggering sounds to put them in play or pause state depending on the animation state. This “thing” is materialized in Blender by the addition of a new sequence in the sequence editor: the “Sound Trigger Area”. This is what you can see at the right part of the picture (the green rectangle).
This “Snd Trigger Area” sequence will start a loop sound if the animation is playing in the interval of the sequence (between left and right handles of the sequence). Here the sequence takes the whole animation timeline so the sound must be triggered.
Obviously, if the animation stops then the playing sound triggered by this sequence will be stopped.
The sounds triggered by this type of sequence must be loop sounds. For the “not loop” sounds, we introduced a second kind of sequence in the sequence editor…
The fox emits a little step sound every time his legs hit the ground. This step sounds are not loops and they will be triggered by the “Sound Trigger Start” sequence bloc.
This is pretty the same configuration than the mill case, except that the sequence type has changed.
You can see that 2 “Sound Trigger Start” sequences have been created in the sequence editor. The 1st sequence in the timeline corresponds to the front legs hitting the ground and the 2nd sequence corresponds to the rear legs hitting the ground. Each sequence triggers a sound when the animation is playing and just entering the sequence bloc.
The length of a “Sound Trigger Start” sequence bloc is not important. What we care about is the left handle position of a given sequence bloc.
> To conclude
The actual implemented system is very rough but it’s working, and it’s convenient because most of the sounds behaviors can be determined directly in our editor without having to add scripts in the game engine.
However, there is some improvements to bring. Like a better integration of pan (left/right speaker repartition of a spatial sound) and extra diffusion shape for spatial sound. Right now, spatial sounds use a circle shape but if we need more vertical height or horizontality, maybe it could be a good idea to have some capsule shapes like the following one.
To see if we need those capsules thing, we have to test and tweak sounds in real levels because my testing levels are pretty limited in term of level design!
Don’t hesitate to share your sound experience with us (in terms of tools, or sound paradigm). Maybe there is a better way to integrate and use sounds than the one we are following, so any experience feedback will be great. I’m not a sound programmer, so I have a lot to learn from you!