"I think you may be getting confused by the name ‘PlayerController’, sorry about that! This is not where the movement logic lives. A ‘controller’ represents a ‘will’ in the game that can ‘possess’ a pawn to control it. A controller could be an AI or a real player, hence the terms AIController and PlayerController. This doc gives an overview of our architecture: https://docs.unrealengine.com/latest...ork/index.html
To get a basic game up and running, you only really need the Pawn class. It’s the Pawn class that handles the input and moves itself around. Character is a special type of Pawn which includes ‘walking’ movement logic, and is used as the basis for templates like the side-scroller. You only really need to create your own PlayerController to handle logic outside of the Pawn, things like bringing up a mid-game menu for example. Our Character class is quite flexible, there are some great tutorials and example out there of extending it to add dodge, climbing etc. In 4.2 we made it even easier to do things like double jump, and we’ll be releasing a video tutorial to cover that."
This logic has always eluded me, specially on multiplayer games.
If i set the movement logic with the inputs right there on the pawn, wouldn’t that give me problems on a multiplayer setup? or the only input that this pawn would get is the one from the possesor player controller?
Also checking the base player controller and the base character from the examples, the player controller handles the logic to jump, move, etc and gives it to the character (via a method call) which is the most logical answer to me.
Why is this discrepancy between the post and the examples?
Input is routed through the player controller then the pawn that it controls. There’s no problem in multiplayer because even though the pawn class might have a Spacebar Key event, only the pawn controlled by the local players controller will receive that input event, other pawns don’t have the input routed to them. In a game you might have a bunch of different types of player pawn, e.g maybe they can choose to be a standard foot soldier, and someone else chooses to control a flying drone. You would put input functionality like ‘bring up pause menu’ or ‘start a chat message’ in the player controller because it’s common to all types of pawn. You would put movement and shooting stuff in the pawn, because each type of pawn they can control needs different controls. Putting input in the controller or pawn is more of an organizational choice that depends on your game. If you’re only ever going to have one type of pawn then it’s just easier to put it in the pawn, rather than having to manipulate the pawn from the player controller.
What about the examples on C++? they capture the input on the controller (jump, movement) and give it to the pawn. I always thought that could give us problem with pawns that are too different (like a spectator pawn).
Now that you say this, it does have logic, but i’m confused about those examples though
Another thing, how would one program an enemy that can be possessed by either the AI or the player?
in that case how would the AI interact with the character if the character has input events?
I don’t know what examples you’re talking about, even the C++ template projects that come with the engine put jump and movement in the pawn, the only thing they use the player controller for is mouse look rotation because it comes with a nice system for that by default. To make an AI control a pawn instead of the player, you can make the pawn AI controlled and it will use an AAIController instead of a APlayerController, which you can subclass to add your own functions if you want.
Typically the AI controller doesn’t do much itself, but instead runs a Behavior Tree asset to determine what it should do. If a pawn is controlled by an AI controller, its input events never get bound and input isn’t routed to the AI controller anyway, instead the AI controller or its behavior tree call the functions directly. This means that your input functions can be either on the pawn or the AI controller depending on preference, they should be UFUNCTION(BlueprintCallable) and your behaviour tree should call them inside a custom Behavior Tree Task node. Pathfinding and movement for ACharacter derived classes already has a nice built in system that uses the MoveTo task in the behavior tree, but you would need to add your own tasks for things like making them jump over an obstacle or shoot a few bullets.