So, in the spirit of helping out others using Unreal Engine 3 or the UDK, here are three features that I wish I had known about when I first started using Unreal.

Kismet Console Command
What’s the easiest way to call an UnrealScript function from Kismet? Write a custom sequence action? No!

Use the Console Command sequence action. Using it you can call any function marked with the exec keyword in UnrealScript. All you need to do is pass in a valid target for the sequence action (most likely a PlayerController, like in the convenient All Players kismet variable.)

Cause Event
Console Command will allow me to easily call into UnrealScript from Kismet. What if I want to go in the other direction? That’s where the Console Event node comes into play. This kismet event gets executed when the “causeevent” console command is triggered through UnrealScript. This makes it trivially easy to write code that calls out from UnrealScript into Kismet.

Having a Pawn, for example, calling “causeevent PawnHitWall” (“CE PawnHitWall” for short):

   PlayerController(Controller).ConsoleCommand("CE PawnHitWall");

Results in the following Kismet event being called with the PlayerController’s Pawn passed through as the Instigator:

ActorComponents
I’m a bit sheepish to admit it, but I jumped into Unreal without really understanding the relationship between Actors and ActorComponents. As a result, I probably created dozens more custom actor classes then I ever needed. In hindsight, the extra classes were senseless because it is so trivially easy to add new ActorComponents in the defaultproperties of a class. Spawning Emitters (a descendant of Actor) when I could have just added ParticleSystemComponents in my Pawn’s defaultproperties block was probably my worst offense.

If you only read one page on UDN, read the page on ActorComponents. (If you only read one page on UDN though, you’re probably doomed. Read a lot of UDN pages, just make sure you don’t miss the one on ActorComponents.)

For people experienced with Unreal, these tips are probably old hat, but it’s surprising how far you can get with the engine while still missing basics like ones above. Personally, knowing the above tidbits ahead of time would have probably sped up the development of my first Unreal Engine game prototypes significantly.

The core of this trick stems from the format that UDK uses when copying data to the clipboard for copy-past operations. It just so happens that the format UDK uses when serializing data to the clipboard is the same format it uses for defining object settings in UnrealScript defaultproperties blocks. That is to say that it serializes objects to an easily human-readable, and therefore human-editable, format.

The trick is to, after copying an object from the UDK Editor, paste it to a text editor. From the text editor, you can modify the source object definition to match the destination object. Then, you just need to copy the modified text and paste it back into the UDK Editor. If all goes well, you should see your data copied to the destination object.

Voila! Tedious hand-editing averted by (semi-)clever hacking.

The UDK provides several utilities for editing objects and actors on-the-fly. You can use these utilities to quickly implement a tweaking interface to allow game designers on your team to easily adjust game parameters in realtime.

The core of UDK’s realtime tweaking capabilities is a feature called Remote Control. Starting UDK.exe with Remote Control enabled opens up a window alongside the game which allows you to change graphics settings, inspect and edit active actors, and toggle stat captures. Activating Remote Control also enables a series of console commands that can allow runtime editing of almost any instantiated object, actor, or archetype.

For example, you may want to implement an object that contain a categorized list of the various global tuning parameters you expose in your game. These numbers could represent values that will eventually be constants in your game system but will need significant iteration in order to find the right mix for your game.

First of all, you’ll need to be able to start your game with Remote Control enabled. In my case, I edit my UDK launch batch file to add “-remotecontrol” argument when launching UDK.exe:

Binaries\Win32\UDK.exe %start_map% -remotecontrol

Next, create an object to contain the parameters that you want to expose to your game designers. By using the “var(category)” syntax for declaring members, you can organize them into collapsable tabs. For arrays of objects, the “editinline” modifier makes it possible for designers to edit the objects contained within the array (as opposed to just the array itself.)

//Class written as example for blog article on creating an in-game editor
class TestGame_GameParameters extends Object;

var(Players) float PlayerHealthMultiplier;
var(Players) float PlayerSpeedMultiplier;
var(Players) float PlayerAttackMultiplier;

var(Enemy) float EnemyHealthMultiplier;
var(Enemy) float EnemySpeedMultiplier;
var(Enemy) float EnemyAttackMultiplier;

var(Weapons) editinline array WeaponAttacks;
var(Weapons) float SecondsPerWeaponBeat;

