Are these two generally interchangeable when it comes to implementing player characteristics like movement, inventory systems, and other functions specific to a player character.
The documentation seems to favor using the PlayerController for this but I’ve seen other people use the Player Pawn…
I ask because in a project I’m using for learning blueprints, I have everything blueprinted within my PlayerController instead of my Player (pawn).
I’m not sure where the huge difference would be. I’m sure there’s a correct answer for this, though. In my project, everything is on the Pawn. Granted, my project is not complex, but it is all working.
Maybe someone can pipe in here and let us know the “proper” way, or explain the pro’s and con’s of having all the blueprint stuff on the controller or pawn.
Thanks for the reply Tearl!
The huge difference is that when implementing the inventory system (with items) in the controller and you would change the pawn you are possessing, that pawn would also get your inventory, while the original one would loose it, (one controller can only posses one pawn), while if it’s on the pawn any controller or pawn logic could interact with the inventory items.
A better example would be that each character in a squad can do a number of actions per turn. The character you currently set the actions for are being controlled by the controller. If the number of actions where in the controller you would only have one set of values. Also if different pawn types have different actions, tank with fire cannon, a character with duck. If you implement this in the controller rather then on the pawn, your tank would know how to duck, and your character could shoot a non existing cannon.
Simply put a Controller is meant to controll, it is supposed to feed input and interaction to the pawn, so that in itself can handle the knowledge of itself and what it can do.
Is what I recon.
To expand on what TheSpaceMan said, the PlayerController can possess any pawn and any pawn can be possessed by a controller.
Ideally, you’d want to have custom events on the pawn drive its actions and have your PlayerController accept input.
Player moves joystick -> PC listens for joystick motion then modulates it (multiply it by runSpeed, for example) -> PC fires custom event on pawn (e.g. a custom event called “MoveForward” with a float input “Amount”) -> pawn moves
This allows you to have an AI controller possess this pawn. It would also allow the player to possess different characters throughout the course of the game without having to rewrite the logic to accept input. It would already be on the PlayerController. You would just need to set up some new custom events on the other pawn.
Of course, this is all optional. If you never change characters or have your pawn controlled by AI, then you can just put all the logic on the pawn and it’ll all work. PCs just make it a bit easier to separate player from pawn if you need to.
I’d personally recommend using them this way in every game. You never know when development plans change and you want to add a side-story with another character.
Thanks for the replies guys!
Jared when you say "PC fires custom event on pawn " do you mean the PC fires a custom event that was created within the pawn blueprint? That it’s just referencing it within the PC blueprint, but the actual logic of that custom event is stored within the pawn blueprint?
yes, You set the logic that affect to the visual part, the othe is better use the PC.
Hey, wouldn’t it be better to have all your input logic on the pawn? That way if your avatar jumps into a car - and all your input logic is on this avatar and car - changing what your PC is possessing should also change inputs right away. So this way all you have to do is possess any pawn/character/vehicle from your playerController and your input logic will change to that.
I’d be very interested in hearing if I’m wrong, I think I still have some learning to do when it comes to best practices.
Thanks.
Like what erWilly said, yes. PC is the brain, pawn is the body. The body has some stuff it knows how to do (custom events) and the brain just tells it to do those things. Logic for actually moving your pawn should live on the pawn itself while listening for input and modulating said input should live on the PC.
You can absolutely do it that way if you so choose. There’s no right way to do it. But the way I would do it is to have another PlayerController for the car. When the player enters the car, halfway through the animation I would switch the PC from the regular one to one that controls cars and have it possess this specific car and this car would derive from a master car class BP that has movement logic on it, and each derived car would change variables like handling, top speed, etc. This is because I’d probably want NPCs to drive off in the cars when they enter them as well. Having the movement logic on the car itself and having AI or PCs drive the movement would be more modular. If you put the input logic all on the car, it won’t be able to drive itself with AI.
Alternatively, you could make a boolean or enum for the PlayerController that does different stuff depending on whether or not the player is driving a car if having a second PC and switching on the fly doesn’t really work for your game, which is possible.
Ah I see. Yes that seems like the better option for more complex games. Thanks for the explanation!
You’re welcome! I hope everything is a bit more clear for you.