Game level Complete !

More searching for the issues surrounding the maximum amount of channels that could be used resulted in little findings so after speaking with my supervisor I looked into the voice limiting option within UDK. I went through each of the sound cues which were created and edited the properties to define the maximum amount of instances of each cue could play at any one time. This was a last effort to try and get the level working outside of the editor.

Voice limiting option (Max Concurrent Play Count) was somehow overlooked earlier in the project phase

Before trying again to package the game I got a response from one of my posts on the Epic Games forum which shed some light on the problem. basically I had changed the max channels code for the editor only which would not transfer over to my packaged game. The following code was added to the BaseEngine.ini and BaseGame.ini files to change the max channels available in the exported game.

BaseEngine.ini which was edited to increase the maximum amount of audio channels available to the game

BaseGame.ini file which was edited to increase the maximum amount of concurrent heard sounds (by the player) 

The level has now been tested on a separate machine and appears to be functioning well, now time for testing

Exporting as Packaged exe. File

I was having major issues with exporting the game as an exe which actually runs on another machine. The script compiled fine and the game packaged without any errors but when it is installed on another machine it crashed on start up. Also the UDK front end menu screen still appeared at load up which gives the option for game modes such as 'death-match' and 'Unreal Tournament'. This issue was supposed to have been solved with the creation and scripting of my own custom game mode. My game mode should have been overriding this default menu system and just booting up the level right away.


After some searching though many pages on forums such as the Epic Games Forum the solution was unearthed.

Within the configuration files lines of code needed to be changed in order to bypass the default menu and game system to tell UDK to use my game mode as the default. The map (my level) name also had to be specified before packaging.

The game now works runs on a different PC but the setting that has been changed to increase the maximum channels to 64 has not carried over so not all sounds are playing back correctly. Time is running out fast to get a solution and a game that works as intended, testing of the level should have been finished already.

Performance Issues UDK - Voice handling

Since including the breathing system into the level, sounds are being cut off whilst playing the game. Usually after a few minutes of play there are random sounds which are not playing back.

After running the in game performance check on the audio data it appears that there are now too many voices being used at any one time (limited to 32). After some reading into the UDK manual it has become clearer exactly how the sound is handled by the system. Previously it was taken for granted that if a sound was switched off then it would not take up any voices. This is why there was trigger volumes set up around the level which were designed to manage sounds within their area, either switching sounds on or off depending if the player was in the area. This however is not the case and all sounds are loaded into memory from start up and any sound triggered remains as a used voice. 

Whilst reading into the documentation I found out the the voice limit of 32 can be changed up to 64 by editing the UDKEngine.ini configuration file which can be seen below. This has fixed the problem whilst playing in the editor but following up on some guidance I will be looking into the voice limiting options within UDK as a better solution.

Player Breathing and Linked to Run Function

The breathing recordings were used to create player breathing cues, initially this is only normal breathing and running breathing. A much more dynamic breathing system is more desirable but at this stage there is little time left to include more at this stage as testing should be under way already.

Inhale and exhale samples were were connected as a continuous sound by using the concatenator node, these were also linked together randomly to add variety to each breath.  

Normal_Breathing to be called when walking

Running breath which is called when character is running

Transition breath is called when the player stops running before returning to normal breath

The system which identifies when the WASD (movement keys) were being pressed was already in place from the previously created crouch function so it was a case of extending this to now incorporate the Left Shift key to trigger the run breathing sound.

When Left Shift + WASD (movement) is pressed the run breathing sound is triggered, after the sound has played it checks to see if the the player is still running and if so repeats the for another breath. If the player has stopped running then the signal moves onto the transition breath before returning to the normal breath.

Crouch Movement Sounds

The following Kismet sequence was created which allowed me to bypass adding anything into the unreal script to define a sound for when the player is crouch moving by simply using 'Compare Bool' nodes. These nodes give out a true or false signal.

The Kismet is set up so that the Play Sound node only triggers when the crouch key + any of the movement keys are pressed (when the player is moving whilst crouching). Once the keys are released this triggers the Play Sound node to stop. 

Player Run Function

By default there is no run function that comes with the UTGame class. To enable such a function was a little more difficult that anticipated. What was required was for the player to be able to run on a key press and to add more complexity to the issue the footstep sounds also needed to increase at the same rate. The unreal script which controls the player speed and footstep frequency had already been highlighted before and so a way to change these values if a key was pressed needed to be established.

After searching through forums the following kismet sequence was found which is set up to allow the character to run with a fatigue system in place. The kismet sequence was recreated but did not work very well. The footstep frequency was not altered and the player wouldn't run very far before returning to a walking pace.  

