Controller Overview
A UT2003 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
- 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.
Comments
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.
