PlayerController vs Character: Are the Template projects actually doing it wrong?

Hello,

I am currently trying to setup some input stuff in my Project and find it odd, that the template projects actually set Input bindings inside the Character Classes. Now, if I understand things right, the Character, is supposed to be the representation of the player in the actuall game world, while the player controller sort of represents the players will. Now, shouldn’t that mean that input bindings belong to the actuall player controller? Since the input is the manifestation of the players will. If so, how do I actually tackle this? I guess I need to implement the player controller. But then what? Where do I set the player controller and how do I actually make the connection between the Input and the Character itself? In the templates, actions are bound to methods of the actuall character, like moving and Jumping. I imagine, for example if I were to use the same base Character class for the actual player Character and AI Characters, this would not work they way it has been implemented in the Templates aswell. Am I right? Because the input is bound inside the character.

Or am I getting something wrong here?

This is like the 3rd or 4th topic about this whole relation between those components and everytime i think I understood how they work, new questions arise. Please excuse my lack of understanding here but I really want to use everything the way it is supposed to be.

Thank you very much :slight_smile:

1 Like

Well now I feel dumb:

Just a couple of moments after writing this, a nice Wiki page came my mind.

And this actually explains some things quite good: PlayerController | Unreal Engine Documentation

However, I still could use some example of implementing own PlayerControllers.

There is not always a need for an extra PlayerController, but sometimes it is necessary to prevent messy code. Since the templates are rather simple, you don’t really need them.

One good example where PlayerControllers help would be a multiplayer shooter. If you die, you enter a spectator state for a set amount of time. With a PlayerController you can just unposses the dying pawn and handle the spectator stuff in the PlayerController and keep your Pawn-class clean. When you can respawn, you just spawn a new Pawn and posess it with your PlayerController.

Another prime example would be entering vehicles. You can just unposses your pawn and posess the vehicle and route the input to the vehicle instead and vice versa if you leave it again.

So your own PlayerControllers are always necessary when you want to dynamically posess and unposses different pawns. If this is not the case, you might aswell leave them out.

Here’s my wiki tutorial on how to add a player controller to a C++ project :slight_smile:

Enjoy!

Rama

Ok. Let’s repeate, analogy that has been used many times here. Controller is brain and character is body.

Assuming we live in Dune World, you could take brain out of your body and implant it into any other body, and each body would have different functionality, but you would still interface with that body using your brain.

The rule of thumb is, if you need some control (input) options available on global level to player, you should put them in Player Controller.

If some input is specific only to the specific character, you might want to put it inside Character class.

I personally tend to do most of my input stuff inside Player Controller, and from there route it currently controlled pawn (note Pawn not character). To make most out of it, you must abstract what are you controlling into interfaces/components which are easy to reuse in many actors.

For example I devised that all weapon need is simple interface which have functions responsible for input, and every actor implementing this interface could be called.

In my player controller i check if actor have this interface (when player press fire button). Controller doesn’t care which pawn in control, as long as weapon, which pawn holds, implement this interface.

1 Like