Learning UnrealScript Appendix A — Updating Your UDK Version

Epic Games is amazing: not only do they release their top-of-the-line development tools for us to use for free, they also reward us with monthly beta updates. As great as this is, though, it can often be a serious problem for the UDK programmer.

The problem lies with the fact that Epic Games makes hundreds of changes to underlying functions and code every month. Because UnrealScript is a tightly-coupled language (it depends a lot on its parent classes to work right), any changes that Epic makes means you will need to make just as many changes in your own code. Don’t believe me? Just take the source folder of one of your old projects and copy it over to a newer version, then recompile. I guarantee you will get a load of errors.

So how do we deal with this? I’ve been working with UDK pretty much since it came out, so I’ve figured out how to streamline the process. Here’s what I do.

It might be tempting to get every new version of UDK as it comes out, but the time it takes to update all of your game assets will severely impact your progress. I find it best to choose a “good” version and stick with it until your project/game is completed.

When each new version comes out, I download it and evaluate it based on several factors (changes to code, apparent bugs, ease to work with, etc.). These versions I’ve found to be the best:

  • February 2010 (old UI, closest to UT3 code)
  • March 2011 (ScaleForm, most stable menu/graphic additions)
  • November 2011 (AS3 support, extremely fast loading times)

Such an evaluation process only takes an hour or so, which really saves development time. But remember, be extremely critical of the engine: I delayed moving my project over to the newer ScaleForm versions for 8 months just because I felt UDK wasn’t up to par for it yet.

Ideally your code should only depend on Core and Engine; that is, you could delete UDKBase and UTGame and your game would still run fine. Of course for most people this is highly impractical, but at the very least attempt to move important game classes to extend Engine. For example, my game classes usually extend GameInfo, not UTGame. This results in less errors that I have to catch when I do decide to switch UDK versions.

One of the biggest sources of errors is Epic changing from Unreal Tournament to Unreal Development Kit — UTPawn becomes UDKPawn, UTPlayerController becomes UDKPlayerController, etc. I’ve found that running a “Replace All” on UT to UDK is usually successful in clearing up most of the errors in my code. However, note that this is a quick fix and not guaranteed to work all the time.

Once I start making changes to the config files, folders, and packages of a fresh UDK install, I write down every change I make in some sort of log file. Some examples of entries in this file:

  • Added “+Edit Package” line to DefaultEngine.ini
  • New .upk in Content\Music, “NETMusic”
  • Added new level info in utgame.int, “NE-Base”

The reason for this is that the way your game works is very much tied in to how the config files, localization files, packages, and scripts interact with each other. Just copying your code over to a new version won’t get your game up to speed; you also have to go in and make all those little changes in .ini’s and .int’s. Yea, it’s annoying, but keeping a log of your changes will make the moving process a lot more hassle-free.

Using these basic tips and some good old-fashioned ingenuity, I can usually move a complex game to a new install in just a few hours. Not bad when you consider the benefits such a move will earn you.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s