UnrealScript Language Reference/Introduction

Design Goals of UnrealScript

UnrealScript was created to provide the development team and the third-party Unreal developers with a powerful, built-in programming language that maps naturally onto the needs and nuances of game programming.

The major design goals of UnrealScript are:

• To support the major concepts of time, state, properties, and networking which traditional programming languages don't address. This greatly simplifies UnrealScript code. The major complication in C/C++ based AI and game logic programming lies in dealing with events that take a certain amount of game time to complete, and with events which are dependent on aspects of the object?s state. In C/C++, this results in spaghetti-code that is hard to write, comprehend, maintain, and debug. UnrealScript includes native support for time, state, and network replication which greatly simplify game programming.
• To provide Java-style programming simplicity, object-orientation, and compile-time error checking. Much as Java brings a clean programming platform to Web programmers, UnrealScript provides an equally clean, simple, and robust programming language to 3D gaming. The major programming concepts which UnrealScript derives from Java are:
  • a pointerless environment with automatic garbage collection;
  • a simple single-inheretance class graph;
  • strong compile-time type checking;
  • a safe client-side execution "sandbox";
  • and the familiar look and feel of C/C++/Java code.
• To enable rich, high level programming in terms of game objects and interactions rather than bits and pixels. Where design tradeoffs had to be made in UnrealScript, I sacrificed execution speed for development simplicity and power. After all, the low-level, performance-critical code in Unreal is written in C/C++ where the performance gain outweighs the added complexity. UnrealScript operates at a level above that, at the object and interaction level, rather than the bits and pixels level.

During the early development of UnrealScript, several major different programming paradigms were explored and discarded before arriving at the current incarnation. First, I researched using the Sun and Microsoft Java VM?s for Windows as the basis of Unreal?s scripting language. It turned out that Java offered no programming benefits over C/C++ in the Unreal context, added frustraging restrictions due to the lack of needed language features (such as operator overloading), and turned out to be unfathomably slow due to both the overhead of the VM task switch and the nefficiencies of the Java garbage collector in the case of a large object graph. Second, I based an early implementation of UnrealScript on a Visual Basic variant, which worked fine, but was less friendly to programmers accustomed to C/C++. The final decision to base UnrealScript on a C++/Java variant was based on the desire to map game-specific concepts onto the language definition itself, and the need for speed and familiarity. This turned out to be a good decision, as it has greatly simplified many aspects of the Unreal codebase.

Example Program Structure

This example illustrates a typical, simple UnrealScript class, and it highlights the syntax and features of UnrealScript. Note that this code may differ from that which appears in the current Unreal source, as this documentation is not synced with the code.

//=============================================================================
// TriggerLight.
// A lightsource which can be triggered on or off.
//=============================================================================

class TriggerLight extends Light;

//----------------------------------------------------------------------------
// Variables.

var() float ChangeTime; // Time light takes to change from on to off.
var() bool bInitiallyOn; // Whether it's initially on.
var() bool bDelayFullOn; // Delay then go full-on.

var ELightType InitialType; // Initial type of light.
var float InitialBrightness; // Initial brightness.
var float Alpha, Direction;
var actor Trigger;

//----------------------------------------------------------------------------
// Engine functions.

// Called at start of gameplay.
function BeginPlay()
{
       // Remember initial light type and set new one.
       Disable( 'Tick' );
       InitialType = LightType;
       InitialBrightness = LightBrightness;
       if( bInitiallyOn )
       {
               Alpha = 1.0;
               Direction = 1.0;
       }
       else
       {
               LightType = LT_None;
               Alpha = 0.0;
               Direction = -1.0;
       }
}

// Called whenever time passes.
function Tick( float DeltaTime )
{
       LightType = InitialType;
       Alpha += Direction * DeltaTime / ChangeTime;
       if( Alpha > 1.0 )
       {
               Alpha = 1.0;
               Disable( 'Tick' );
               if( Trigger != None )
                       Trigger.ResetTrigger();
       }
       else if( Alpha < 0.0 )
       {
               Alpha = 0.0;
               Disable( 'Tick' );
               LightType = LT_None;
               if( Trigger != None )
                       Trigger.ResetTrigger();
       }
       if( !bDelayFullOn )
               LightBrightness = Alpha * InitialBrightness;
       else if( (Direction>0 && Alpha!=1) || Alpha==0 )
               LightBrightness = 0;
       else
               LightBrightness = InitialBrightness;
}

