Hi faselbaum!
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!