Controller and Pawn

Development Programming & Scripting Blueprint
, , , ,
1

Hi guys.

I always used a Character, since it’s the fastest way to implement easy functionality.
But using a character has many restrictions.

I wanted to switch to Controller and a separate Pawn and I have a problem understanding the concept.

How do I tell my pawn that it has to move left, If I press the left analog stick?
I can’t access the Axis Values from my pawn.

2

This can be a tough concept to grasp and there is a good bit of grey area. The way I think of is:

  • The Controller represents the will of the player. This is where you put movement logic and the like. In general this is the first layer after player input. That last statement might go a bit far but it’s generally how you can think of it.
  • The Pawn is the players representation in the world. This is the thing that accepts the will of the player within the various constraints that you set.

Here is another good answer to this part of the question: PlayerController vs Character - Character & Animation - Epic Developer Community Forums

To directly answer your question, you would use the AddMovementInput() and AddControllerYawInput()/AddControllerPitchInput() from the controller. There is also a handy GetControlledPawn() node that can be accessed from the controller.

We generally use a Pawn for AI characters and Character (which inherits from pawn) for player characters. This a general guideline we follow but is not necessary and may not be right for your game though, just food for thought.

3

Isn’t the purpose of Controllers that a pawn can be used by different controllers? When using “getControlledPawn()” I have to cast it to the specific pawn. Checking the correct type is something you shoudln’t do often in a object oriented language like C++ (or in this case with blueprints, which is based on C++)

The same from the other side. when using “getController()” of the Pawn, I have to cast to the correct controller to get the pawn moving or doing different things.

4

Correct, if you are casting a bunch then you’re doing something wrong. One way to get around this is interfaces that hold the contract for the controllers interaction with the pawn.

Our game is structured so that you only ever have one pawn that you control. Even when you die we don’t destroy the pawn you’re using, dead and downed are states we manage as well as respawning. And since all of our characters have the same input to action making (just a different action implementation in the pawn) we can use one controller and just fetch and cast the pawn once as well.

Another option would be to implement your own controller (inheriting from the existing controller) that takes in a base version of your pawn where you keep the contract between the pawn and controller. Keep in mind that what epic has done for us very very generic and with that level of abstraction comes a few sacrifices (like needing to cast) especially since blueprints don’t support any form of generics.