This project was created purely as a means of showcasing an array of sound design solutions to a magic combat game and to provide evidence of my audio programming abilities using Unreal Engine 4 and Wwise.
As can be heard in the capture above all abilities within this project comprise of a 'draw' sound, a looping 'idle' sound and the ability attack sound. The draw and idle sounds are called from two Wwise events, each playing their respective switch containers. The switch containers hold random containers for each 'draw' sound and blend tracks for each 'idle' loop. The sounds are associated to their appropriate switch using the contents editor.
The abilities are equipped to the character using the number keys 1 through to 0, each of these input actions calls an index number between 0 and 9, the get function in the picture below uses this index variable to call the ability name within the array that correlates to that index value, the name it outputs is used to set the switch, the switch names in Wwise are exactly the same as within this array to allow the set switch node to communicate these inputs to the switch.
The arena within this map where the play can fight against AI opponents comprises of two rooms, each have been provided with a spatial audio volume to introduce a reverb onto all sound effects that use game-defined auxiliary sends, each spatial audio volume is set to room to replicate the acoustics relationship between sound and emitter when in different rooms. A spatial audio portal is used to connect these rooms and define the size of the opening between the two rooms. Both the obstruction and occlusion parameters within Wwise project settings have custom volume and low pass filter curves applied. The result can be seen in the video below.
The fireball ability audio system is also illustrated within this video. The attack sounds are comprised of multiple separate components, in the case of the fireball three parts are used; a cast or shoot sound, a sustained loop sound and a collision sound.
The sustained loop and collision sounds are called through the fireball projectiles blueprint in order to attach the loop to its mesh and post the hit sound when the projectile collides.
Two RTPC's (blueprint seen below) are used on the sustained loop attached to the fireball, replicating the sonic effect of the fireball in transit. The first controls the pitch of the looped sound based on the speed at which the projectile travels, The second RTPC, namely 'distance', controls the volume and filter curves for the looped 'in transit' sound, based on the distance from player pawn.
An attenuation curve is used to provide this same effect on the collision sound, which is called when the fireball collides and explodes. However the 'distance' RTPC is also used to affect the amount of reverb on the collision sound to improve the sense of realism, if the fireball collides on a surface which is nearby to the player, the reverb on this sound is far less present than if the fireball collides with a surface that is farther away.
The vortex (or tornado) ability is comprised again from a cast and loop component. The loop is made up from several vortex wind sounds created from manipulating wind recordings with a rotating doppler effect to achieve the circular motion as well as rocky earth crack sounds. The multiple wind sounds are situated within a blend track, it's crossfade, volume and filter RTPC's are defined by the distance of the particle effect from the player pawn, as the effect approaches the player the sound of the vortex becomes more present and detailed with wispier elements being prominent whilst when it is distant not only is it quieter and filtered but also the body of the vortex sound is more present and the detail of the sound is reduced.
To give a more defined sense of realism to the Electric Beam attack i intended to achieve a doppler shift effect on the loop based on the player pawns rotation speed. As seen in the screenshot below the players current rotation yaw is subtracted from the last known rotation yaw stored in the variable. This outputs a float value which is equivalent to that of the change in rotation speed consequently altering the pitch of the sound in relation to this value.
A state group was created to control a separate reverb bus's volume dependent on the current health of the player, shown in the screenshot below. As seen the volume of the bus is incrementally increased depending on which state the players health currently presides within. As the players health decreases the volume of the bus and therefore the amount of this reverb effect increases. The relevant state is state within the player blueprint when the players health falls below the threshold the new state is set.
To further exaggerate this effect a low pass filter is applied to the bus containing all ability effects so the last ability casted before the player dies is filtered upon death.
The videos below show a rundown of all abilities and an example of the combat within the finished project to illustrate as many of these examples as possible.