Initial Bike Audio Implementation
The implementation of the bike audio has been an iterative process beginning with the very first sprint, from compiling the bank of audio snippets to the implementation and modifications that have happened to date.
The code implements many "Branch" nodes which act as boolean IF statements ( Figure 1.0 ), in tandem with some of Ronan's hovercar code to check whether or not the bike is touching the ground. This is used to decide what sounds should be played at certain times. For instance pedaling sounds, terrain sounds and braking sounds are only played if the Bike is touching the grounds, whereas the coasting sound can play either on the ground or in the are as the wheels will be spinning either way while the bike is moving.
The initial implementation used hard plays and stops that lead to problems whereby the sound would cut off suddenly under certain situations and start abruptly, examples of this would be the crash and when a person restarts pedaling. The fix for this was simple, applying a fade out that happens at the same time as a new sound begins to play as can be seen in Figure 1.1 prevented any breaks in the audio.
Another problem posed was that the implementation currently used which uses button presses and releases to play and stop sounds ( Figure 1.0 ) meant that if a player held down a button before the starter had finished and they were able to move none of the bike sounds would play until the first time that the player stopped pedaling. This was fixed in the alpha release early on by implementing a boolean variable check. Such a simple fix worked because the pedaling sounds was the only sound affected by this bug.
The crash sounds implementation is implemented as a sequence of steps. The bike code which checks whether or not the bike is crashing is constantly being checked and as such simply activating a sound when the crashing is true was not feasible as this would mean the crash sound would be activated every tick and not play in its entirety. To get around this there is a "falling" boolean in the hoverbike blueprint that is defaulted at false.
When the blueprint first detects that the player is crashing the boolean is checked. ( Figure 1.1 )If it is false then a sequence is activated that does a number of things which will be outlined momentarily. If it is true the the chain is broken there as the game recognizes now that the player is currently in the act of falling or has already fallen.
When the game has determined that the player has begun falling there is a sequence of 6 actions that takes place, the first 2 actions are to immediately stop the sound of the bike pedals and terrain sounds. The next action is to gradually fade out the sound of the bike wheels spinning. The fourth is to play the actual crash sound. The last 2 are to set the booleans for falling and to disable the bike controls.
When the bike is reset to the track these booleans are changed back to allow the cycle to be repeated.
Finish Line Crowds
The crowd implementation happened in two stages. The first which was completed for Proof of Concept being the main finish-line crowd. This crowd is a looping sound cue activated by a trigger box halfway down the track. The sound has a large attenuation sphere which allows it to fade in gradually as the player nears the finish line. The reaction of the crowd then changes based on the players finishing time. ( Figure 1.2 ) Currently the time check is a fixed number of seconds but going forward to beta the sound will be based off either a local high score or the high score on the world leader board. These actions are performed in a StageIEBlueprint which handles all of the level specific crowds changes.
After the sound has been played a custom event in hovercar blueprint is activated following a delay that stops the bike sounds from playing and disables the bike controls to stop the player wandering off after finishing the level.
The second stage of crowd implementation was developed for the Alpha release. These various implementations are all very similar using various sound cues based on track position and number of crowd actors present. These are all activated in the same way the actor animation are by trigger volumes placed before the bike passes the actors so the sound plays in time with the animations. The sounds have a spatial attenuation so if the player is going slower he will hear the crowd until he is out of earshot which would be a longer time than if he was travelling fast. These sounds can be seen in the alpha demo video in the Development Progression section.
For the terrain Implementation I am still not happy with the way i have implemented it and continue my search for a better alternative. It is currently using trigger volumes that change an enumerator in the hovercar to either grass, gravel, stone or platform and play the corresponding sound when the player starts pedaling or a change in terrain is detected. This can be seen in Figure 1.3 but expect to see an updated version in the future
Volume / Sound Classes
For our game I wanted the sound levels to be fully customizable as we would expect to be the case in any major game release nowadays. For this I organised all sounds into a hierarchy of sounds classes as can be seen in Figure 1.5. This allowed me to change the values of the volume of a number of sounds at one time. However, with unreal blueprints there is no way to dynamically change the volume of an individual class that I could find. Therefore I looked externally to a plugin called Victory Plugin that can be seen in Figure 1.4 which gave me this access.
Moving from Proof of Concept to Alpha one of the main tasked I had been assigned was to cut down the size of audio files in the project. The simplest and most effective change that I made was to take the large audio file that was being used for the forest ambience that was about 80MB and replace it with 10 smaller files of around 3-5MB each and use them to make a completely random ambience every time the game is played. The sound cue that I developed to implement this can be seen in the adjacent video that shows each random choice in 2 sound banks, being mixed over each other. The different lengths of each clip also adds to the randomness of the ambience.
Advanced Bike Implementation
For the advanced version of the bike audio I worked on linking the speed of the bike to the audio being output. I worked with three different speed levels taking the bikes maximum linear velocity to be about 1500 and set the 3 ranges to be 0-500, 500-1000 and 1000+. The sounds recorded reflect a significant increase in speed of the particular sound in the case of the example in Figure 1.6 the pedaling sound. The sound wave in the sound cue is then changed based on changes to speed. The branch prevents the sound restarting the sound every update if the speed hasn't changed ranges.