Dungeon Level editing - Footsteps 02

Some fundamental issues surrounding the footstep sounds in the level were highlighted previously (walk speed and step frequency).

After a substantial amount of research on the matter I found a video on YouTube which explained how to change the player walk speed, this had to be changed by editing the Unrealscript. Having very little knowledge of the syntax involved with Unrealscript has so far hindered much of the projects progress and is an area worth further reading. The video tutorial in this case was quite straight forward but before editing the script file a backup copy of the original was saved securely in case of any problems later.

Code for player movement speed

The line of code highlighted defines the player movement speed (originally at a value of 1.00). This was changed as shown which resulted in a more natural walking pace. This setting however did not affect the actual footstep sound playback rate which was still the same (jogging pace) as it was.

After more reading on the matter an answer was dug up on the Unreal Epic forum where someone else had had to deal with a similar issue. Again, the solution was within the Unrealscript.

Code for footstep playback frequency

The highlighted area shows the lines of code that had to be edited in order to slow the footstep sounds down to match the new walk speed. Although I am not entirely sure what the numbers represent at this time, some tweaking and testing has given the desired results.

More investigation is required into how the code functions as it would be great to somehow link the player speed to the footstep frequency, as it is intended that the player can walk, run and move whilst crouching. The next step in this phase of development will be to try and work out how to set up and link player movement whilst running and crouching to a specific sound cue. 

Dungeon level editing - Reverb Volumes 01

Using knowledge gained from The Game Audio Tutorial book I began to define some basic reverb volumes for the areas within the level. These volumes were created by using the builder brush to highlight areas of the game map and then define them as a reverb volume (area in which a reverb is applied when the player enters). Once the reverb volumes were created setting were available for adjustment such as reverb type (related to the type of space desired), volume of the reverb and fade time (time taken to fade in or out when the player enters or leaves the reverb volume). In cases where two or more volumes overlap a priority setting can be defined, this will make one volume take priority over another in such a situation.These settings were adjusted enough to sound authentic as possible given the limited number of preset reverb sounds available. This will provide a base to build upon and develop further but at this point gives an idea of how my own sounds will play back within the games environment.

Defining Reverb Volumes (highlighted in yellow)

Reverb Volume settings

Dungeon Level editing - Footsteps 01

Footsteps are arguably the most repetitive sound a player will hear in most first person games. Keeping them interesting and fresh whilst also varied is a tough challenge for a sound designer with very little memory allocation. If executed poorly the player may become distracted from actually playing and enjoying the game and thus breaking immersion. Even the prettiest graphics can't detract from annoying footstep sounds.

First step forward  

Footsteps within UDK are played back by detecting the foot collisions of the player whilst they move around. These collisions can only take place when an item in the game such as a static mesh reference a 'physical material' such as 'stone' or 'gravel' for example. In order to playback custom footstep sounds I firstly had to create a new physical material within UDK, this material could then be referenced by the floor mesh within the level. 

Physical material creation for a wooden floor

Once the floor mesh was referencing my new physical material (done using the material editor) then it could call the custom footstep sound cue associated with that physical material.

The footstep sound associated with the physical material had to be coded within the unrealscript by defining the new material and the path to the relevant sound cue.

Using some of the footstep recordings that were added to the assets I created the sound cue which was set to play back the footstep sound when walking on the wooden floor material around the level. This included breaking the step sounds up into heel and toe sections which were then married together using the concatenator node within the sound cue editor. Two random nodes were used to play back of heel and toe sounds as well as adding modulation nodes to both sets of sounds. This resulted in a great deal of variation in the footstep sounds being played back.

This was enhanced further by adding in some creaking floorboard sound effects which were also randomised and modulated.

This resulted in a much less repetitive footstep system, however at present, the pace at which the steps are played back are too fast for how I want the player to move. It sound more link a jogging speed and a walk is more desirable. There are no settings within the kismet that I have managed to find which can define the footstep playback frequency so this may be a coding problem to solve. The next task will be to resolve this issue before anymore footsteps are created.

Recording Session - Binaural Breathing

To enable a more intimate connection between the player and character, a breathing system is planned for the character which will change dynamically as the player navigates through the level.

Instead of traditionally recording breathing sounds directly into a microphone set up the decision has been made to use a set of in ear binaural microphones. this will capture the the sound of breathing from a perspective which is much more realistic and hopefully make the player tune into the mood of the character, leading to a greater sense of immersion.

The recordings were chopped up into inhale and exhale samples which will be imported into UDK and joined together randomly to create a varying breath sound.

[UPDATED] 25/04/15
I have eventually got round to uploading a sample of what was recorded.

Dungeon Escape Level - Level Sound Design