//----------------------------------------------------------------------------
// Public states.

// Trigger turns the light on.
state() TriggerTurnsOn
{
       function Trigger( actor Other, pawn EventInstigator )
       {
               Trigger = None;
               Direction = 1.0;
               Enable( 'Tick' );
       }
}

// Trigger turns the light off.
state() TriggerTurnsOff
{
       function Trigger( actor Other, pawn EventInstigator )
       {
               Trigger = None;
               Direction = -1.0;
               Enable( 'Tick' );
       }
}

// Trigger toggles the light.
state() TriggerToggle
{
       function Trigger( actor Other, pawn EventInstigator )
       {
               log("Toggle");
               Trigger = Other;
               Direction *= -1;
               Enable( 'Tick' );
       }
}

// Trigger controls the light.
state() TriggerControl
{
       function Trigger( actor Other, pawn EventInstigator )
       {
               Trigger = Other;
               if( bInitiallyOn ) Direction = -1.0;
               else Direction = 1.0;
               Enable( 'Tick' );
       }
       function UnTrigger( actor Other, pawn EventInstigator )
       {
               Trigger = Other;
               if( bInitiallyOn ) Direction = 1.0;
               else Direction = -1.0;
               Enable( 'Tick' );
       }
}

The key elements to look at in this script are:

The class declaration

Each class "extends" (derives from) one parent class, and each class belongs to a "package", a collection of objects that are distributed together. All functions and variables belong to a class, and are only accessible through an actor that belongs to that class. There are no system-wide global functions or variables.

The variable declarations

UnrealScript supports a very diverse set of variable types including most base C/Java types, object references, structs, and arrays. In addition, variables can be made into editable properties which designers can access in UnrealEd without any programming.

The functions

Functions can take a list of parameters, and they optionally return a value. Functions can have local variables. Some functions are called by the Unreal engine itself (such as BeginPlay), and some functions are called from other script code elsewhere (such as Trigger).

The code

All of the standard C and Java keywords are supported, like for, while, break, switch, if, and so on. Braces and semicolons are used in UnrealScript as in C, C++, and Java.

Actor and object references

Here you see several cases where a function is called within another object, using an object reference.

The state keyword

This script defines several "states", which are groupings of functions, variables, and code which are executed only when the actor is in that state.

Note that all keywords, variable names, functions, and object names in UnrealScript are case-insensitive. To UnrealScript, "Demon", "demON", and "demon" are the same thing.

The Unreal Virtual Machine

The Unreal Virtual Machine consists of several components: The server, the client, the rendering engine, and the engine support code.

The Unreal server controls all gameplay and interaction between players and actors. In a single-player game, both the Unreal client and the Unreal server are run on the same machine; in an Internet game, there is a dedicated server running on one machine; all players connect to this machine and are clients.

All gameplay takes place inside a "level", a self-contained environment containing geometry and actors. Though UnrealServer may be capable of running more than one level simultaneously, each level operates independently, and are shielded from each other: actors cannot travel between levels, and actors on one level cannot communicate with actors on another level.

Each actor in a map can either be under player control (there can be many players in a network game) or under script control. When an actor is under script control, its script completely defines how the actor moves and interacts with other actors.

With all of those actors running around, scripts executing, and events occuring in the world, you're probably asking how one can understand the flow of execution in an UnrealScript. The answer is as follows:

To manage time, Unreal divides each second of gameplay into "Ticks". A tick is the smallest unit of time in which all actors in a level are updated. A tick typically takes between 1/100th to 1/10th of a second. The tick time is limited only by CPU power; the faster machine, the lower the tick duration is.

Some commands in UnrealScript take zero ticks to execute (i.e. they execute without any game-time passing), and others take many ticks. Functions which require game-time to pass are called "latent functions". Some examples of latent functions include "Sleep", "FinishAnim", and "MoveTo". Latent functions in UnrealScript may only be called from code within a state, not from code within a function.

While an actor is executing a latent function, that actor's state execution doesn't continue until the latent function completes. However, other actors, or the VM, may call functions within the actor. The net result is that all UnrealScript functions can be called at any time, even while latent functions are pending.

In traditional programming terms, UnrealScript acts as if each actor in a level has its own "thread" of execution. Internally, Unreal does not use Windows threads, because that would be very inefficient (Windows 95 and Windows NT do not handle thousands of simultaneous threads efficiently). Instead, UnrealScript simulates threads. This fact is transparent to UnrealScript code, but becomes very apparent when you write C++ code which interacts with UnrealScript.

