Legacy:Controller Overview

A UT200x player is composed of a number of classes that all work together to accept and process input from the player and handle collision with the world. Bots use much the same system, so processing of AI also takes place (for Bot-specific subclasses; more on that in a minute) within the same code. What follows is an attempt to explain the different classes involved and how they interact.

Controller

The base interface to a pawn.

• Receives events from the engine that are destined for the Pawn,
• Handles AI,
• Acts as an animation interface,
• Controllers are partially implemented using native code and have native replication,
• Most of the time, each Controller has a Pawn attached to it,
• A good way to visualise the Controller/Pawn interface is to consider the Controller the "brain" of a Pawn (which is the "body").

The class definition of Controller shows that it is an abstract class - this means that this isn't the class actually used in UT2003; human players use xPlayer while bots use xBot.

The gametype of the current Level specifies the type of Controller for bots and players to use. As bots don't cheat in UT2003, the xBot class doesn't have a number of security-related classes that the xPlayer has.

One of these differences is that a PlayerInput class is attached to each (human) player, and this processes keyboard/mouse/joystick input and (then) passes it to the Controller.

The other is the CheatManager class; this is involved with handling console commands (such as cheats such as "god") and other debug functions that can only be called in Instant Action (or other custom non-network gametypes).

Unlike The Matrix, Pawns can exist without Controllers and vice-versa. Indeed, the alternate firemode of the Redeemer creates a new Pawn that the Player's Controller possesses - this is how the Player's mouse/keyboard input is "mapped" onto the Redeemer.

Some Useful Properties

Engine.GameInfo.PlayerControllerClass 

This property defines the class to use to control the player. Changing this class will allow you to alter the view the player sees in first person, behind view, and spectator mode. It also handles lots of stuff that only execute on the client. The default value for this is not set although Engine.PlayerController (UnrealGame.DeathMatch specifies xGame.xPlayer) will be instantiated if a subclass of GameInfo fails to provide a default value by using the PlayerControllerClassName property.

Engine.GameInfo.DefaultPlayerClassName 

This property allows the default player class as displayed within the 3D world to be specified. The class specified by this property handles all the classic player pawn stuff (animation, physics, blah blah blah). The default value for this specified in UnrealGame.DeathMatch is xGame.xPawn.

Engine.PlayerController.CheatManager 

This property specifies the class to use to handle the cheat manager. If you want to add new console commands then this is the class you need to replace. The default value set within the PlayerController class is Engine.CheatManager.

Engine.PlayerController.PlayerInput 

This property specifies the class use to capture and process player input. So if you want to change the way double-click moving works or mouse smoothing then this is the place to start.

Related Pages

• Controller – Base class
  • AIController – Artificially intelligent agents
  • PlayerController – A slightly more in depth look at the relationship between player controllers and pawns.
• Engine_Concept – A list of definitions of terms used on this page.

Discussion

Tarquin: Merge needed of the two intros above. Since I don't know much about it, someone else should do it. The stuff on PlayerController has been moved to, well, PlayerController.

DJPaul: Started doing Mr. T's merge; hopefully it's not too bad.

scumble: It's an oversimplification to say that the Level determines the Controller used by Pawns. From what I found out recently, it's one of the defaultproperties in xPawn that specifies XGame.xBot as the controller. The GameInfo only specifies the Roster class. You have to get down to xRosterEntry before you find the code that returns xPawns for the Enemy team.

Daid303: It's says that the "gametype of the current Level" not the "Level" determines the controller class. And that's 100% true :) But yes, for bots it gets it from the Roster. But that's not true for normal players.

scumble: Yes, I meant gametype! I'm really advocating a little elaboration on the difference between how Bots and Players are spawned. They seem to work in opposite directions.

---

Category:Legacy To Do – Make this a more complete overview of all Controllers with relevant links to Controller and its subclasses.