I don't understand the Player Controller nodes

There seems to be a-lot of misconception surrounding the player controller nodes. I’ve read multiple forum pages and all say something different. The documenation was no help either.

What I’m having difficulty with is how ‘get player controller’ and ‘get player camera’ etc know what pawn to use (is it the pawn its attatched to?). I was under the impression that the gamemode class was what determined what pawn to use per level and the playercontroller class being an additional helper if one wanted to say, switch control to a car pawn using the posess node (the car actor having all the blueprint code to make it move. The player actor having all his movement blueprints as-well) I have watched tutorials that don’t set or create a gamemode or playercontroller class so maybe thats adding to my confusion by them missing a step.

Does the get player controller have anything to do with the inputs you set? whether or not a gamepad or keyboard or mouse is connected?

Does unreal assume what the default pawn is if you don’t set it? Is that what get player controller does?

What is the return type of get player controller? No one seems to mention that either. Is it the pawn? The playercontroller class?

I’d appreciate some clarity because this is driving me bananas.

I will try to explain it, being not too technical, but enough for you to understand the concept, since most game engines have the concept of player controllers.

Player Controller is a class very small used to drive user input to the player pawn. That input can come anywhere: mouse, keyboard, gamepad, virtual input (like actions controlled by AI, in this case AIController would be used instead), etc

Player Controller exists to simplify the work one would have to do in order to process user input and also have implications when dealing with networking.

At the game client there can be only one player controller, while at the server side, there are as many player controllers as players concurrently playing the level, and since the player controller class is very small, there is not much overhead at the server side dealing with so many of them (theoretically).

At the game client you can have a lot of pawns, but you can only control one at a time, meaning that you can assign to a pawn the “one” player controller created at the playing level.

With the explanations above, the return type of a player controller is the instance of a certain player controller currently active for you client side, and since there can be only one player controller at client side, whenever you want the current pawn being controlled, you need to supply the controller using “get player controller” to accurately retrieve the correct pawn when you need it.

Let me know if you understood the above and what else I could say to complement what you need to know.

A Pawn itself is just a possessable object that appears in scene. It’s basically an Actor with some additional functionality that makes it possessable.

A Controller is what “possesses” the Pawn and sends commands to it. PlayerControllers and AIControllers are subclasses of Controller, and you can also create your own Controllers to process input or events in customized ways.

GetPlayerController is getting the PlayerController for a particular player, which is specified by its index argument (0 for single-player, > 0 for some players in multiplayer). It’s intentionally Pawn-agnostic because by design, it’s not supposed to return a Pawn, and the player could be controlling any Pawn at any time.

The Game Mode determines the default Pawn to use for PlayerControllers, but you could switch the Pawn for any or all controllers at any time.

It can. Most tutorials I’ve watched process input actions/axes directly on the player’s Pawn BP. But imo this is bad practice if you want to be able to switch pawns at runtime (e.g., between a humanoid, car, and free camera). It’s better to process input all in one place on a custom PlayerController and have the controller send events to whatever pawn it happens to be possessing at the time, so each pawn class can implement its own behavior (for example, a car or freecam shouldn’t be able to “jump”).

No - see above. It’s not necessary to know what pawn is being possessed by a controller if you just want the controller itself.

The last one - it’s a reference to an object of type PlayerController.

In response to NilsonLima, I have used Unity Breifly in the past. Would it be fair to say The PlayerController nodes are similiar to Unitys Character Controller components? Its there so you don’t have to hard code inputs yourself. So the player controller node basically says: 'This pawn is being controlled, please refer to inputs set and move in the appropriate direction when the corrosponding event fires. I.e W is move on the forward vector and S would be the opposite.

So the player controller node doesn’t need a player controller class to be created or set by default? Thats my confusion really, does it require a player controller class to work?

In Response to DsyD, in your example you’d have all the movement code and other things like inventory and variables in a player controller class and (I presume) put the characters animations on the actor (i imagine animations can occur when events fire. Haven’t looked into that yet before i get my head around the actual scripting). And a possess pawn would be used to switch and detect what kind of actor you’re controlling if needed.

I feel like if the node and class don’t have much in common it was a mistake to give them the same name.

I imagine the index is for splitscreen? Because in multiplayer everyones player one on their system. Just playing together on a single server. I would ask how it can tell players apart if multiple game pads are connected but thats probably for another time.

In my example, the code to move each pawn would be on each pawn’s BP. The controller is the only place where input action\axis events appear, so that all of them are processed in the same place. The controller takes the input and calls events like “PawnMoveForward” or “Jump” on whatever pawn it’s controlling at the time. The pawn class decides what to do in response. That way it can handle move (e.g., Add Movement Input) or turn or jumps however it wants or choose to ignore some commands. If it just “listens” for events like that, it doesn’t need to know what controller class it controlling it, so it doesn’t need to “detect” a controller change or anything.

Player indexes is not just for split screen. In a MP game the player may be the only one locally, but the server (and therefore the game) needs to keep track of all players. So obviously player indexes are important :wink:

Player Index is for local multiplayer, yes. When creating multiple players for a local multi game, you’ll need to create multiple player controllers. In so doing, each one will get its own player index that increments by one over the last. It would be best to keep track of which PC has which index on your end so you can act upon specific player controllers.

One way to think about the difference between Player-Controller vs Pawn is functionality:

In-game a Pawn can change from Creature to Motorbike to Spaceship to Humanoid etc.

A character / vehicle Pawn can also die and need to be re-spawned back into the game.

You also need a place to define and then capture all Player ‘keyboard / gamepad’ input.

Plus, what if the game offers in-game Player-Customization or some kind of re-skinning.

