In the game I’m making there wouldn’t necessarily be a “pawn” or “character” object associated with the player in a particular game mode. I’m too new to Unreal Engine, but from what I’ve read, it sounds like I would put the game logic and state inside a class which inherits from GameStateBase. Actually controlling the game now is the challenge. Because I’ve seen the GameMode and GameState classes I’ve also spotted the PlayerController.h header seemingly associated with the GameMode I select. What this is for I’m not clear on, if this would be how to go about this I would like know.
Pretty common to make the pawn an empty character just with a camera and maybe a small collision sphere if needed.
You’ll want it so your player controller can Possess() it to get a specific camera view. To switch around to different views would be possessing different characters.
We make all our controllable and stationary cameras inherit from our custom base character.
It felt like from what I’ve read there’s only ever one “pawn” being possessed. Which then makes me think ok, the mapping abstracts from the controller input, and the actions the logic, the system doesn’t necessarily have to do with a particular “pawn”. As is, it’s convenient for how the engine seems to be structured, but it seems as though there’s probably a “good” way around both possessing pawns and not.
EG: In terms of what I’ve read, it sounds like there could be a “default” input action context that applies globally when no “pawn” is possessed.
My mind might not be in it’s clearest state right now, but I feel like we should clear some stuff up.
@UnknownGeek, would it be possible to make this paragraph a little more legible?
To be more specific, why is the word pawn in quotes? The first sentence is correct but maybe you mean more.
Next, what does “The system doesn’t necessarily have to do with a particular pawn.” mean?
And finally, in the last sentence, did you mean “What would be a good practice to control multiple pawns?” ?
Like I said, I may be a little confused at the moment, but doesn’t that mean we’re still possessing a pawn or a character? Maybe you understood OP correctly and your explanation is the way to go in their case though. I was stuck on that “there wouldn’t necessarily be a pawn or character object associated with the player” part. Regardless, I think OP should try to implement your explanations. Because even without the context, I believe what OP has in mind as the end result is just a spectator mode.
I put the pawn in quotes because I’m new to unreal and it’s a bit strange to hear a chess term in my head. It makes sense for what it is, but it’s a tad confusing. An actor is essentially anything loaded into the game, might be renderable, has nothing to do with something being moved around. Then there’s a pawn which you can control, and then a character which is a pawn that has some preset movement controls.
As for the input system confusing me, I don’t see why the default needs to be related to a pawn. The way it’s built, given it’s directing and processing controls to deal with ONE pawn, realistically there’s no reason why inputs couldn’t be processed w/o one.
I also read further in the documentation, it sounds like for dealing with inputs interacting with things that aren’t a pawn class there is a separate thing. I’d really like to have seen a tutorial on both usages.
A Pawn is simply an object that is controlled by the player. This is why you’re able to get the player controller. A Character extends the Pawn class to give extra capabilities focused on bipedal player characters. A tank, airplane, ball, block, etc… type of objects could all be Pawn objects without the need for being a Character object while giving you the ability to access the player controller.
An Actor for example isn’t player controllable, so there’s no need for a player controller.
The Pawn isn’t a chess piece, it’s basically a non-specific player controlled object. Even in Chess, the pawn is “player playable”. Maybe that helps? The chess board would be like an actor, it exists in the game world, but you don’t play or control it.
AFAIK the player controller has no location or camera. If you want a specific camera view you’d have to Possess() something. Its always some type of pawn/character, even it is simply a collision sphere with a camera.
But you are correct, inputs can and should be processed through the player controller - it represents “the player’s will”.
Pretty common to have something like “MoveLeft()” in your PlayerController, then have Pawns/Characters all with a MoveLeft() function.Your player controller simply passes the command to whatever it is currently controlling. If you are controlling a tank, character, or spectator cam, they all get the same move commands but can handle them differently.
You can also set up inputs on individual paws/characters if you wish.
Yes, you could, but in reality, a pawn doesn’t have to be an object controlled by the player. For example, in a card game where you have several heroes, it would be a hub for hero data, and in a soccer game, it could contain the logic for managing players without having to posses the characters on the field. Whatever your game, there’s sure to be some logic that makes sense to have separate in the pawn.
Also, now with the enchanced input system even more, the goal is practically to put inputs in the pawn and be able to have different gameplays changing te pawn while keeping the same player controller.
U