Item Definition Patterns
Last updated
Last updated
When it comes to defining items, there are a few ways you can go about doing this. VaultLogic is intended to be very open ended on this approach, making Items be represented by objects as opposed to structs opens the door for some cool design patterns you might want to take advantage of. However, the way you define your item classes will boil down to what works best for you, your project and your team. Here are some example patterns I found useful when using VaultLogic myself.
Nowadays inheritance gets a bad rep, particularly in games system design, as it is deemed to rigid and rarely justified. However truth is Inheritance is a tool in a developers toolbox just like any other, it must be used for the right job for it to be effective. One of the reasons inheritance often gets misused is because it's one of the first tools a developer will come across when starting out so, when you only have a hammer everything looks like a nail, thus a lot of the most cursed code you'll come across (and you'll probably write some yourself) when starting out will be the result of misused inheritance. Sorry I'm rambling.
The point is that inheritance is a perfectly valid tool. For the particular use case of defining inventory items in a system such as VaultLogic within a game that doesn't need complex crazy items, inheritance will get you there 99.9% of the time.
An option that is also available to you are interfaces, this can be made as granular or as large as you want and they will let you define your items in a more "compositional approach" as unreal engine doesn't limit the amount of interfaces you can implement (where as, in blueprints, it doesn't support multiple inheritance).
VaultLogic already implements this approach for stackable items, it provides an interface called StackableItemInterface defining all the behavior that is expected of a stackable item. Using this approach also has the huge advantage of not needing to use casting within systems that reference this inventory items. Casting is commonly frowned upon (though, like inheritance, it's just a tool...) because, when not done properly, it can lead to some cursed dependency chains that can bloat your memory usage, with a lot of unused assets and blueprints. On the other hand, interfaces (c++ or blueprints) are incredibly lightweight as they provide nothing more than a bunch of function signatures and maybe one or two default implementations, eliminating the risk of dependency chains.
Vault Items are instanced by default. Instanced objects are a very powerful unreal engine feature that lets you to instantiate an item in editor time allowing for any values within that instance to be set right there in the editor. This means if the only thing that would change between 2 would-be sub-classes of the same item is the value of some properties, it might make more sense to just keep the one parent class and change the values in the instances if need be.
The disadvantage of this approach is that it gets harder to track how many different "would-be sub-classes" the "parent" item has, also to use the item again elsewhere would involve copy-pasting which is error prone and slow.
In the above example you can see an instance of the document item, it displays some properties defined in the class. The instance holds values for this property that are unique to it. This works great in this case, since making new data only blueprint sub-classes of Document would become cumbersome for designers.
