The Imperative Narrative

One of the first issues I ran into with prototyping this game concept was with building out the Controller/Pawn hierarchy. In the UDK, pawns represent the physical “characters” in the game, whether they are players, missile turrets or scampering wildebeests just added in to fill the world. The controller represents an abstract entity that does not appear in the game, but rather takes inputs and issues commands to the pawn. Think of it as the body and the mind. Except in this case, the mind can control multiple bodies – you can assign more than one pawn to a single controller. For example, say you have a game where there is a single player with a gun and a bunch of randomly placed zombies. The undead aggressors, when they can’t see the player, will occasionally turn in some direction and amble for a bit, and then go back to looking around for something to chew on. When they happen to catch sight of the player, they start moving directly towards him or her until they get killed or get a mouth full of brains.

In this scenario, the enemy actions are pretty simple and you could easily create on Controller (extending GameAIController or just AIController) that controls all of the zombie pawns.  Each tick, the AI controller could iterate through the pawns and check to see if any of them can see the player or wants to move around.  If any of the zombies have their bCanSeePlayer flags set, they run at the player until they are close enough to attack.

Pretty simple and in that case, each zombie has basically the same kind of simple actions and the overall command of the enemy AI can be handled by one controller.

In the case of Fleet, I decided to go a different route.  In a multiplayer UT3-style shooter, each player controls his pawn directly.  Your inputs get translated directly into pawn actions.  With this game, I wanted the individual pawns to be able to act a little more autonomously after being issued a command, and with that in mind, I am giving each one their own controller.  Once given a command from the PlayerController (or the AIController), the pawn’s controller kicks in and commands the pawn to complete the motion.

One of the cool things about the Unreal Development Kit is that it comes packaged with basically a full game.  There is a small but substantial version of Unreal Tournament 3 included in the UnrealScript code provided when you download the kit.  While the team at Epic has taken strides to refactor as much of the core elements out the UT game into a separate part called UDKGame, the UTGame code is there available to learn from, or if you are so inclined, to extend off of.

If you are working on a first person shooter or want similar functionality to a game like UT3, it might be beneficial to have your game type and other objects extend the UTGame classes.  In that specific circumstance, it can definitely save you a lot of work re-inventing the wheel – and provides a deep set of features to build off of.

However, if you are making any other sort of game, or (like me) want the experience of starting fresh and learning as you go, then extending from the base UDKGame may prove better in the long run.  Of course, you could take it a step farther and start from the classes that UDKGame extend from (living in the GameFramework folders or even the Engine folder) and build up from there, but UDKGame has a nice portfolio of features that make it worthwhile.

So, to get started, I created a folder in my Development/Src directory with the name ‘Fleet’ (the code name for the project).  Like with all UnrealScript folders, you then put a ‘Classes’ directory in there.  When this gets added to your config files, it takes all of the files inside and builds a package named after the folder the code is in.  Inside that folder, I create a new UnrealScript class to hold my new game type.  In the interest of organization, I’m prefacing my class names with ‘FLT’, so this would be FLTGame.  It looks a bit like this:

Source code

class FLTGame extends UDKGame;
 
static event class<GameInfo> SetGameType(string MapName, string Options, string Portal)
{
    return class'FLTGame';
}
 
function PostBeginPlay()
{
	Super.PostBeginPlay();
}
 
DefaultProperties
{
}

The important part is in the class declaration at the top, where I indicate that FLTGame is extending UDKGame.  The ‘SetGameType’ function is just another way (in addition to config files) to make sure that when you run the game, it sticks with FLTGame and doesn’t try to load another game based on map prefix or anything.  Although, if you wanted to, you could have multiple game types extending your game type and switch them based on a parameter or the map that is loaded.

Anyways, that’s just a framework.  I’m using a plugin on wordpress to do syntax highlighting, but it doesn’t specifically work for UnrealScript, so we’ll have to make due with C#.  We’ll see how it goes.

Once you get your game type going (there’s plenty of good references on setting up the config files and all that), you’ll want to work on your Pawn and Controller classes.  That was the next step for me. I’m a bit ahead of myself when it comes to development over blogging, so I have some catching up to do.  Until then, here’s a recent progress update video to show where I’m at with moving a pawn around.

The first step to any project like this is organization. There’s just too many moving parts in a video game, especially one based on a system like the Unreal Engine. You’ve got code and maps and materials and flash files and 3D models. It’s a lot to keep track of. So I’m going to go over how I organize everything.

1. UDK

