Here is a brief tutorial on how to add custom footsteps into UDK. Before I get started please be aware that this tutorial is designed for people who have an intermediate understanding of Unreal Script and UDK. Certain aspects such as importing sound waves into UDK will not be covered in this tutorial since it should be prior knowledge on the readers end. Also note that the scripts used in this tutorial are all custom scripts but the information can applied to the default scripts UDK provides.(Note:  if you do edit the default scripts make copies of the original code prior to any alterations)

To start off in your Custom Pawn script’s default properties you will add a Sound Group Class that the pawn will reference instead of the default Sound Group Class that the UTPawn uses.( Assuming you are extending off of UTPawn). It should look something like this:

class CustomPawn extends UTPawn;




Next you will need to create a new script that will act as your custom sound group that extends off the UTPawn sound group like this:

Class CustomGameSoundGroup extends UTPawnSoundGroup;




In the default properties of this script is the location where you will place your custom footstep sounds that your pawn will use in the game. By default UDK comes with an array of footstep sounds that can be overridden, so for good measure I usually copy and paste the default footstep sounds present in the original sound group used by the UTPawn:

Class CustomGameSoundGroup extends UTPawnSoundGroup;




FootstepSounds[2]=(Material,Sound=SoundCue'A_Character_Footsteps.FootSteps.A_Character_Footstep_EnergyCue' )

FootstepSounds[3]=(Material,Sound=SoundCue'A_Character_Footsteps.FootSteps.A_Character_Footstep_Flesh Cue')









In UDK footsteps are produced and recognize by the material texture applied to the static mesh or bsp the pawn is walking on. Sound effects like footsteps are applied to material textures by a physical material as shown below:
The physical material that is applied to the material texture actually houses the location of where the custom sound group script looks at to apply the footstep sounds. Looking back at the default footstep sounds you will see that before the sound cue is referenced in the line of code, a material type is called with a unique name. This material type is what connects the sound cues present in the script to the physical material.

First create a custom physical material and in its properties, go to the very bottom and click the blue arrow on the right of "Physical Material Property" and click "UTPhysicalMaterialProperty". A section called "Material Type" should appear. This is where you put in the type of material you want to have a specific footstep sound.  For example in my game I made footstep sounds for walking in a junkyard.
I put "HeliosJunkYard" as the material type then close it. Navigate to the material texture that I’m going to use it on, open it, and in the Physical Material properties plug in the physical material I just created. Next I have to go back to the CustomGameSoundGroup script that I created and add the sound pathway to the physical material like so:

FootstepSounds[11]=(Material, SoundCue'Helios_SFX.GroundSFX.DirtFS')

(Note: keep in mind that if you have multiple footstep sound effects you will need to number them properly in an array)

Lastly with a quick recompile of my scripts my custom footstep sound is all set to be used in the game.

Hello Everybody,

Long time no see, or hear, or write, or whatever you call it but it’s been a while since any blog post was posted to here. Just to let everyone know our team is still kicking and alive but over the last two months our game has gone through a major overhaul. Not to get too much into the specifics of our dilemmas but the short and sweet answer for our team’s long hiatus was that our game wasn’t progressing as it should have so we had to reevaluate our core concepts and mechanics and reiterate our entire game. Now that might sound like a huge back step to our development and it was for about a week but fortunately for us our team is awesome so it wasn’t as much of a set back as we thought it would be.

Some of the biggest changes that we had to employ into our new game vision were:

1. Making our levels a lot smaller but elaborate.

2. Scrapping most of our light power mechanic and focusing the game on one specific mechanic, pushing objects.

3. Reiterating our world swapping mechanic to have a cause and effect mechanic.

Now the reason we decided to focus our attention towards just a few specific mechanic instead of many was because as mention before our game wasn’t progressing much and it was becoming too much of an action platformer instead of a puzzle platformer game.

  The main concept behind Helios was to essentially have an intricate puzzle platform game focused on direct player controlled mechanics. Unfortunately our original idea of using three lights that gave the player different abilities was too out of scope for our project’s timeline so we couldn’t fully develop those mechanics. Instead we just said out with the old and in with the new which surprisingly worked out much better in the long run.

So here is a basic synopsis of want Helios gameplay will feature:

Since the game will revolve around the player pushing objects there will be a variety of pushable objects for the player to interact with throughout each level. The main three will be…

Wood Box

Electric Box

Explosion Box

Similar to our light mechanics these boxes will have unique properties that are essential to so solving each level. For example the explosion box as the name suggest explodes ( and yes a lot of thought went into that) when it is drop from elevated levels destroy objects on impact. So levels that feature the explosion box will  give a hint to the player that there is some object that will need to be destroyed for the them to progress

Another feature that will be integral to the player’s progression is the world/time swapping function. Very similar to our green light mechanic in our previous design, the player has to swap between time periods to traverse around levels.  However instead of just switching between time periods to traverse, players will actually have to interact with objects in one time period to have an effect on the other time period.

As the end of this project nears us week by week expect more updates soon, such as some new tutorials on features applied to our game and a beta version of our game but thanks to everyone for following us and checking our website regular for updates. We are back and also Happy Holidays.

 Hello there this is Darren and I’m Team Helios awesome kismet scripters, even through the other members are too bashful to tell me face to face. As my first post to this blog I thought I should provide everyone with an Unreal Script developed for our game if anyone else in game design was looking for the same result.

In our game we have sections where objects fall and hurt the player when they make contact with them. So we need the actor to spawn in, destroy itself when it hurts the player, and have a life span long enough to reach the player from whatever height the object was spawning from. Aside from the static meshes uses many of the falling objects in our game extended off this one script and I hope it will help other game designers in their endeavors:

class FallingActor extends KActorSpawnable placeable;

var() int myDamage;
var() class<DamageType> myDamageType;

 event Bump(Actor Other, PrimitiveComponent OtherComp, Vector HitNormal)

       if(Pawn(Other)!=none && !Pawn(Other).bDeleteMe) //Is it a pawn?

       Pawn(Other).TakeDamage(myDamage, None, Other.Location, Other.Velocity, myDamageType,, Self);

event RanInTo(Actor other)

       if(Pawn(Other)!=none && !Pawn(Other).bDeleteMe) //Is it a pawn?

       Pawn(Other).TakeDamage(myDamage, None, Other.Location, Velocity, myDamageType,, Self);

       Begin Object Name=StaticMeshComponent0
       End Object

       LifeSpan= 5.0