Pawn vs Character, what’s the difference, when use what.
PlayerController, I get that it’s for handling input/data, and somehow passes that to the character. Is this necessary? What advantage does this have over just handling input in the character blueprint.
Player Start. Is there anything I should know about this?
GameMode, what? Why do I need to make a “MyGameMode” then set that as the default gamemode so I tell it what character and controller to use. Am I doing that right.
How do I make my character a ball controlled by physics? I tried using the Add Force node but a target of self doesn’t work, I have to pick a component, and the only option is the mesh, which doesn’t work. Why isn’t self an option? What component do I have to move to move my character? Is this where the PlayerController comes in?
Pawn: A Pawn is an Actor that can be an “agent” within the world. Pawns can be possessed by a Controller, they are set up to easily accept input, and they can do various and sundry other player-like things. Note that a Pawn is not assumed to be humanoid.
Character: A Character is a humanoid-style Pawn. It comes with a CapsuleComponent for collision and a CharacterMovementComponent by default. It can do basic human-like movement, it can replicate movement smoothly across the network, it has some animation-related functionality.
Controller: A Controller is an Actor that is responsible for directing a Pawn. They typically come in 2 flavors, AIController and PlayerController. A controller can “possess” a Pawn to take control of it.
PlayerController: A PlayerController is the interface between the Pawn and the human player controlling it. The PlayerController essentially represents the human player’s will.
PlayerStart: PlayerStart is just a placeable actor that defines the position of the player when the game starts. The arrow represents the rotation of where the player will be facing when the game begins. Without it you wont be able to start the game because the Engine will have no idea where to put the player.
GameMode: The concept of a “game” is split into 2 classes. The GameMode is the definition of the game, including things like the game rules and win conditions. It only exists on the server. It typically shouldn’t have much data that changes during play, and it definitely shouldn’t have transient data that clients need to know about.
Its because “self” is an actor and Add Force is expecting a component. If the “self” actor has a mesh component in its Root then you can drag a wire from the “self” and search for Root Component. You can then plug this to Add Force.
One note, if you embed input functionality in the Pawn rather than in the Controller, blocking it will not work on the Pawn. You’d have to fiddle with possess/unposses.
I see [ROOT] CapsuleComponent in the components tab. but in the blueprint tab, root anything is not an option.
Also what is the SpringArm1, why is the in-game camera farther away than where I put it, is that because it’s nested in the SpringArm and that’s doing something weird?
And what is the CharacterMovement component.
SpringArm: tries to maintain its children at a fixed distance from the parent, but will retract the children if there is a collision, and spring back when there is no collision. CharacterMovement is used by walking/running/flying avatars not using rigid body physics.
I’ll state the follow is purely base on my understanding so far, so please correct me if I’m wrong.
To simplify, Chararacter is a specialized Pawn, where the movement is replaced by CharacterMovement and in your case from 3rd person template it also has a springArm that behaves as parent of player’s camera.
The reason for separating Pawn and Controller is that by doing this, you allow the same base class(either any Pawn you created or derived from template examples) to be controlled by one of the following:
you locally, or another player locally
AI controlled NPC or co-op AI that allows drop-in/out coop.
remote player that connect to your game or a dedicate server.
As for difference between GameMode and level blueprint, my understanding is that GameMode should be responsible for any game status change, like keeping score board in a deathmatch, respawn dead player or trigger next wave of zombies.
While level blueprint should handle house keeping, like where are my triggers to open doors, to stream in/unload part of levels, where are the possible points for player to spawn.
And with above explained, imaging a multiplayer session flow, when you connect to a server.
You connect to a server, and load a level.
base on server GameMode, you could be assigned a DefaultController and hook to a spectatorPawn(so you can clip through walls and handling a free flying camera).
When this is done, you will be shown to say, press B to join Blue Team, or start match, or anything else from summon a HUD menu that decide your actual role in the game.
Once you selected, your will be assigned to(possess) a CharacterController(that lets you jump, aim-down-sight, etc) and spawn a Character depending on your choice, where GameMode choose from level saved spawn point(or dynamic ones)
you play, die, GameMode do the accounting(update scoreboard), put you back to defaultController and spectatorPawn, until your spawn timer is out, then do 4 again.
Once server setting of GameMode achieved ending condition(ie Blue Team reach 10 captures), everyone gets detach from their pawn and shown scoreboard HUD, and a next match/level button.
either level or GameMode(on the server) calls a function to decide whether to load next level, or restart a match using the same level. then it’s 1 again.
Note: that it could also be possible that you only get to assigned to a Controller per GameMode where the controller switch it’s operating mode based on your status(spectate or playing).
But this would be a special case where no current blueprint basetemplates demonstrate how this actually works.
farzher - Character comes with certain ‘preset’ components (a root CapsuleComponent for collision, a SkeletalMeshComponent for visuals/animation, a CharacterMovementComponent for walking logic and an ArrowComponent to show which way is forwards!). If you are not making a walking player, make a Pawn instead which doesn’t have anything! To make a rolling ball, add a StaticMeshComponent as your Root component, enable physics simulation, and add forces to that. In 4.1 we have a template that does just this!
**PenguinTD **- your description is pretty much right! The only thing I would point out is that your PlayerController class will probably not change when you go from spectating to playing to dead. That is one of the other reasons to split Pawn and Controller - it means you can separate the code that persists across these events (e.g. player name, voice chat, menu) and the code related to the actual avatar being controlled (e.g. animation, input, health).
