Good Coding Practice for Character Inventory

Development Programming & Scripting Blueprint
1

Hello.

I am working on a project that is an old school doom/quake style FPS and I was wondering what was the best way to go about managing character inventory for available weapons. I have been modifying an existing FPS tutorial where you hide unequipped weapons while keeping them attached to the player and then hiding and unhiding them as you switch them around. The inventory of these weapons are managed in the BP_FirstPersonCharacter blueprint and controlled by gameplay tags that keep said weapons locked and unlocked as needed.

My question was if this was the best way to go about it or is it better to manage character inventory through a separate class that controls both weapons and ammo and then managing interactions between BP_Inventory and BP_FirstPersonCharacter via interfaces?

Any help would be appreciated. Thanks!

2

for a simple game like that just use an actor component, you wont even need an interface since you can GetComponentByClass

3

Is generally considered best to make an actor component to handle it, and add that to your character (and enemies, containers, etc.. that can have items). To start, create a new blueprint class with ActorComponent as the parent class, and add the component to player char the same way you would add a mesh or whatever to an actor class. Since it would be a component of char, you don’t really need an interface for character to use it, as you can call component functions from the owner without needing a cast. Though you may want an interface later for other actors to give you items (like a shop or something) or so weapon actors attached to player can communicate with inventory (like to ask for ammo in a reload function)

4

I store and manage inventory in the Player State via actor component. Communication via interface. Zero class specific references. Simple Actor, Pawn, AC etc.

My project is multiplayer, so I have to consider connection disconnects and rejoins preserving the players inventory and stats. The GM auto copies and stores PS for default 300s on discos and handles rejoins.

Working with inventory on the PS is a bit more complex, but worth the gains.

5

Can you explain why you use an interface? I am assuming your inventory component is only one class type, no?

6

I’m not casting or storing class specific references.

E.g. MyCharacter, MyContoller, MyPlayerState

Character would be base Actor or Pawn Obj ref.
Controller: base PlayerController obj
PS: base PlayerState obj ref

The base ref points to the vanilla empty parent class. No added pointer, memory weight. The interface is the communication bridge.

Pawn class: Input (fire weapon) → get controller(get player state(interface:: GetActiveWeapon(return obj ref)) is valid → fire.

7

That’s my point though… if your inventory component is only one class can you not replace this step with:

Get Player State → Get Component By Class (InventoryComp)&(if valid)-> Get Active Weapon

Then you wouldn’t need to manage an interface.

8

The weapon actor has its own ACs. Dynamic data driven. I don’t have to get components by class.

Inventory stores an actor obj reference of the weapon and just calls an action event on the class. The class handles it’s components

9

This is how you are confusing me, I asked if there were multiple component class types. For purely the inventory system, do you have multiple classes? If no, why use an interface for something that is a singular class?

Say I have a player and a chest. Both of them have Inventory Comp. I do not need an interface to “Get Inventory Comp”, because I can just do Get Component By Class (Inventory Comp).

In both ways of doing that I have the starting reference I would call an interface on vs just getting the component directly. If you have multiple types of inventory classes I could see why you’d use an interface.