Thanks, also sorry to bother you for one final question, but let’s say I’m using the EOS for its account systems, then linking the Account ID with the database to retrieve the player data for that respective account ID.
Regarding everything you’ve told me, how would the logic work (Do I need RPC or anything like that), where should the logic be located (In an ActorComponent, GameMode, GameInstance, etc), do I need to worry about being logged in requiring to be persistent between levels?
When adding EOS, the only thing that needs to be changed is to add the player ID when sending an RPC to the server when taking an item or when taking it out of inventory.
All other logic remains the same as I described earlier.
The logic for interacting with the inventory will be located in the corresponding Actor Component.
When you log in, you create a Pawn and load the Inventory Actor Component with information from the database.
your instinct is right, server owns everything that matters. game instance is fine as a temp cache across travel but it never replicates, and game mode only exists on the server, so neither can push to clients.
the shape that scales is per player data on a replicated home like player state with a small inventory component. client sends a server rpc to request a change, server validates against the database then updates the replicated vars, and clients react in RepNotify to refresh the hero select and inventory widgets. late joiners just get current values, no missed multicast. keep widget code thin and put the equip logic in the component so dont duplicate it per screen.
you can also try Blueprint Object Replication, an inventory data plugin for Unreal Engine that replicates each owned hero and item as its own object with repnotify vars instead of packing everything into the player state: https://www.fab.com/listings/e26dcf07-7c78-4e67-8e56-272cf6df8021