The first step is actually getting the Unreal Development Kit.  It’s pretty simple – you go to http://www.udk.com/download and download the big-ass exe (1.2GB, thanks to all the new demo content and iOS stuff).  The UDK is updated almost monthly, however you don’t have to update every month.  In fact, it may make more sense not to upgrade often unless a needed feature or something is added or you need a performance boost that a new build might provide.  Otherwise, you will find yourself running into errors where your old code doesn’t work with the new framework, and you may end up spending a lot of time making sure that it does.

For me, I am working with the Dec 2010 build, and it’s working fine for me.  Any code samples I put up here will be based on that build until I say otherwise.

Once you get it downloaded, install it somewhere.  The folder you choose is going to hold all of your assets, so I would suggest not hiding it away too far.  I have a second hard drive for storage, so I created a folder off the root for my development projects and stuck the install in there.  You can leave the default name (which is based on the build date), but I usually name the directory after whatever I’m working on.  You’ll end up with five directories in the folder you point it at: Binaries, Development, Engine, MobileGame and UDKGame.  Binaries holds, as you would expect, all the .exes and .dlls for the engine and toolsets.  Development has all of your UnrealScript code and some ScaleForm flash stuff.  This is where most of the work for me happens.  Engine has a bunch of stuff I don’t touch.  MobileGame you can leave alone unless you are developing for the iPhone or iPad and UDKGame is where all of your content and config files for the game goes.

A note about multiple UDK installs – each time you install a new build of the UDK, it adds a new Start Menu entry and a new set of shortcuts.  Make sure if you have more than one version installed that you are opening the right tools.

2. Source Control

Let me tell you a story: A long time ago, I was stupid and just stored a single copy of my source files.  I would go in and make a bunch of changes and break stuff and then couldn’t go back and sometimes wasn’t even sure about everything I had changed.  Then my friend Joel introduced me to Perforce and I am no longer stupid.

Actually, while I had used source control for work before, I never really applied it to any personal projects, and paid the price.  So now I use Perforce which is free (for two users) and pretty easy to use. My Perforce workspace starts from the root directory of the UDK install, but I don’t include anything outside of the UDKGame and Development/Src folders, as that’s what I’ll be changing.

I am probably not the best person to give advice on setting up Perforce though, I always just muddle through it and get it to work.  It’s not difficult, I’m just not an expert and there’s plenty of those out there.

3. Visual Studio

Without any bickering and arguing about what is the best IDE for any given situation – I use Visual Studio 2010.  I’m lucky enough to have a MSDN subscription so I make use of it.  It works fine with the right tools installed for UDK development.

The right tool in this case is nFringe – a plugin for Visual Studio that provides all sorts of support for Unreal Engine development.  It not only gives you proper syntax highlighting and Intellisense, but there’s also a solution file you can download that is almost completely set up for coding and debugging.  It works pretty well, and you can set the map you want to load up and some other options.

It’s free for non-commercial projects.  And if you don’t have Visual Studio, you can get the free VS Shell (integrated mode) which it also supports.

4. 3D Modeling/Image Creation/ScaleForm

I’ll cover these together, as they go into more of the asset creation side of things.  I’m not terribly experienced with 3D modeling, but I’m going to give it a shot, and for that purpose, I’m using the free program Blender.  I’ll get to the pipeline for importing that stuff into the UDK when I actually reach that point, but I’m sure it will be an adventure fraught with me screwing things up.

For 2D work and Flash, I’m lucky enough to be married to a woman who just finished college courses in graphic design, so Photoshop and Flash from the Creative Suite are the order of the day, via student pricing.  There are plenty of alternatives, Gimp being the front runner in free graphics programs and this post on the UDK forums outlining a few additional choices for SWF and ActionScript editing (although Flash has a 30-day trial and is pretty cheap with a student discount).

That’s pretty much it for my setup.  Now you can know what to expect when I start detailing my workflow.  In the next post, I’ll go over digging into the code for the first time.

You must first invent the universe.

I have been playing around with the Unreal Development Kit from Epic Games since it was released more than a year ago, but never in a very serious context.

This changed recently as I took on what I think will be a fun project.  Although I’m not really going to go into the specifics of the game (it’s a surprise!), I thought it would be helpful for me as a developer and maybe for some people trying to get started with the UDK if I captured my experience with the toolset on this blog.

Hey, at least it will get me updating.

Some of the features of the game that I’ll be implementing and covering:

• Third person (free) camera that rotates around an origin point
• Getting started with the ScaleForm UI system
• Freeing the mouse input from the camera and creating a mouse cursor
• Selecting objects in space with the mouse
• ScaleForm UI elements and using the mouse to select them
• Multiple pawns for one PlayerController
• Moving pawns to waypoints

That’s probably enough to start with.  First I will go over my dev environment and source control.

There’s a long road ahead, but it should be fun and hopefully informative.