All UnrealScripts execute in parallel. If there are 100 monsters walking around in a level, all 100 of those monsters' scripts are executing simultaneously and independently.

Class Overview

Before beginning work with UnrealScript, it?s important to understand the high-level relationships of objects within Unreal. The architecture of Unreal is a major departure from that of most other games: Unreal is purely object-oriented (much like COM/ActiveX), in that it has a well-defined object model with support for high-level object oriented concepts such as the object graph, serialization, object lifetime, and polymorphism. Historically, most games have been designed monolithically, with their major functionality hardcoded and unexpandable at the object level, though many games, such as Doom and Quake, have proven to be very expandable at the content level. There is a major benefit to Unreal?s form of object-orientation: major new functionality and object types can be added to Unreal at runtime, and this expansion can take the form of subclassing, rather than (for example) by modifying a bunch of existing code. This form of extensibility is extremely powerful, as it encourages the Unreal community to create Unreal enhancements that all interoperate.

• Object is the parent class of all objects in Unreal. All of the functions in the Object class are accessible everywhere, because everything derives from Object. Object is an abstract base class, in that it doesn't do anything useful. All functionality is provided by subclasses, such as Texture (a texture map), TextBuffer (a chunk of text), and Class (which describes the class of other objects).
• Actor (extends Object) is the parent class of all standalone game objects in Unreal. The Actor class contains all of the functionality needed for an actor to move around, interact with other actors, affect the environment, and do other useful game-related things.
• Pawn (UT) (expands Actor) is the parent class of all creatures and players in Unreal which are capable of high-level AI and player controls.
• Class (expands Object) is a special kind of object which describes a class of object. This may seem confusing at first: a class is an object, and a class describes certain objects. But, the concept is sound, and there are many cases where you will deal with Class objects. For example, when you spawn a new actor in UnrealScript, you can specify the new actor?s class with a Class object.

With UnrealScript, you can write code for any Object class, but 99% of the time, you will be writing code for a class derived from Actor. Most of the useful UnrealScript functionality is game-related and deals with actors.

The Class Declaration

Each script corresponds to exactly one class, and the script begins by declaring the class, the class?s parent, and any additional information that is relevant to the class. The simplest form is:

class MyClass extends MyParentClass;

Here I am declaring a new class named "MyClass", which inherets the functionality of "MyParentClass". Additionally, the class resides in the package named "MyPackage".

Each class inherets all of the variables, functions, and states from its parent class. It can then add new variable declarations, add new functions (or override the existing functions), add new states (or add functionality to the existing states).

The typical approach to class design in UnrealScript is to make a new class (for example a Minotaur monster) which expands an existing class that has most of the functionality you need (for example the Pawn class, the base class of all monsters). With this approach, you never need to reinvent the wheel ? you can simply add the new functionality you want to customize, while keeping all of the existing functionality you don't need to customize. This approach is especially powerful for implementing AI in Unreal, where the built-in AI system provides a tremendous amount of base functionality which you can use as building blocks for your custom creatures.

The class declaration can take several optional specifiers that affect the class:

native

Says "this class uses behind-the-scenes C++ support". Unreal expects native classes to contain a C++ implementation in the DLL corresponding to the class?s package. For example, if your package is named "Robots", Unreal looks in the "Robots.dll" for the C++ implementation of the native class, which is generated by the C++ IMPLEMENT_CLASS macro.

abstract

Declares the class as an "abstract base class". This prevents the user from adding actors of this class to the world in UnrealEd, because the class isn't meaningful on its own. For example, the "Pawn" base class is abstract, while the "Brute" subclass is not abstract ? you can place a Brute in the world, but you can't place a Pawn in the world.

guid(a,b,c,d)

Associates a globally unique identifier (a 128-bit number) with the class. This Guid is currently unused, but will be relevant when native COM support is later added to Unreal.

transient

Says "objects belonging to this class should never be saved on disk". Only useful in conjunction with certain kinds of native classes which are non-persistent by nature, such as players or windows.

config(section_name)

If there are any configurable variables in the class (declared with "config" or "globalconfig"), causes those variables to be stored in a particular configuration file:

• config(system) – Uses the system configuration file, Unreal.ini for Unreal.
• config(user) – Uses the user configuration file, currently User.ini.
• config(whatever) – Uses the specified configuration file, for example "whatever.ini".

---

Section 1 of 9 – Next Page: /Variables

See also: Class Syntax