So from what I’ve experimented with, it seems the player state is required to store unique info about each player - but is it required for everything like the health of the pawn, the health of other pawns, inventory of the possessed pawn, etc?
I’d like to store all of that info on the pawn itself, but from my experiments, I’ve always had better (as in, working at all) results over multiplayer by using the player state and running on the server.
While this works handily, there’s the matter of lag. My inventory was registering changes after a noticeable delay, which allowed me to duplicate items by quickly “removing” them or “stowing” them again quickly.
I tried disabling the buttons for a second or two, to compensate for lag, but that’s a double-edged sword because you can’t compensate for all lag, and you don’t want to disable the buttons for too long.
To remedy this, I put the inventory on the character/pawn (third person blueprint from the content example) and then save the inventory to the player state and save game separately so that the user interface runs on the client’s side, but then I ran into problems with setting skeletal meshes from the player state… eventually, I decided that my menu system was clunky and confusing and I was better off just asking on here for some advice on how to effectively counter the lag when dealing with moving replicated variables around on a user interface, say with drag & drop or context (right click) menus in mind?
And how necessary is the player state for storing variables in a multiplayer game? I feel like I’m using it wrong because I want the player to be able to switch player possession to other pawns.
This entirely depends on your game: I assume that each pawn has its own health, that should be stored inside the pawn itself. If the inventory is also unique, the same applies here, if it’s shared then storing it in the player state makes sense. Unless used otherwise, health of other pawns should be handled through UMG or in the damage code of your weapon (assuming you have a widget that shows other peoples health and you can damage them).
Of course, it is easier if everything you need is stored in a single replicated blueprint, but that’s not proper object oriented programming and will make this single blueprint huge and hard to modify in my experience. Running everything important to gameplay on the server is a given in multiplayer to prevent cheating or exploiting like the example you wrote, but it doesnt have to happen in only one blueprint.
I havent really dealth with lag in detail, but are you testing with simulated lag or is that complicated code just taking its time to execute? Disabling buttons is not an option, as youve said, instead you should send every action to the server, which in turn changes your UI. If you can remove and stow them again quickly, that means youre manipulating the UI without confirmation from the server, which should be handled instead like i just wrote.
The user interface (HUD and widgets) are always created client side and should send RPCs to the server to change anything important. What does a skeletal mesh do in your player state?
The player state should hold all information that the player has throughout a session, taking a shooter for example his score, KDA, rewards, etc. Everything unique to controlled pawns, such as stats (health, stamina), accessories (weapons, tools) and pawn specific UI should all be stored in that pawn.
