Why does PlayerController "own" the yaw pitch and roll, but the Character "owns" its location?

Hi folks,

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 just confused by the fact that the location is stored in the character itself but the rotation doesn’t seem to be?

Could somebody please help break this down for me and explain how I should “think about” character or pawn movement? I’m just unclear on it and it’s kind of causing me to get hung up on the topic.


Its a good question.

The Character inherits from Pawn, which inherits from Actor, which has a GetTransform, which it gets from transform of its RootComponent.

A Transform includes position and orientation.
So basically everything rendered in the world has a transform.

On the other hand, the Controller is focused on representing the human player and can possess and control pawns.

Part of control is the Control Rotation.
It is sometimes the pitch yaw and roll of the camera.

You might control a car, boat, plane, or monkey.
Your control rotation is often used to update the controlled Pawn transform.

It is not always direct, eg you might lerp the pawn rotation to match controller rotation over time.

As you are doing - you typically handle the input in the Controller and use it to modify the Character.


There are lots of permutations to the Camera / Character / Player-Controller settings. More than there are game genres and too many to sum up here. Usually its better to just work from ‘standard’ Character / Camera / Player-Controller templates. Safer than just trying to guess at things or hitting switches etc. For example, conflicting settings mean that even experienced devs have humbling moments sometimes. :stuck_out_tongue: So it helps to just build working templates / examples that you can go back to. Afterwards have fun experimenting and breaking things. :slight_smile:

Analogy / Analogies can help maybe with the Rotation vs Location query… Player-Controller (PC) is like the person operating the Camera in a Character’s own reality show… Your Character is concerned with which way its moving, looking and facing. But the PC is concerned with what’s being filmed and beamed back home to the viewers watching at home… So, the PC controls the actual game viewport, or which way the Camera is pointing and what’s actually being filmed. This can be confusing sometimes, as Cameras can be part of the Character or independent. The same goes for Game inputs etc. But for now… Think of the relationship as: Which way am I moving or facing… (Character). What am I actually looking at… (PC).

Overall there is a kind of symbiotic relationship connecting Character/Pawn + Camera + PC. However, PC has a much larger role to play ‘under the hood’. Take a step back for a second. The PC can tell the Camera to orbit around the Character, or it can just be a passive spectator in the game. The PC can be a means to do a level-flythrough, but it can also take charge of important things like respawning a Character when it dies, or showing a death-cam. Overall, PC is a way to look down on the action or Players / Characters in the game in a kind of ‘God-mode’. At any time, the PC can take over and control any Character it wishes. It can even be made to control multiple Characters at the same time. In that sense, the PC is like the human hand on a chessboard moving the Pawns around.

Lots of threads / docs like to talk about PC as the ‘will’ of the character or the human input. But its better to just focus on the practical side. For example… You need the PC to enable your Character to move between Third-Person-Vehicle and First-Person shooter modes and views. You need the PC to catch special inputs from Gamepads etc. The PC owns all the Menus and Healthbars and UI displaying Scores inside the game (although the character is often the one that updates these). The PC manages all the Cameras (camera shake etc), even if the Cameras appear to be bolted onto your Character directly.

What’s confusing sometimes is that Characters can get simple WASD inputs directly without seemingly using the PC at all. But that’s better thought of as a simple ‘pass-through’ method. As the PC still controls all of this under the hood. For example, if the PC drops a Character in favor of controlling another, inputs now go to the new Character, not the old one. Also, if the Character ever needs to know if several keys or buttons are pressed at once, this is the work of the PC again…

So to recap, but taking a slightly different approach… What if there was no PC…??? What if it didn’t exist at all as a concept inside the engine… Then who controls the Cameras / Views inside the game… Who captures Gamepad Inputs to tell Characters which way to move. Who respawns Characters when they die. BTW: This last part can be done using Gamemode in single-player too. Or you can cheat and avoid respawning Characters entirely by just hiding them for a few seconds and then re-displaying them. But normally this is all part of what the PC brings to the table. So when the Docs like to talk about the ‘Will’ of the Character or the Pawn, this is what they really mean…

The UE4 game framework is confusing until you keep repeating patterns or working in familiar scenarios or similar templates. Then it starts to get easier. Reading this might help get you started as well. Good luck… :slight_smile:

Thank you both, @franktech and @OptimisticMonkey. I’m pretty sure I have a better understanding of how to think about the controller interactions, now.

After looking at the AActor class, I see that it has a location and rotation that it keeps track of. The ACharacter class inherits this, too. From within my character class, I seem to be able to directly modify the actor’s rotation using SetActorRotation.

So, I’m assuming that when I instead use SetControllerYawInput that the Character class has some code in it somewhere that sees the Controller’s rotation data changes and then in turn modifies the Character’s own rotation data. I’ve not yet looked at the Character class code, but I’d expect to see in there, somewhere, some code that does this.


I think I found where the controller tells the pawn which rotation to be using …