Design paradigm: Composition vs Inheritance vs Interface(?) in Unreal with example. Need help

[anonymous_user_cae9bcfa]

@TheJamsh;736801

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.

I’m trying to build an “Escape from Tarkov” style inventory to really investigate what I can do with a heavy component centered design while learning UMG system. An inventory like this works in this way I imagine:

(for a backpack)
-Character has an InventoryComponent where the EquipSlots reside. Items are not directly stored here.
-ItemActor has a PickupComponent which is a child of an InteractComponent. This allows you to look for an InteractComponent to determine if something can be Interacted with…ie DoorActor/ItemActor/PlayerActor/ContainerActor all child of AActor…
* PickupComponent wll allow this item to go into an Inventory. Holds all properties related to Inventory; item size, weight, if it’s stackable, etc.*
-ItemActor has an EquipComponent which will show “Equip” action through context menus in the UI and tell InventoryComponent where it should be equipped.
-ItemActor has an ItemStorageComponent which will hold “contents” or references to the ItemActors in inventory.

ItemActor in this case is a very bland class housing only a Name property. You can make many different types of Items by combining different custom UActorComponents.

What I do not like in game systems design, is things like Epic’s implementation of ACharacter and UCharacterMovementComponent. The Character and CharacterMovementComponent are completely coupled and dependent on each other. You cannot use CharacterMovementComponent on anything other than derived classes of ACharacter. Character even has basic “DoCrouch” style logic while the Component itself has the actual Crouch implementation. In my dream world, the MovementComonent would move or crouch the Object without caring what it is. The Object shouldn’t even need to know about the Component. Maybe even receive player input events instead of Input being performed on the Character itself cutting out the need to call events ON CharacterMovement from Character…

An example of this would be “WeaponHandler” component attached to your Character which holds input event for “Reload”. Essentially, a character without a WeaponHandler does not know how to Reload or Shoot a gun.