defaultproperties
{
	Begin Object Class=TestGame_InstantHitAttack Name=Attack1
		AttackName="OverhandLight"
		Damage=1.0
		Duration=1.0
		Cooldown=1.0
	End Object
	WeaponAttacks.Add(Attack1)

	Begin Object Class=TestGame_ProjectileAttack Name=Attack2
		AttackName="Fireball"
		Damage=4.0
		Duration=2.0
		Cooldown=3.0
	End Object
	WeaponAttacks.Add(Attack2)

	Begin Object Class=TestGame_InstantHitAttack Name=Attack3
		AttackName="OverhandHeavy"
		Damage=2.0
		Duration=1.0
		Cooldown=1.0
	End Object
	WeaponAttacks.Add(Attack3)

	PlayerHealthMultiplier = 1.0f
	PlayerSpeedMultiplier = 1.0f
	PlayerAttackMultiplier = 1.0f

	EnemyHealthMultiplier = 1.0f
	EnemySpeedMultiplier = 1.0f
	EnemyAttackMultiplier = 1.0f
}

With the game parameters object defined, it’s time to instantiate it in some easily accessible global space: GameInfo, for example.

class TestGame_GameInfo extends SimpleGame;

var TestGame_GameParameters GameTuningParameters;

//...

defaultproperties
{
	Begin Object Class=TestGame_GameParameters Name=GameParameters0
	End Object
	GameTuningParameters=GameParameters0
}

It’s important to note the name of the game parameters object instantiated in defaultproperties, “GameParameters0″. You’ll be able to use this name as a parameter to the “editobject” command to directly address your parameter object.

At this point, you can edit your game parameters object in-game by hitting tab and entering “editobject GameParameters0″. Doing so will open a property grid targeting your global instance of TestGame_GameParameters.

Of course, typing in “editobject GameParameters0″ tweak values is a nuisance and we don’t want anything discouraging your game designers from using the tools you’ve built. To make it easier for them, we can take an extra step and make the game parameter property grid accessible with a single button press.

By editing DefaultInput.ini, you can set up a key binding like so:

;-----------------------------------------------------------------------------------------
; Game Keyboard/Mouse Bindings
;-----------------------------------------------------------------------------------------

; Binding for tweaking ingame parameters (written for blog post)
.Bindings=(Name="F9",Command="TweakGameParameters")

With the above setting, pressing F9 will call an exec function called TweakGameParameters(). After that, it’s just a matter of defining said function:

class TestGame_PlayerControler extends PlayerController;

exec function TweakGameParameters()
{
   ConsoleCommand("editobject GameParameters0");
}

And that’s it! Now, your team’s game designers will be able to press F9 while the game is running to bring up a property grid for tweaking game parameters on-the-fly.

In my latest game prototype, I decided to implement a simple Street Fighter-like command input system for executing special attacks.  The big trick here is to take a stream of (imperfect) human input, compare it against a list of canonical actions, and match in such a way that a human player will be satisfied that the system is responding accurately to their input.  This is how I put it together.

For the command input system, I start off with a series of commands that I will recognize.

1. Super Beam (HCF+ATK)
2. Energy Ball (QCF+ATK)
3. Spin Attack (QCB+ATK)
4. Normal Attack (ATK)

• ATK = Attack button
• HCF = Half-circle forward
• QCF = Quarter-circle forward
• QCB = Quarter-circle backward

I specifically ordered the attacks starting from the most complex inputs going to the simplest.  This is the order in which I will test actions against my input buffer and I want to make sure my more complex actions will be recognized over the simpler actions.  This is especially important for HCF+ATK versus QCF+ATK because the latter is actually a subset of the former.

With a list of actions in hand, the next step is to fill a buffer with input from the player.  Ideally, I would like to have input capture running at a fixed rate independent of my visual framerate.  However, since I’m using the UDK for my prototype, it would be a bit difficult (not to mention wasteful) to implement a custom input capture system.  So, I settled for extending the existing PlayerInput implementation to log input and throw out commands older than some arbitrary age (about 0.5 seconds in my initial implementation.)  This gives me a record of the inputs executed by the player over the last half a second.