After spending a considerable amount of time trying to tweak this existing system without any luck I then simplified it as to remove the fatigue section. All that was used was the 'Modify Property' nodes which were originally modifying the property 'GroundSpeed', this was changed to 'MovementSpeedModifier' which was the original property that was changed to slow the game character down via the unreal script. This was just a stab in the dark but worked better than was imagined, the player speed as well as footstep frequency is now increased when the left shift button is pressed along with the WASD movement keys.

The next step is to try and add a sound for when the player is crouched and moving as by default the footstep sounds turn off when crouched.

Footstep Sounds Update _ 05 Fully Functional

Having now re-installed UDK and got the level back up to speed with a custom game mode running, a revisit on the footstep sound issues was required to get this bit of the game working.

The main problem was to do with multiple materials under the players feet and so confusing UDK as to which footstep sound to play back.

The room where there is water on the floor was looked at first, again I tried to delete all non essential floor materials in this room (which had been tried before). Somehow this time it fixed the problem!
I can only assume that it has something to do with the new version of UDK that was installed. Now the custom water footsteps are being called as intended.

However the other area (within the cave) is still reverting to the (nasty) UDK default footstep sound. To fix this I have now redefined the default footstep sound in my custom sound class as my own sound. Perhaps not the greatest thing to do but it works in the given situation as the cave is the only place in the level were this problem is now happening.

Default footstep is called in situations where the material type under foot cannot be identified. here it is redefined to call my own sound in such situations.

UDK Game mode - Take Two

The last attempt at messing with the unreal script to create a custom game mode resulted in the editor crashing. A more cautious approach was taken this time around and back ups of each edited script has been stored safely in case of any problems.

This time a different GUIDE was followed which allowed me to set up a custom game class within the unreal script. The 'Classes' in UDK which I have come to learn work like a family tree, where there is parent classes at the top which branch out into sub classes or extensions of the parent classes. Take the 'UTGame' class for example (as this was the one I wanted to take parts from) is just an extension of another class stated further back in the tree.

The image below show the folder that was created and the unreal scripts that had to be inside in order to run my own game type.

Custom game mode folder tree

Here is defined what kind of game this is. In this case my game (GaryGame) extends the UDKGame class.

This part of the code defines my game character which extends the UTPawn class. This means my game character has all the functionality of the character in the UTGame mode. The default properties were added which adjusts values from the UTPawn class to suite my game. In this case the double jump function and spawn sound was disabled. This is where my sound class was now being referenced instead of the UTPawnSoundGroup.

This class allowed me to gain all the functionality of the UTPlayerController which enables my character to move around and crouch.

This is my custom sound class which extends the UTPawnSoundGroup, this is where I have now placed my custom footstep sounds.

With this in place I had to let UDK know where to look for my custom class so that the unreal script could be recompiled correctly, this had to specified within the UDK configuration file "DefaultEngin.ini" as shown below.

Now with my custom game mode functioning (AT LAST) the next step is to revisit the issue surrounding the footstep sounds.

UDK Game Mode - UPDATE

After reinstalling UDK and trying to open the level, it seems there are some issues with the way my custom sound package is being referenced. None of my sounds are playing back at all!

From what I can see all the work that has been done in the kismet is still there but no sounds are defined within the 'PlaySound' nodes. I have had to re-import my custom sound package and now must try and link everything back together the way it was.

UDK Game Mode CRASH

An attempt has been made at tying to create a custom 'Game Mode' for the level which should allow it to be exported as an executable file. This will also include the functionality of handles footstep sounds found in the 'UTGame' mode.

After reading up and watching tutorials about how the UnrealScript works I have found the relevant code which is used for the 'UTGame' mode. As suspected there is a lot more "stuff" shall we say in this mode that my specific level requires. For example weapon functions, server settings, vehicle settings and lots to d with multi player action. Most of which is not required.

I used a GUIDE to help try and set up a basic game mode but in doing so I have changed or removed something within the original UnrealScript (which sadly was never backed up). Now the UDK Editor crashes whenever I try to load the level. I am not even sure what has been changed or what is going on. I plan next to make a copy of the level assets and try to reinstall UDK to see if this fixes the issue.

Timed Gates Sequence

In the level there are two sets of timed gates with levers that both must be activated within a certain amount of time in order to open them. The basic system for this was already set up within the Kismet as default but there was little player feedback on what was actually to be done apart from matching numbers on the wall.

One set of levers are situated almost next to each other which from the players perspective is quite easy to see what needs to be done. The second set as shown in the image above are much further apart and needed a better system in place to guide the player on what was required of them.