The overall design of the level with regards to appearance sets it firmly in the zone of a horror/suspense/adventure genre. The visual design will be capitalised to present a sound design which is both fitting and convincing. The sound will veer more on the horror and suspense elements but with the quest involving picking up treasure, finding items and opening timed gates it will enrol an adventure element too.
     

Story?

Previously the idea of a back story was presented to give the player information with regards to their location, why they are there and what they are supposed to do. This idea has been dropped for a couple of reasons. 

Firstly the creation of a story (one which is actually good enough to draw the player in) is an extra task that has not been planned for and feel at this stage it mat consume more time than is available. Also a story may give too much away to the player, it is preferred if they don't know what to expect. This way perhaps a greater level of tension can be achieved which brings me to the second point. 

If they player has no story to work with then they will be forced to subconsciously make some decisions about what is going on in the level. The idea is that the sound design of the level will force the player to paint a mental image of the story just how they imagine it. This is aimed to draw more of their attention to the game by forcing them to think about questions such as; Why am I here? What is going on?  Allowing them to become more immersed in the game. 

Picking up on the study by Brown & Cairns they state “If gamers need to attend to sound, as well as sight more effort is needed to be placed into the game. The more attention and effort invested, the more immersed a gamer can feel.” (Brown & Cairns. 2004, p. 3). 

Creating a threat

As mentioned in the level evaluation post the threat of an enemy is essential for creating tension. Physically placing a foe of some description in the level is a great idea, however without the assets for a suitable enemy (which fits the aesthetics of the level) such as some kind of monster character, this is not an option. This would also require a lot of extra time coding on my part to get an NPC functioning desirably.

The solution is to try and create a sense of threat through the use of audio which is more suitable to this project. The initial Idea is to try and use the camera actors within UDK to create a cut scene in which the player is viewing through the eyes of the threat (The threat will be defined as the beast from here on in). There will be a trigger point when the player gets to a certain location in the level that will cut the players view and switch to the view of the beast. The camera will simulate the beast moving through the level and towards the player location. Use of music and sound effects to signify the presence of the beast will help to inform the player of the imminent threat posed. 

To bolster the idea in the mind of the player that there is a beast some other sound solutions should also be considered. Such as moveable sounds using the UDK 'Matinee' which will allow the cue to be animated and shift location during game play. This will create a spatial sense that the beast is moving around the players location. 

Player Becoming the Character

A link needs to be made between the player and character so they really get a sense of being in their shoes so to speak. To achieve this a character breathing system will be devised where the characters breathing changes depending on the actions the player takes. The plan is to record breathing sounds using a pair of in ear binaural microphones with the aim of creating an illusion of the breath coming from the player. This approach should work better than mono cues (recorded face on to a microphone) which would play back with a sonic image of the character breathing in front of your face. 

Gameplay Feedback

Game play feedback sound will be used to give the player an audio cue which signifies that they have completed a task. These will be used in a non diegetic sense These sounds will include things like key/relic pick-ups, shifting walls and the placement of relics in the alter. most of the feedback sounds should be of a rewarding nature and encourage the player to keep playing and completing objectives.

References:

Brown, E. and Cairns, P. (2004). A Grounded Investigation of Game Immersion. Extended Abstracts of the 2004 Conference on Human Factors and Computing Systems, Vienna April 24-29 2004. New York: ACM. pp. 1297-1300. [online]. Available from: http://www-users.cs.york.ac.uk/~pcairns/papers/Immersion.pdf [Accessed 1st November 2014]

  

Level Sound Categorisation (IZEA)

Following the investigation into the IZEA Framework I have complied a list of all sounds which will be used in game and mapped them within the IZEA.

This has helped to formulate exactly where and how the audio assets will be used and interacted with. This framework will be used a referencing guide as the implementation phase develops.

Dungeon Level editing - 01

I began to make some adjustments to the dungeon level to make it more suitable for the project. The first task was to strip all existing audio from the level to make way for the custom sound design, this included deleting all visible sound nodes from the map as well as those which were triggered from within the Kismet.

Side view of UDK map

Top down view of UDK map

To enhance the horror genre and incite the threat of death some blood detail was added throughout the dungeon using the UDK editing tools.

Blood detail next to a switch gives the impression that someone has been here before and failed to escape alive

More blood trails with hand prints tells the player someone had a bloody struggle.

As described in the level evaluation some switches and hidden pathways are very difficult to find and only due to seeing the switches in the UDK edit window was I able to find them. With this in mind some visual clues were added. These visual clues will be used for the visually orientated test level. For the aural focused test these clues will be sound based and the player must rely on their ears to find what they are looking for.

Blood arrow points to a barely visible switch