The final step in command recognition is to actually match actions against my player’s input buffer.  In a world of perfect player input, I would just have to search the buffer for occurrences of sequences like Down + Down-Right + Right + Attack in order to match QCF+ATK.  In reality, player input has a lot more variance.  While a player may intend to enter Down + Down-Right + Right + Attack in order to launch a QCF+ATK, they are just as likely to enter something like Down + Down + Down-Right + Right + Up-Right + Attack.  To a computer, that sequence looks nothing like a QCF+ATK, but the player is most likely going to be convinced they entered a QCF+ATK, if not perfectly, at least well enough.

In order to give the player a suitable level of forgiveness in action matching, I search across the input buffer for matching inputs while ignoring non-matching inputs.  As long as a subset of the buffer matches the target action’s input string (in the proper order), then I consider the action matched and end my search.  I also clear the input buffer as I know consider it “consumed” for the purpose of recognizing command actions.

With the input Down + Down + Down-Right + Right + Up-Right + Attack as an example, I would check against the “Super Beam” action (HCF+ATK) and fail to match.  Then, I would check against the “Energy Ball” action (QCF+ATK) and match against the buffer since Down + Down-Right + Right + Attack occurs in the buffer once I ignore the extraneous Down and Up-Right.

The end result of this implementation is a fairly convincing input matching system that should satisfy most player’s with its mix of accuracy and forgiveness.  By tuning the length of time to preserve the input buffer, you can control the tightness of the input recognition to match your tastes.

The UnrealScript source code for the input matching system follows:

class BPG_PlayerInput extends PlayerInput;

enum BPG_InputCommand
{
        BIC_Up,
        BIC_UpRight,
        BIC_Right,
        BIC_DownRight,
        BIC_Down,
        BIC_DownLeft,
        BIC_Left,
        BIC_UpLeft,
        BIC_Attack
};

struct BPG_InputCommandEntry
{
        var BPG_InputCommand InputCommand;
        var float AgeSeconds;
};

struct BPG_ActionDescription
{
        var name ActionName;
        var array Inputs;
};

var transient bool LastAttackPressed;
var transient bool AttackPressed;
var transient array CommandBuffer;

var array Actions;
var transient int LastMatchIndex;

const COMMAND_INPUT_MAX_AGE = 0.5f;
const MATCH_REMEMBER_TIME = 1.0f;

function string CommandToString(BPG_InputCommand inputCommand)
{
        switch( inputCommand )
        {
        case BIC_Up:
                return "U_";
                break;
        case BIC_UpRight:
                return "UR";
                break;
        case BIC_Right:
                return "R_";
                break;
        case BIC_DownRight:
                return "DR";
                break;
        case BIC_Down:
                return "D_";
                break;
        case BIC_DownLeft:
                return "DL";
                break;
        case BIC_Left:
                return "L_";
                break;
        case BIC_UpLeft:
                return "UL";
                break;
        case BIC_Attack:
                return "AT";
                break;
        }
        return "";
}

function string GetBestMatchAsString()
{
        if( LastMatchIndex == -1 )
                return "NO MATCH";

        return string(Actions[LastMatchIndex].ActionName);
}

function string GetActionsAsString()
{
        local String actionString;
        local int index, index2;

        for(index = 0; index < Actions.Length; ++index)
        {
                actionString $= Actions[index].ActionName;
                actionString $= "(";
                for(index2 = 0; index2 < Actions[index].Inputs.Length; ++index2)                 {                         if( index2 > 0 )
                        {
                                actionString $= ", ";
                        }
                        actionString $= CommandToString( Actions[index].Inputs[index2] );
                }
                actionString $= ")\n";
        }

        return actionString;
}

function string GetCommandBufferAsString()
{
        local String commandBufferString;
        local int i;

        for( i = 0; i < CommandBuffer.Length; ++i )
        {
                commandBufferString $= " " $ CommandToString( CommandBuffer[i].InputCommand );
        }

        return commandBufferString;
}

function AddCommand(BPG_InputCommand inputCommand)
{
        local BPG_InputCommandEntry commandEntry;
        commandEntry.InputCommand = inputCommand;
        commandEntry.AgeSeconds = 0.0f;
        CommandBuffer.AddItem(commandEntry);
}

//Hooked to action in DefaultInput.ini
exec function AttackStart()
{
        AttackPressed = true;
}

//Hooked to action onrelease in DefaultInput.ini
exec function AttackStop()
{
        AttackPressed = false;
}

