Ok here is just a super quick example of building a system like this with a single Parent BP class.
First, here is the folder structure I use for this test:
And these are the variables that are added to the “MasterInventoryClass” BP:
This is the only BP that is located in the root “Blueprints” folder:
Two Generic Enums that apply to most item types are in the root “Enums” directory:
ItemTypes:
MaterialTypes:
(in case you want to automatically determine item durability and lifespan etc)
Three Structs are in the “Structs” folder, one for each basic type I set up:
So now whenever I make a blueprint based off of “MasterInventoryClass” I get access to all those variables. Here is an example where I created a Helmet item. I placed this BP in the “Blueprints\Armor” folder.
Notice that the armor BP has all the variables for weapons and character modifiers as well, but you simply don’t need to define them for any items where those settings do not apply.
I also wanted to show how a system like this can be somewhat flexible. Notice that the armor struct has a variable called “Buffs”. That is an array of class variables to “MasterInventoryClass”, and it lets you create an item for a character modifier and also stack them as modifiers on top of any other items. So here as an example is a helmet that would be very strong but reduce player speed by 50%.
If we look at the “SlowBones” blueprint we can see its “Character Modifier Properties”:
Note that currently this will let you put any inventory item under buffs. You could easily restrict that by having another sub-parent class called “MasterBuffClass” and make the buff variable an array of “MasterBuffClass” rather than “MasterInventoryClass”… but it doesn’t really matter since you could either enforce it by hand or just check that the ‘buff’ item is actually a character modifier and not a weapon etc.
Obviously this is all super rough and lacking in implementation details. There are a bunch of ways you could organize it from here. I would probably have most of the basic scripting happen in the parent class with something like this:
You could then do further sub-switches based on the separate types of each item, and then once you get down to common types, its all the pure variables that define what happens. Ie, if you have armor, you need to figure out what type (is it a helmet or breastplate) and decide how to modulate the players incoming damage. You might opt to store a variable for how much each part of the body is procected and then you simply modify the corresponding variable any time the item armor is changed. And then the buffs need to get read but you pass that in as if another item was selected so it does not complicate the script. Then you can easily get all sorts of stacked effects going on.
Another image showing a hypothetical Weapon BP so you can see what type of weapon struct settings you might want to use.
Notice here again that there is an enum for Melee vs Projectiles. Then there are two more enums defining the types further below that. If you selected the Melee type for the broader category, then the “Weapon_Projectile_Type” will not matter since it wont be used (due to the way you set it up using switches on type). But since this is a melee weapon, it can further specify that it is of type “Knife”.
Of course whether or not there is a benefit to making “knife” a whole type or not depends on how many knives your game needs to have. I like to break things up in case of future expansion.
Anytime you need to access these vars elsewhere you simply have to Cast to “MasterInventoryClass”. And then you could have a switch on ItemType after that in order to filter the behavior elsewhere.