I'm new to UE4 and am trying to understand some basics concepts around controlling a character pawn. I'm fumbling around trying to implement some character movement logic. I'm going for the basic WASD to move the character forward, back, side to side - like in pretty much every basic first person shooter. I also want the mouse input to rotate the character around.
I've got my own custom PlayerController
and Character
classes.
Adding the code to move the character around - front, back, sideways - seems to all go in the character class itself. There is a method in there called AddMovementInput that appears to modify the position for me. This also makes me think that the character class "owns" its own location. That makes sense because there could be more than one character class at a time, each at different locations, right?
Adding the code to rotate the character has similar methods for controlling rotation - AddControllerYawInput
, AddControllerPitchInput
, AddControllerRollInput
. Simply looking at the names of the functions suggests that the yaw pitch and roll are "owned" by the player controller. Looking at the docs and comments for the functions further backs that up: "Add input (affecting Yaw) to the Controller's ControlRotation, if it is a local PlayerController." So it would seem, to me, that the yaw pitch and roll are values "owned" by the player controller, right?
As a beginner, this confuses me: I'm confused by the fact that the location is stored in the character itself but the rotation doesn't seem to be.
I am interested to learn how I should "think about" character or pawn movement. I'm just unclear on it and it's causing me to get hung up on the topic.
Windows. Get the control rotation. This is the full aim rotation, which may be different than a camera orientation (for example in a third person view), and may differ from the rotation of the controlled Pawn (which may choose not to visually pitch or roll, for example).
A PlayerController is the interface between the Pawn and the human player controlling it. The PlayerController essentially represents the human player's will. One thing to consider when setting up your PlayerController is what functionality should be in the PlayerController, and what should be in your Pawn.
The intention behind this design is to separate the Control Mechanics from the Character Physics. In terms of writing software, the idea is to decouple the player control's rotation in terms of the gameplay interaction mechanism from the character's rotation inside the game-world physics. For example, I can be aiming upwards while my character's body is somehow leaning downwards -- and so may physically collide with an object positioned beneath it.
See, you are right in your observations regarding "who owns what". You can see that AController
, base class of PlayerController
, has a member variable ControlRotation
of type FRotator
. The documentation for this data member says:
ControlRotation (accessed via GetControlRotation() ), determines the viewing/aiming direction of the controlled Pawn ...
And GetControlRotation()
further clarifies:
This is the full aim rotation, which [...] may differ from the rotation of the controlled Pawn (which may choose not to visually pitch or roll, for example).
As in, the controller rotation is being kept in separate from anything "rotation related" that the character manages for itself.
This is further supported in the documentation, for example see under Pawn
(base class of ACharacter
):
Pawn is the base class of all actors that can be possessed by players or AI. They are the physical representations of players and creatures in a level.
and under AController
:
Controllers are non-physical actors that can possess a Pawn to control its actions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With