// Postprocess the player's input.
event PlayerInput( float DeltaTime )
{
        local int index;
        local array indexesToRemove;

        super.PlayerInput(DeltaTime);

        for( index = 0; index < CommandBuffer.Length; ++index)         {                 CommandBuffer[index].AgeSeconds += DeltaTime;                 if( CommandBuffer[index].AgeSeconds >= COMMAND_INPUT_MAX_AGE )
                {
                        indexesToRemove.AddItem(index);
                }
        }

        for( index = 0; index < indexesToRemove.Length; ++index)         {                 CommandBuffer.Remove(indexesToRemove[index], 1);         }         if( aBaseY > 0.0f )
        {
                if( aStrafe > 0.0f )
                {
                        AddCommand(BIC_UpRight);
                }
                else if( aStrafe < 0.0f )
                {
                        AddCommand(BIC_UpLeft);
                }
                else            {
                        AddCommand(BIC_Up);
                }
        }
        else if( aBaseY < 0.0f )         {                 if( aStrafe > 0.0f )
                {
                        AddCommand(BIC_DownRight);
                }
                else if( aStrafe < 0.0f )                 {                         AddCommand(BIC_DownLeft);                 }                 else            {                         AddCommand(BIC_Down);                 }         }         else         {                 if( aStrafe > 0.0f )
                {
                        AddCommand(BIC_Right);
                }
                else if( aStrafe < 0.0f )
                {
                        AddCommand(BIC_Left);
                }
        }

        if( AttackPressed && !LastAttackPressed)
        {
                AddCommand(BIC_Attack);
        }
        LastAttackPressed = AttackPressed;

        FindBestActionMatch();
}

function FindBestActionMatch()
{
        local int actionIndex;
        local int inputIndex;
        local int commandBufferIndex;
        local int matchedInputCount;

        //For each action (ordered by priority)
        for(actionIndex = 0; actionIndex < Actions.Length; ++actionIndex)         {                 commandBufferIndex = CommandBuffer.Length - 1;                 matchedInputCount = 0;                 //Walk backwards through input on list and find in command buffer                 for( inputIndex = Actions[actionIndex].Inputs.Length - 1; inputIndex >= 0; inputIndex-- )
                {
                        //Consume commandBuffer until we find our target input (or run out of buffer)
                        while( commandBufferIndex >= 0 )
                        {
                                if( Actions[actionIndex].Inputs[inputIndex] == CommandBuffer[commandBufferIndex].InputCommand )
                                {
                                        matchedInputCount++;
                                        break;  
                                }
                                commandBufferIndex--;
                        }
                }

                //If we matched all inputs in an action, record that action and stop searching
                //Also clear the command buffer since it's all processed
                if( matchedInputCount == Actions[actionIndex].Inputs.Length )
                {
                        LastMatchIndex = actionIndex;
                        SecondsSinceLastMatch = 0.0f;
                        CommandBuffer.Length = 0;
                        break;
                }
        }
}

defaultproperties
{
        Actions(0)=(ActionName="EX1", Inputs=(BIC_Left, BIC_DownLeft, BIC_Down, BIC_DownRight, BIC_Right, BIC_Attack))
        Actions(1)=(ActionName="SP2", Inputs=(BIC_Down, BIC_DownRight, BIC_Right, BIC_Attack))
        Actions(2)=(ActionName="SP1", Inputs=(BIC_Down, BIC_DownLeft, BIC_Left, BIC_Attack))
        Actions(3)=(ActionName="ATK", Inputs=(BIC_Attack))

        LastMatchIndex=-1

        LastAttackPressed=false
        AttackPressed=false
}

These are the UDK command-line parameters that I find indispensable for improving my development experience:

