What to put in actor component vs Owner Actor

Hi,
So I’m trying to make an inventory system using data tables and actor components. I think I have the inventory part working when it comes to storing stuff correctly, but I’m not sure what data I should store or functions I should create in the inventory actor component. I am also making a loot actor component which will hold the data of the loot the player is picking up and to be added to the inventory. But for example, I have most of the initializing functions and interaction code in the loot component and I’m not sure if that’s where I should store it because grabbing or retrieving certain information isn’t as fluid as I would think the system should be. I’m wondering if there are any good practices to better organize where and how I should store the information about the inventory or the loot. Whether it should be in the actor component or the owner actor itself. Any ideas or suggestions would be greatly appreciated!

Anything static that does not change at runtime is probably best kept in a datatable. This is the fastest way to access large quantities of information relating to a key value (row name). You could also look into using ‘Get Class Defaults’ on a master class and any variables marked as instance editable will be able to be changed in children defaults. I’d still suggest using a datatable, though.

Are you making a loot component because the loot is not immediately given to the inventory? What is the reason for separation? Could you not just add something to the inventory as soon as you pick it up?

For reference in a normal inventory you should only need to pass around a row name and quantity of that item. If the item needs real time data its probably better to have an actor actually control its functionality. The example I could give is a gun that has a certain amount of rounds loaded in it like Resident Evil 4 inventory. You do not need to pass around all the static information of that weapon but trying to keep track of the loaded rounds would require work. My best solution to this is having an actor that keeps track of relevant information the UI can grab through an interface or something of the sort. An inventory system is largely trivial and specific to your project’s use cases.

Hey @tyconner !
Thanks for the response! So I do have data tables for possible pickup items and stuff like that which holds all of the information. From tutorials I’ve found online, I’ve seen them use inventory actor components for things like the player, npcs/enemies, and chests. And loot components for items that would be laying on the ground. Maybe like coins or materials or just things that can be picked up and added to the player’s inventory. An example with the loot is if I’d want to randomize the quantity that the loot has when the player picks it up, I’d have an initialize function in the component and other behaviors like that. I guess maybe I’m confused on when I would want to put a variable inside of the component vs inside of the owner like the player or npc or chest actor which will own or contain the component.

Actor components are nice because they can seamlessly be added to anything that is of class type ‘Actor’. Technically speaking anything that can go into an actor can go into an actor component minus visual components and additional components. I would say that anything that the component requires to function independently should be contained within itself. This way you could drag and drop inventory functionality into any actor just by adding the component. But your implementation is your own and that’s the beauty of making games!