For your multiplayer game, when you have an actor in game vs an inventory item, do you just use the same actor class for the inventory item, turning off the collision, visibility, etc? Or do you use a separate item (a struct possibly) for the inventory item that represents the actor?
Three approaches I can think of are:
Use the “pure” actor approach, and turn off certain features.
Use a dedicated object for just the inventory data
Use both. Use an actor that holds the “data” stuff for the item, but if you want it to be present in the world just attach a child actor with all of the graphical items and functionality.
Still looking for others thoughts on this, but I’m currently going with the approach of having an actor with the data. If I need the graphical parts, I attach them via child actor.
Hello…
Since i made several inventory systems and worked on wow emulators too…
i think there is no good answer…
Inventory and data design really depends on usage, how much and what items you will have…
For example:
do you need store unique data in your items?
I mean like lets imagine weapons… if weapon need store ammo and or magazine, clip id… definitly best if you use some data class (like uobject)
But if your game need only constant datas, like ItemID, Quantity etc. etc.
Thats can be stored in STRUCT and struct work well with networking…
Using actors for inventory items is totally not the best solution. Actors have 3d transforms, they exist in the world… using lot more memory and bandwith…
Dont use them…
Of course if you drop out item from inventory to world, you need spawn a pickupable actor i guess… but if you pickup and you need store in inventory i think much better if you convert all data to some lightweight struct…
Thanks, good info. For now, I’ve decided to go with:
All items in game are represented by a UObject.
The UObject contains a struct for the item’s “personalized” data, such as its health, name, durability…basically, anything about the item that can change. When the game saves, this is the data for the item that gets written to a save file.
It also contains another struct, for item “Type” data that doesn’t change. What type of item it is, the actor class that represents the item visually, etc. Quick lookup data for game logic.
One downside to this is, the personalized and type data are now stored in the struct, which means you can’t easily see the information when debugging. I added a function library I call “debugging” with functions to print the data out. But, it would be much easier if unreal had an easier way to see variable info when debugging, like the locals window in visual studio.
Yeah definitly seems legit…
I made an inventory system which actually works similar mostly…
The difference in my system im using inheritance…
I have base UItemObjectClass
for weapons i have UWeaponItemObjectClass
for mags i have UMagItemObjectClass
Etc…
those classes can store their personalized data and i store all inventor yitem as uitemobjectclass (since it is the parent for all) and through interfaces i can get any value based on one enum which is a Type actually
for me its much cleaner as a struct… personalized datas can be debugged easily and type is just 1 byte…
One important consideration of using a UObject as a “container” for structs is, the inspector and visibility.
Let’s say you just want to drag an item out into your level, and set its stats manually. Can’t, because the uobject isn’t initialized, and as far as I can see there is no way to.
Which isn’t horrible, I guess, but you would have to create a table of items you want to place in game, and then you would read from the table at level start and create those items. It’s just a bit more of a pain than placing the items.