• warningsaserrors – There are few script-compiling arguments more useful than this one.  As the name implies, this flag causes UDK to treat make-time script warnings as errors and prevent you from making script until they are fixed.  While it may seem like a hassle at first, the increased discipline in fixing your warnings before they become errors will save you large amounts of time spent tracking down bugs later.  Any programmer/scripter who comes to me for help in debugging their code gets forced to fix compiler warnings before I’ll help them because I’m a mean nice guy and I don’t want to waste their time or mine.
• scriptstackonwarnings – This flag is a real prize at runtime.  Whenever you trip a warning, it will cause the UDK to output a call stack leading to the warning along with the warning message itself.  This is invaluable when you need to track down an error in functions that get called from multiple locations (which is most of them since you’re a DRY-kind of programmer, right?)  In fact, I can’t think of any reason why you wouldn’t want to have this flag enabled…
• fatalscriptwarnings – This argument is for when you’re getting serious.  Any runtime warning will be treated as a fatal error and stop your game in its tracks.  Having this puppy enabled will make absolutely sure that you fix your UnrealScript warnings.  Given that a warning is usually a sign that something unexpected is going on in your logic, this is a GOOD thing.  A couple caveats on this one though:  First, I generally only use this flag when I’m writing production script intended for release.  When I prototype, I tend to change code quickly and implement things in a quick and (often very) dirty fashion.  Second, UDK has a tendency to ship with a couple warnings firing during startup, often related to missing online profiles.  It’s fairly trivial to add the necessary nil-checks to prevent these warnings.  Enabling scriptstackonwarnings should help you find these bugs with no problem.

For those who want something nice and easy to cut-and-paste, here is the latest iteration of my UDK launch batch incorporating the flags above:

set start_map=BPG_Entry

Binaries\Win32\UDK.com make -warningsaserrors

IF errorlevel 1 GOTO :ERROR_EXIT
Binaries\Win32\UDK.exe %start_map% -log -scriptstackonwarnings

GOTO :GOOD_EXIT

:ERROR_EXIT
pause
exit /b %ERRORLEVEL%

:GOOD_EXIT

I hope this proves useful to other UDK-users out there. Good coding and bug-hunting to you all!

All you have to do is delete/rename UDK_logo.bik which is located at $UDK_ROOT\UDK_Game\Movies. This prevents the movie from playing (obviously) and allows the UDK to start up faster. It’s a trick that’s about as dirty and as simple as they come, but it can really make a difference when you’re iterating on game script.

Epic, your logo movies are nice and all, but sometimes I just want to concentrate on making my game. Nothing personal, right?

The biggest slowdown culprit has been the Unreal Frontend. Ostensibly a tool to give you easy access to every step of the Unreal workflow, it can slow development to a crawl because it forces you to cook data every time you update your script. It does this by hardcoding the “-seekfreeloading” flag when it launches UDK.exe. With this flag enabled, UDK.exe will only load seek-free packages which only get updated when cooked. Considering that cooking can take minutes depending on your machine and any script you edit needs to be cooked if you want to see its effect in-game, the “-seekfreeloading” flag can slow the typical edit->compile->run cycle to a crawl.

At work, I can modify and rebuild Unreal’s tools to match my (and my team’s) preferred workflow with no problem. Using the stock binaries that come with the UDK, I have to be a bit trickier. In this case, it’s not too hard because all the Unreal Frontend does is marshall parameters for executing programs on the commandline. This means that I can replicate almost anything that the Unreal Fronted does by using batch files.

In the case of launching the game without “-seekfreeloading”, it’s as easy as this:

Binaries\Win32\UDK.exe MyGame_Entry

You can call this from the root folder of the UDK with “MyGame_Entry” being replaced by a map of your choice. When launched this way, UDK.exe will use the compiled script and editor content packages directly instead of loading pre-cooked data. The key here, of course, is the lack of “-seekfreeloading” as a parameter for UDK.exe.

Since this is for speeding up my UnrealScript editing workflow, I like to make sure I build my scripts before launching my game:

Binaries\Win32\UDK.com make
Binaries\Win32\UDK.exe MyGame_Entry

Calling UDK.com instead of UDK.exe allows the output from the make command to stay in the same console window instead of launching in a new window. This is great when you want to see errors that come up from mistakes in your UnrealScript.

With a little bit of work, I can make a batch file that will launch UDK.exe only if scripts were successfully built and pause to let me examine the error report otherwise:

set start_map=BPG_Entry

Binaries\Win32\UDK.com make

IF errorlevel 1 GOTO :ERROR_EXIT
Binaries\Win32\UDK.exe %start_map%

GOTO :GOOD_EXIT

:ERROR_EXIT
pause
exit /b %ERRORLEVEL%

:GOOD_EXIT

Now, my workflow can be edit script -> save -> double-click LaunchUDKGame.bat -> check my changes -> repeat. Much faster without the cooking step. This means I can spend more of my time making my game instead of just waiting for the UDK to run.