Okay So I understand the basics that PlayerState and GameState are used for replication between client and server… but why?. From my understanding the PlayerController and the Pawn also replicate. I know the GameMode exists only on the server and the GameState replicates to the clients (I get that one). But if the PlayerController and Pawn both replicate why does one need a PlayerState?
My only guess is to cut down bandwith, only needing to replicate a relatively smaller object instead of the entire player controller or pawn. I would assume anything that is universal to the Pawn itself would be on the pawn (Attributes and Weapons, etc as they will be needed even for AI). Is there another reason for the player state there isn’t exactly much documentation on why and how you would use it.
Considering how important to the engine it is, the Replication Documentation seems severely lacking…
A PlayerController only exists on the owning client (the player that the PlayerController belongs to) and the server. So any replication inside the player controller won’t be noticed by other clients. So Player Controller -> Things that are only important for server and owner or maybe even things that shouldn’t reach other players. PlayerState -> Information about the player that is important for everyone.
One thing the PlayerController is often used for is handling input. There is no reason for other clients except for the owner to have access to this.
The Documentation for UDK has this image. It works like this, but the PlayerReplicationInfo is now PlayerState:
But I have to agree the current documentation for replication related topics and probably other parts of the engine is lacking, unless you have prior knowledge about Unreal Engine.
As for why not use the pawn to replicate: You don’t always have a pawn, or at least not the same one. For example, the name of your player or some clan tag can be put in PlayerState. When you get killed, your pawn dies and you get a new one, that information will still be there. It’s independant of the player’s pawn.
Okay so the PlayerController exists only on the server (except for the Players PlayerController on their own client) and basically PlayerState is sent from the player controller on the server to the Pawn or character on the client.
The pawn itself can die and be destroyed by the server and upon respawning the server player controller can spawn a new pawn that is then replicated to the client with the player controller’s player state information…
Is it possible NOT to destroy this pawn and bring it back to life?
(am I following this correctly?)
Following the idea that pawns are destroyed upon death, does that mean that if you have a Trait system that belongs to the player no matter what pawn they are playing then the PlayerState is where you would want to put that?
What if you have 5 pawns that a group of players can choose from and each can customize EACH of the different pawns differently. So Pawn A can use heavy guns and grenades but the player gets to customize them. Player A makes Pawn A Super good at Heavy Guns, but player B chooses to make Pawn A super good at grenades… I assume the PlayerState again would be where you would put that data, for each specialized pawn the player chooses?
Okay I realized my example may also be solved by having the trait system on the player controller on the server (and subsequently the respecting clients controllers) and upon respawning could configure the pawn with the desired stats and replicate them to the clients (so the client can render them to the screen). However lets say you don’t want the pawn to be “configured” that you want your data on a single object that exists on both the client and the server that the pawn checks against to calculate damage for shooting a heavy gun vs throwing grenades… but then RPC’s could be used to perform all that on the Server and replicate down to the clients…
Really Rendering HUD Systems seems to be the only reason I can think to use PlayerState…
Okay… As I contemplate the meaning of life (replication) I slowly seem to be wrapping my head around it… and am starting to develop strategies… Basically the server represents the entirety of the world (the universe), the true world with 100 percent data integrity (aka the authority). Each client only contains valid data of their own character (the mind) and a visual representation of objects in the world.
Objects in the world (which are relevant) are replicated down to the client for visual purposes. Creation of objects can be performed by the server and replicated down OR can be RPCed to create on both the server and the client (in the instance you are utilizing UObjects instead of AActors). It seems there are two possible strategies for handling data replication. Object serialization that then get’s sent down through the net to the server or action duplication where you ensure that if action A is triggered on the client it then then triggers on the server and vice versa. Other wise the mind gets out of sync with the universe and that’s how you have hallucinations @.@
The way I understand it is there are some additional properties besides what was mentioned, like score, etc…
PlayerController on the server will probably have the score in a match, but that info won’t ever travel to clients. So if clients want to look at the score board, they get the PlayerStates and can display the data that’s in the PlayerState for the score. This is also a good way to prevent ESP cheating (hacks where clients display hidden info about the gamestate, etc…) since you can avoid sending info unless the client needs to display it somehow. The server governs all the logic anyway so there’s no point in sending everything to the clients, only the things clients want to display.
You will still need to be careful with how much data that you send. Having every single Actor replicate from the server to the client can wind up using a lot of Actor channels. Thus, you have to be selective as to what you send. Even with that, you may not always want to send information due to cheating / hacking.
For example, in a FPS game a simple way to stop radars is to simply stop sending information about other player’s avatars when it is no longer relevant (they are hidden behind a wall for example).
There are a number of patterns that are commonly used when replicating things in games.
Everyone
I’d like to say thank you to everyone who responded to this thread it has helped me Immensely on replication.
iLLYay
Yes! That is the direction I was beginning to think toward. You read articles and watch the videos for hours but you don’t always get it until you are knee deep in replication design trying to figure it all out. I’m just glad I am doing this as a hobby right now and not under any real deadline! (Yet)
Solid Snake
I was somewhat aware of the actor relevancy idea but beyond that I have no idea about how it works, more precisely how to control it. My thoughts was that UE4 has a built in default relevancy algorithm. Network game play is 100% new to me and have only been working on it for the last week now.
So In Recap
The server has a representation of everything. Each client contains a subset of relevant data on surrounding actors. All PlayerControllers and Pawns exist on the Server but only the players own PlayerController exists on the clients. A PlayerState is sent to each relevant Pawn on the clients representing any game relevant data that needs to be displayed or represented to the client player about the state of the other clients (such as who is winning in a FPS match). Positional data should probably be maintained and replicated by the Pawn itself to reduce scanning as well as some other various bits of data to prevent cheating or hacking