I originally posted this question on answerhub but since it requires more of a discussion i’ll move it here (original post).
To represent an agent in the world we typically use 2 objects, a Pawn and a Controller. Think of the Pawn as the in-world representation of the agent and the Controller as the “will” or the “brain” that drives it. The Pawn is kind of like a sock puppet, with the PlayerController being the person whose hand is inside. A Controller can possess/unposses a pawn to take/release control of it. A Pawn doesn’t always have to have a Controller, and a Controller doesn’t always need to be possessing a Pawn.
Controllers come in 2 flavors, the AIController and the PlayerController, representing an artificial will and a human will respectively.
So in short, the PlayerController is the code representation of a human player’s will in the game.
To address your specific points…
- It’s fine to handle input in the Character. It’s a natural way to think of things, especially for less complex cases, so we made sure to support it. If you have more complex needs though, like multiple players on one game client or the ability to change characters dynamically at runtime, you might be better off keeping your input in the PlayerController.
- I’ve typically followed a marionette-style model, where the PlayerController decides what to do and just issues commands to the Pawn (e.g. “start crouching”, “jump”)
- For some things, it’s necessary. In MP, the Controller persists throughout the game while the Pawn can be transient (e.g. you die and respawn, you get a new pawn but your controller is the same).
- By default the possession/control relationship is 1:1. So a Controller can control at most a single Pawn, and a Pawn can be possessed by at most a single Controller. You could change that with the source though.
- This is something we’ve talked about internally several times. A PlayerController has a ControlRotation that’s useful for capturing rotation inputs. The actual position and rotation aren’t particularly useful themselves.
I hope that helps!
That actually really helped further my understanding of the relationship between a Pawn and Controller; thank you very much!
This is very helpful. Thank you!
I’m trying to control a player from an input stream using absolute values. How do I drive the Pawn using absolute positioning in the world space?
I may have answered my own question when I came across this function.
Can anyone confirm that this does set the absolute position in space? Also, does this require a Tick() function, or some other time based property? Or… is this updated with every new frame rendered?
You should just be able to call SetActorLocation on the Pawn whenever you want to move it.
Here’s a helpful link from documentation:
Sorry for bringing back an old topic… I figured it’s better than creating a new post.
So I’m trying to get the hang of controllers as well, and right now I actually have my controller doing the work of moving whomever it is currently possessing. After thinking about it though, it seems like that’s a horrible way to go as it limits all Actors it possess to one type of movement. Should I implement my gameplay functions (Move, Shoot, Jump, etc) within my character class and just have my controller call those functions when the bound inputs come through? That way I can have different actors move in different ways?
Yes, yes you should.
A controller represents something telling the pawn to do something.
Usually a player pressing input with is converted to logical words like WalkLeft Fire, Jump.
But the thing we didn’t cover in the previous topic where we also talk about this.
Is that if you want an AI to do the same thing as a player. You probably implement an AI controller. This becomes cumbersome if your logic for movement is in the controller.
Yeah I think a good way is to do the input in the controller and have functions in the pawn for example, in the controller read input Forward and sand it to a pawn function with MoveFwd event (takes the float). The controller understands input, the pawn knows how to move itself. that was calling MoveFwd on any pawn that can move forward will work. Doesn’t matter if the pawn is a character or a a tank.
From looking at the shooter example, it looks like the player controller binds input to generic things like checking leaderboards or chatting, not to movement specific input. If I have a player controller that unpossesses a ground pawn and possesses an aircraft, it would make sense for movement specific input to be bound within the classes of the actor types (AGround vs AAircraft). Am I understanding this correctly?
When a controller possesses a pawn, doesn’t it handle who is receiving input from the gamepad/keyboard? Like in my ground v. aircraft example, when I possess the aircraft and it binds all the inputs, what tells the input manager to stop sending input data to the ground unit?