I’ve been studying the API and tutorials, including Tom’s survival multiplayer series on the wiki. There’s a few parts in the networking process that confuse me:
I don’t know the significance of APlayerState if ACharacter or what not can also hold variables like health/ammo/etc and replicate them to other participants
As far as *_Implementation and *_Validate code goes, I’ve only seen “return true;” in the *_Validate body of example code. Is there an example of what else I can do? I’d guess there could be authority validation code here?
PlayerState is one of the structures that is persistent across maps, so if you want to carry across the players health and ammo to the next map/level, you put it in PlayerState. If you leave it in ACharacter it will be recreated fresh every time you travel.
Regarding Validation - I believe it’s purpose is to allow you to make sure that the players aren’t cheating - ie, if you try and add 1000 health but your max health is only 100 then there’s something funny going on. Having said that, my personal view is that 95% of the games that make it to a release state (and 99.9% of those started) are just going to replace it with a stub returning true, so all it is really achieving is code bloat.
You don’t need to use Validation if you don’t a logic for it. This is the point where you can filter out cheaters and directly kick them or something like that.
I, for now, have them all at return true, but i plan to pack some logic in them later. If you don’t want to validate the call, then you can just do it without validation.
The PlayerState is more than a Character. It is used to store data about the actual State of the Player. The GameState for example has an Array of PlayerStates which you could use to display
a scoreboard or something like that. You can also get the ping or the Network Playername from it. The Character shouldn’t be used for variables like this!
I use PlayerState to hold (public) data not bound to the lifetime of the character. For example, if somebody’s character dies, you might not want them to respawn with 0 score again so you store the score in PlayerState.