If i have a bunch of data that varies from character to character (Health, mana, energy, levels, etc). Would it make sense to put all this in Player State or Player Character?
PlayerState is extension of PlayerController, main diffrence is that PlayerState is replicated, PlayerController is not. PlayerController is not replicated for security reasons, if PlayerControllers information would be contained in client memory there risk it could be manipulated, it a open window for cheat software, best example is GTA:SA multiplayer mod which fully synchronizes clients without any safety measures (since GTA:SA is not really made for multiplayer), typical single player hacks are normally replicated to other clients there. Thats why PlayerControllers are only on server side and they control pawns on server which later are replicated to clients. PlayerState is where you place information from PlayerController that you want to be replicated to all clients, but server should not relay on that information, so you just copy information that clients need to know.
Same thing with GameMode and GameState
PlayerState is used to replace PlayerController in network replication for all clients so it is exist through out the level with PlayerController and it use use to store the variable that matter even if your character is not there or dying like score, level, kills, deaths, character type/class,âŚ
Anything that define of your character you can put in like health, mana, energyâŚ
For example in MOBA game, your should put level in Playerstate, coz when your character die, all the stat in character will be reset, so you still can grab the level from Playerstate and re-init your character base on level, same go with items, weapons. In case of disconnected and reconnected, PlayerState will be saved, and your can get back all of that when player reconnect to server.
1 Like
Part of this is blatantly wrong. âPlayerControllers are only on server sideâ is incorrect. Granted I do not know how this played off in May 2015, but the PlayerController is replicated ONLY for the player that owns it. Meaning the client has only a single PlayerController instance on their machine - namely their own controller - while the server replicates the various controllers to the respective clients. This is extremely important for client-server communication as it allows processing of input through RPC events easily without even having to worry who the events are replicated to.
âPlayerState is extension of PlayerControllerâ is also wrong. PlayerState is its own class hierarchy and the first parent class the two share is AActor. PlayerState is, as Duncan Dam pointed out, designed to store data across sessions. It is a form of container, not a form of controller.
When it comes to security, the server should always sanitize player input. In your MOBA example, the server simply shouldnât accept the request to trigger a spell twice within 0.5 seconds when the cooldown is supposed to be 3 seconds. Of course the fact PlayerControllers arenât replicated across all clients helps greatly and might be one reason for this implementation. But it certainly is not enough to protect your game.
Why use Playerstate instead of Game Instance though? Say you are loading character costume on event begin play of character from the costume being stored on Game Instance. As far as I can tell all clients can see the costume loaded correctly so would you still need the Playerstate acting as a bridge between Game Instance and Player Character in this situation or is it redundant?
Thanks
Hi, this explaination is for Multiplayer Game where you need PlayerState to handle player data between server and all client. Game Instance is unique for each server and client, and itâs not replicated so if you doing Singleplayer game you donât even need PlayerState.
Hi Duncan.
Do you mean, I can store last player stats (like âgun-ammo, exp, inventory etc.â) in serverâs local save folder automaticly -via blueprints, without c++? And if player rejoins after 1 week, will player init with last stats?