From a sound point of view a ticking timer sound was created for when the player activated one of these levers, this sound was attached to the lever itself and could be heard spatially within the level. To increase the sense of urgency a music cue was also created to support the fact that there was a time limit on getting to the other lever. This sound can be heard by the player for the entire duration of the set time as opposed to the ticking sound which will fade out as the player moves away from the lever. By having the ticking sound attached to both levers the player can then use this as a guide to locating the next lever as they get closer to it.

As a last touch there was also a camera cut scene used to jump to the location of the next lever that needed to be used. This was created using a movement track within the Matinee and linked to the trigger which is set up for the levers interaction.

Above can be seen what was done in the kismet to make the sequence work. When either of the levers are triggered it calls the Matinee cut scene which then shows the player the next target, also the ticking and music sounds are played whilst a timer is set  using a 'Delay' node. After the delay runs out it closes a 'Gate' which then stops the music and ticking sound as well as the player form being able to open the door. The system is then reset but with cut scenes now disabled. If the player manages to get to the second lever before the delay reaches 32 second they are able to open the door way which then fades out the ticking and music cues.

Cave Camera - The Big Entrance

Following up on some advice from my supervisor the decision was made to make more of the cave room being revealed. As it is possibly the most unique and interesting location within the level is seemed fitting to have a quick camera fly though to give some scale and perspective to the player when they enter the cave. This will also help to draw the player further into the level by bringing parts of the level to their attention which they may have missed before.

The same procedure was followed as the beast camera scene to get the camera up and running. From there a short musical section was created using some layered synth patches with the aim of creating a sense of wonder but also caution eg, "does the beast live here".

Cave Camera Matinee

Camera Key-Frames tracked along the green line showing the camera path

Simple Kismet set up which starts the camera scene upon coming into contact with the trigger on the cave entrance 

Beast Camera Sequence

The main threat throughout the level is to come from the suggestion of a beast lurking within the dungeon. To achieve this a camera cut scene was created using the Matinee sequence in Kismet. This was as simple as adding a camera actor to the level and attaching it to a Matinee in the kismet. From within the Kismet key-frames can be added at intervals along a timeline, these key-frames tell the Matinee where the camera should be at a given time. The camera route was laid out on the level map and fine tuned for timing and positions until the desired effect was achieved.

The cut scene was then linked to one of the relics being picked up, the position of this relic (and character at this point) is ultimately where the beast appears to be heading to. This sequence is designed to panic the player and in doing so should grab more of their attention and result in a greater chance of game immersion.

Matinee Sequence for the Beast camera

Camera in action moving along the path defined by the information recorded in the Matinee

A custom sound design was created for the cut scene by exporting the Matinee sequence as a video and importing it to Pro Tools to work with. There was some back and forth editing between sound and video before a final mix was achieved. Once the cut scene sound was imported to UDK it was a case of creating a simple sound cue with it and placing it directly into the matinee sequence on a sound track.

The Kismet sequence above shows how the beast camera scene is triggered (when the square relic is picked up). This also cuts off the original underlying music and atmospheric loops to make way for the 'On_Edge_Loop' which provides a slightly more active background layer. This also lets the player know that the mood has changed after the Hunted music sequence tails off. So the 'Hunted_Main_Alert' music is also called as soon as the cut scene is finished, forcing a sense of urgency on the player.

Once the player leaves the area which is defined by a trigger point the intensity of the 'Hunted' music sequence will begin to tail off and eventually fade out.
Also connected to the beast camera completed output is the 'beast movement' sound cue which has been set up to make it sound like the threat is moving around close to the player position.

Beast movement was created in the same way as the cut scene only this time instead of a camera being moved around it was a note actor which has the beast sound cue attached to it.

'Beast_Sound' cue calls on pitch shifted vocal recordings of roars.

As well as this the end of the cut scene also triggers the 'Random_Beast_Sound' cue, which triggers on on a delayed loop. This sound is different from the 'Beast_Sound' cue in that it contains pitch shifted sounds which were recorded from the Grain bin location recordings. These sounds are low end metallic sounds which work well once the action has died down a bit to keep the tension going.

Random Beast sound cue triggers on a looped delay between 15 and 60 seconds adding to the atmosphere after the beast camera cut scene action.

As the player is quite close to the relic alter at the time of the cut scene they are able to get to the alter and place relics before the music fades. With this in mind, the placing of any relics during the Hunted Music sequence will override the music and fade it out quickly. This avoids any clash between the Hunted music and the relic placement cues, which after testing without this cancellation in place sounded terrible. To break the sudden silence after such a relic placement the trigger for placing the relic was used to re-trigger the beast movement cue which is still within the hearing range of the player. This functions as a nice reminder that they are still being hunted and the beast has gone no where.

Level Ambience - Weather