The camera system must also be separate. Think of Local Co-op Multiplayer games etc.
Example: Topdown game with a single-camera view but multiple local players on-screen.
In single-player too, you can even store things like score & health in PC if you so choose.

So some kind of ‘master class’ outside Pawn is needed to house all this key functionality.

Sorry but I just don’t understand what the nodes are, what they do, how they do it and how you use them. Do they have anything to do with the player controller classes and do you need a player controller class?

When you create a project using any of the available project templates Player Controller instances are created in a game automatically according on what those templates set internally (settings that you can change). If you want to spawn a character, usually that character has a setting telling which player controller will be used, if it is an AI character, you can set it as AIController.

Sometimes when coding a game, being in C++ or Blueprints, some nodes that do actions on a character or a pawn, needs to know as input which is the player controller, and those nodes has this functionality, return a reference to an instance of a player controller which is in use by that character or pawn.

Once you start checking some game code and coding yourself, it will be easier to understand. Getting hands dirty coding sometimes are the easiest way to understand how things works.

PS: your questions got answered already by what several people have answered already. Your main issue is understand the classes hierarchy inside Unreal and what is automatically instanced for you: World, GameInstance, GameMode, PlayerController, etc

Thats a pretty unsatisfying answer but I’ll take it.

Just made a quick video, analyzing what you asked and how to improve answers if improving questions maybe…

Nilson Lima I apologise for being rude, especially after taking the time to make a 30 minute video trying to address my confusion. Thank you sincerely, clearly I have much to learn about being part of a community.

I’m going to chalk this up to me being an idiot. I’ve been binge watching and reading tutorials non-stop from all over the place, the manual, videos and forum posts.

And instead of focusing on what was was said I would research every little thing I didn’t understand (regardless of how relevant it was to my project or personal interests) my question is so vague because I wasn’t asking with one project in mind but any project that could exist. (I’m sure you know the feeling of your mind racing at 100mph)

Hence this forum post.

Sorry for wasting everyone’s time, clearly I don’t yet know enough to ask this sort of question so I will take a break and figure out where to start.

And about the Unity thing. My exposure was brief because I did the exact same thing. I got in over my head and it left a bad impression.

I have to say I’m having a hard time figuring out just what it is that your attempting to do but I do agree that it is confusing to figure out just what Epic’s intention of design is until one is exposed to all of the nuts and bolts but what is clear is that Epic is taking a top down approach as to component design instead of making a bottom up feature as to absolute function and a lot of terminology can only be applied with in a context (what does the “player controller” needs to do)

Kind of like the term "shader: can mean a lot of different things and is not just limited to or implies a material.

Another term used is “Pawn”

Like saying “I was making a cake and added two eggs (pawns)” as compared to “Today I made some scrambled eggs (pawns)”. Same word but different context.

As mentioned a pawn, in context, can only have one controller and a player controller implies an object that the player can control but data driven input is also another type of controller (live update) but one is not limited to what has been provided by Epic as a “just make it work” feature as it’s up to the end user to add the additional features based on their needs.

This is why such questions are hard to answer, with out context, as due to the top down nature of UE4 there are 1001 ways of doing the same thing different ways and I think Nilson did a good job of a very basic primer.


You can assume that if it’s out of the box what is provide will not work as to your expatiation and not to be nasty but the questions are not very clear as once again they lack context of what you are tying to do


Now if you were trying to figure out how the 3rd person template works it would be far easier to explain how it works as everything you have asked is present with in that template as an example and with in context. :wink:

Just saying.

P.S. P.S.

Posted before watching the video :smiley:

@BanterBabbx No need to apologize and I didn’t take it as a rudeness at all. There was one day I was in the same boat as you. The only thing I was proficient when I started learning UE4 was C++ programming and at 1st thought it should have made my life easier, but was not. I started learning from the wrong path, imagining that if I started to read the documentation and C++ source code I would end up learning something, and I discovered I wasn’t learning at all, but getting more and more confused.

The best way to learn, now that has passed 4 years (I started at 2015 and not 2016), I have experience enough to understand that I was completely wrong and if I had someone to give me hints from where to start, probably I would not have expended hundreds of hours watching things that I was not prepared to do. So, if I can be of assistance regarding this, my counsel:

  • create one project of each template and study them separately
  • compare the differences and trying to understand why the differences
  • study the learning resources at the launcher’s Learn tab. The Content Examples project is awesome to explain and showcase every feature present in the engine
  • try the new learning portal and choose a learning path (I myself will watch all of them, because I think we all need to extract every single bit of information, even if that will result in 2% of the entire content)
  • grab all the free stuff at the marketplace
  • learn to make materials, it is the most basic, use the Content Examples and the free stuff to see how people do
  • learn about making particles, takes time, so take be basic stuff first
  • learn about making landscapes
  • learn about making small levels
  • learn about making blueprints
  • choose a small and simple project: a complete goal with not many complicated things, but you can choose something that you can add features and make it more complete once you are confident with the previous results. Getting hands dirty earlier will help a lot crystallize the acquired knowledge.
  • try recreate simple game mechanics from games you have played (just simple mechanics, not the entire game)
  • from this point forward you can choose specializations: environment specialization, gameplay, special effects (VFX), character creation and animation, some of them you will need external tools like: Blender, Photoshop/Krita, Maya or 3DSMax, if you are student the paid tools usually offer a free student version, the free tools are harder to find good tutorials, but they exist.
  • start planing on participating on Game Jams alone or in a group.

The road is broad and there are many paths, some you can skip, but in the end you might need to travel them all.

Good luck on your endeavors!