Are references between entities in Entitiy Component System allowed?

Question

I've got a player entiy in my game that can pick up weapons when colliding with item entities. The player can hold and use the weapon in their hand (the weapon sprite is rendered relative to the carrier).

I'm wondering how to design weapons and items in an ECS approach. Should the weapon be an entity the whole time so that the player entity has a weapon-component which holds a reference to the weapon-entity?

Answer 1

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.