There is no Council of Entity System Design that is going to fine you if have references between your entities. If that's how you want to build the system so it works for you, go for it. There isn't a single "correct" way to create an entity system.
For your specific situation, I'd probably expect to see something where you have an entity for the player, and that entity has an "inventory" component. You also have entities for the weapons that are placed around the world, and they have an item component that indicates what they are.
However, the item component and the inventory component both refer to a third structure, called ItemDefinition
or whatever. That third structure contains data for items or weapons, describing their non-instanced properties (name, what model they use, bullet type, damage, weight, et cetera). However this ItemDefinition
is not a component.
There's no need to make everything a component when you are building a component-based entity system, and it can get confusing and create a complex hierarchy of sloppy organization.
In summary:
- Give the player entity an
InventoryComponent
, which has a list of ItemDefinition
references (and possibly additional information like how much of each definition is carried, which "slot" in the inventory they take up, and so on).
- Give the items on the ground a
PickupComponent
, which has an ItemDefinition
reference indicating which item will get picked up. When entities with inventories interact with an entity with a pickup, add the referenced item to the inventory.
- Store the actual data for the items outside the component system, because there really isn't a reason to entangle them and if you do you potentially start getting into silly situations involving deep hierarchical attachments of components.