(Inventory) Store instance data in array of USTRUCTs or as an array of instances?

So I’m working on my inventory system. My game has a small crafting metagame with upgradeable/degradable weapons and items so each of instance will be unique. I’m uncertain about the most efficient/performance-friendly method for storing items. I currently have an item class with a USTRUCT that hold default information (type, icon, base stats) while the class holds instance specific data like modified stats or name. This setup also makes sense with subclasses. Weapons derive from the base class and have weapon specific data in the class while the variables in the USTRUCT are unchanged. If I continue using this format, the inventory would be an array storing pointers to the class instances like so:


TArray<class AItemBase*> Inventory;

. This approach makes the most sense to me, but I’m a bit worried that it could be unstable in the future. I’m also not 100% sure how to implement this for weapon equipping and stuff like that.

The alternative would be to put all of the variables in the USTRUCT as well as an ENUM that specifies what type of item it is (weapon, consumable, etc.) and then when the instance is needed, spawn the correct type of class with the stored USTRUCT, essentially destroying and recreating it every time with the data saved. I don’t really like this method though, because then all the items would be holding onto empty variables that might not be relevant to them.

The main dilemma is in the destroying and recreating vs. just keeping instances alive.

I could also meet somewhere in the middle and have an inventory that stores instances and a separate inventory array that stores the USTRUCT data for non-unique objects that won’t be affected by not storing instance data.

Please let me know what method is better or if there is another method I’ve overlooked. Thanks!

Your approach might work but I personally don’t see any reason to split impementation to sructs which will hold info about items and objects. First of all structs can’t be really instanced in blueprint, they are treated as simple data structs.
IMO best approach, is to crate simple struct describing slot (index in array, reference to item object).
Then create simple uobject, which will implement virtual functions for getting images, descriptions and what not.

Inventory in form of linked list is good for games which doesn’t complex inventories like shooters, or platformers. Anything where you need more complex mangment or complex items it will fall short, mainly because of increased complexity of main class.

I wouldn’t worry about performance, unless you do something realllly bad, you won’t have any issues and reliability is much more important in this case. Imagine players loosing items or duping them - game broken beyond recovery.

If you want sample implementation check out links in my signature for ActiomRPGGame, GameInventorySystem module. It have almost feature complete implementation.

I can write more when I will be back at home, posting from tablet is not that good for long posts (;