Multiplayer Inventory System based on Objects, Structs or ... ??

Development Programming & Scripting Blueprint
1

hey!
I’m working on an inventory system, and cant figure out how to do it with multiplayer support. (and I already read like every thread on the “inventory” topic i could find from 2014-2017…^^)
The system itself should contain(at least) the 3 basic parts: “the inventory”, actionbar and equiped items (like weapons etc).
Most threads seem to suggest you should store the inventory data in (arrays of) structs, which contain only ItemID/name, and amount etc (and the actuall item data istored in a data table), but i think this method kind of awkward - i will give examples after explaining my own implementation.

So is based everything on an “Object” class, which contains a reference to the inventory component (on the character that has this item), the iteminfo (name, description, icon etc) and data like amount/durability etc. So 1 Item is basicly 1 Object in the game, which has a lot of good properties, for example the item can only be in one inventory at the same time (because of the reference), or i can implement custom functionality when i want to use an item, so that food triggers a different reaction than a piece of wood, or when i want to move the item from 1 inventory to the other i just have to remove the reference from the old inventory and add it into the new one.
This system works really well in singleplayer, and i already solved 99% of the edge case which could break the system, but the problem is: objects dont get replicated in multiplayer (as far as i know). I also noticed this when i started to do test with multiple clients.

so what now? try to make the object class replicated (i’m using blueprints only, but i think you can do that with a c++ project -> to much data for replication when playing with a lot of players?), or base it off of actors instead of objects -> easy replication; or do i change the system to structs?

i tried changing it to structs, but the more i changed, the more i noticed i would miss a lot of good features of the object approach, for example when i drag an item onto my actionbar i only have to swap the item(object)references and things like icon/tooltip get updated really easy with umg-widget bindings; or when i want to take the item on say the first slot of the actionbar and reduce its durability by 1 i only have to get the object reference from the first actionbar slot and change its values directliy with 1 node set durablity = xxxx

i dont want to spend a lot of time with implementing more content into my game when the system everything else is based on isnt working in multiplayer

so what would be the best option for me? the game is designed for like 1-5players in coop, but with an big open world it could also be cool with public servers with 20+ players, and then the performance hits from bad implementation would be massive

2

I use actors, and works well. There’s a downside though, you’d need to replicate items that are not essential, e.g if you go near a chest, whether you can open it or not you will still have to replicate the actors (Unless there’s a way to replicate actors to selected players only, but I don’t know such a method in blueprints at least). This way I also create child actors for different type of items, e.g Food, tools, weapons etc.

3

Usually you’re combining the two systems:

Idle Items (in inventory) are contained in a structure (replicated in one way or another).
Equiped Items are contained in a structure + are displayed ingame by a replicated actor.

I don’t see a big performance hit being an issue here as long as you don’t spam the network with informations all the time.

Regarding the UMG binding, if you extract your datas from an object you can do the same with a structure.

You could also keep the object structure and just sync the moment you update object datas on remote machines but I feel like it needs more implementation / tuning to work fine (just because you rely so much on not making mistake when updating / browsing / manipulating datas).