This is my preferred approach when coming to extending game objects.
Actor Child-Classes
Used for discrete types of objects. For example, ‘Powerup’, ‘Pawn’, ‘Vehicle’, ‘Character’. Stores common behaviour for that types and child types. Exposes a lot of blueprint default properties for customizing appearance and basic properties.
Components
Used for appending properties, variables or identical behaviour to actors of varying types. Examples:
A ‘Health’ variable that is modified by the owning actor. ‘Health’ is a universal variable and could be shared across multiple actors.
Storing an array of ‘Inventory’ such as weapons or ‘abilities’, and providing functionality to start and stop using them. Both Characters and Vehicles might want to carry weapons!
Interfaces
Used for when actors of different types need to perform some given behaviour, but that behaviour can be customized per-object that uses the interface. For example:
*A ‘Killable object’ interface, which provides the following functions:
- HasBeenKilled()
- Kill()
Actors and Components of different types may want to be ‘killed’. Each object can decide whether it has been killed with different parameters, and can be killed in different ways. (E.g, character might ragdoll, vehicle might explode).*
Personally, for ‘Useable’ items I like interfaces. Why? Because each actor can define what ‘Using’ it really means.
Is it a pickup? Add it to inventory.
Is it an inventory item? Use the item.
Is it a weapon? Fire the weapon.
Is it a door? Open the Door.
Does the ‘usable’ items need to have an interface for the player? Create a UUseableUI component that allows you to change the UI Icon, UI Text etc.
You can also create whatever callbacks functions you need, and force objects using those interfaces to implement that behaviour.