To enhance the connection with the outside world (outside dungeon) I created a weather sound cue which was made up of a rain loop sound and randomised, delayed thunder rolls which I recorded last summer. As there is openings to the outside of the dungeon at various points (complete with water dripping in it was only fitting that this sound be added. It was activated within the kismet so that it played from level start up, now the level feels much more complete from an ambient standing.

Weather system sound cue

UDK Game Mode Problem

I have been trying to export the level as an executable file which will run on another PC as a stand alone game, however it keeps crashing. I have pinned it down to the game mode option in the game world properties option bar. Currently my level is set to the UTGame mode which defines what kind of game is being set up. In this case the 'UT' bit stands for Unreal Tournament, so my game is essentially trying to start up this kind of game when it is exported into an exe. file. As the dungeon level is not set up for this type of game I think this is why is causes the crash. Changing the game mode to anything other than UTGame causes my footstep sounds to stop and the character speed to revert back to the jogging pace which was changed.

I have discovered that the UTGame mode is directly linked to the UnrealScript that was edited to add custom footstep sounds and change player speed. The way forward appears to be to try and create a custom version of the UTgame mode that only holds onto certain aspects of the mode. This means a much deeper look than was bargained for into UnrealScript to try and find a solution.

Wooden Doors Sound Cues & Kismet Sequence

Throughout the level there are double wooden doors that the player can open, these door opening sequences were already set up through the Kismet so this was just a case of creating the relevant sound cues and attaching them to the actions of the door. Three sound cues were created for the doors as seen below.

Door closed sound cue (for when the doors are fully closed)

Door closing sound is a variant of the opening sound cue

Doors opening sound cue comprising of an unlocking/handle turn sound and a creaking sound

Seen below is an example of the Kismet sequence that controls the door movement.

Kismet sequence of the wooden doors that lead into the main hall

Game Play Feedback _03 - Treasure Chest & Shifting Walls

The feedback sound for the treasure pick up was added along side the sounds for the chest being opened. Also there are shifting walls that appear and disappear within an area of the level to confuse the player so a sound was also attached to this event to give the player an indication that the event is taking place.

Chest opening sound with the reward sting "Treasure_get" playing on a dealy

Chest unlocking sound cue made up of randomised locking sounds

Shifting Walls Sound Cue

Kismet Sequences

Shifting walls sequence, Play Sound node attached to the events that cause the walls to shift

Treasure chest opening sequence, firstly decides whether the player has the key then if so opens the chest and plays the sound cues

Game Play Feedback _ 02 - Relic Placement

Relic Placement Cues and Kismet Sequence

I managed to set up a system which will call a certain sound cue depending on how many relics are being placed in the alter. The four cues are all made from the same base synth patch but differ in intensity and pitch. With each additional relic placed in the alter the player can hear a more intense sound which is an indicator that they are getting closer to completing the levels main objective of finding and placing all the relics.The sound cues are as follows;

The Kismet Sequence

the Kismet system for identifying which relics the player has picked up was already in place, when the player picks a relic up it opens a 'Gate' which in turn then activates the sequence that allows the relic to be placed in the alter. When each 'Gate' was opened (relic picked up) I passed a signal to an 'Add Int'. This basically counts how many 'Gates' have been opened (how many relics the player has) when the player presses the 'Use' key at the alter. From the 'Add int' the signal goes to 3 separate 'Compare Int' nodes which compare their value to the 'Add Int' and play the corresponding sound cues.

Game Play Feedback _ 01

I began to create the required sound cues for some of the game play feedback. These sounds included things like key/relic pick-ups, shifting walls and the placement of the relics in the alter.

The two pick up sounds are mostly to be associated with player gratification and reward whilst giving the player some incentive to keep searching for the items. The key pick up which is required to unlock the treasure boxes was aimed to be a bright sound which stands out from the dark atmospheric sound of the level. The idea is to give the player a sense of hope and achievement.

The relic pick up sound was designed to be a little more mysterious to try and leave the player wondering, what exactly is this item?

Key as seen in level

One of the 3 different shaped relics as seen in the level

 Sound Cues

Key pick up sound consisting of a base layer and additional randomised key jangle

Relic pick up sound cue going with a similar layout to the key pick up

These were then attached to the items via the kismet to trigger when the player picked up each item. As an added effect I also attached a toggle light to each of the keys to make it appear to glow. This is to further allure the player into seeking to find all the keys by making them look more desirable.

The next task for the feedback sounds will consist on the relic placement into the alter. There are four versions of this sound planned, each of increasing intensity basically a sound for x1 relic placed, x2, x3 and a final looping version that loops until the player exits the level.  A system will will need to be set up within the Kismet that can identify how many relics are being placed/have been placed into the alter, then it can can the desired sound cue.