1
\$\begingroup\$

I was wondering if it is a bad idea to store a pointer in every Component to the Entity which owns the Component.

E.g. I have a Component "NPC". Each entity which owns this Component also must have a Position and Sprite Component. Sometimes i get a list of NPC Components from one of my Systems, but I also need the coresponding Position and Sprite Components. I can retrieve the entity, but it's quite some code I have to type and it is more expensive than just following the pointer.

So would it be a bad idea to store a pointer to the Entity in a Component?

\$\endgroup\$
  • \$\begingroup\$ Why don't you store it alongside the component instead where its stored? Would probably be cleaner and allow more elegant code, if the components don't have to know anything else than their own data \$\endgroup\$ – Grimshaw Sep 26 '14 at 17:38
  • 1
    \$\begingroup\$ "Bad idea" is subjective. What problem are you trying to solve? Are you worried this will take up too much RAM? Are you worried about the time it'll take to implement? \$\endgroup\$ – MichaelHouse Sep 26 '14 at 17:40
  • \$\begingroup\$ The problem i want to solve is that if a Systems returns a list of a specific Type of Components (e.g. Sprite Component) I need alot of code to get the other Components belonging to the Entity. \$\endgroup\$ – twilightends.com Sep 26 '14 at 18:35
  • \$\begingroup\$ In the ECS code samples I read I never saw it. So I thought maybe it's a bad idea, because for me and the Framework I'm using (Artemis) it seems pretty convenient. \$\endgroup\$ – twilightends.com Sep 26 '14 at 18:37
  • \$\begingroup\$ There is no standard ECS implementation. In my opinion components should be entity-agnostic and unaware of each other's existence. Entity just groups components logically. Otherwise it might be a slippery slope that will result in a bad coupled design similar to Unity3d: t-machine.org/index.php/2013/12/27/… \$\endgroup\$ – Den Sep 27 '14 at 12:03
1
\$\begingroup\$

One obvious solution is to store the entityId inside each component structure or class. This way when you need to obtain components or do some entity-specific logic, you already have an easy way to obtain the entityId based on a given component.

Another solution that may be a tad more complex but has some useful side affects is to assign each component a unique id that using bit-wise arithmetic you could obtain the entityId, the component type or some dense array index, and a unique version number for the component's id. This is often hinted at in situations where component pools are managed using a single sparse array based on entityId and an internal dense array that keeps components in cache friendly uniform blocks of contiguous memory.

There is nothing bad with associating an entityId with a component because how else would you plan to implement component-to-component or system-to-system communication that involves one behavior to influence another for a specific entity. :).

\$\endgroup\$
0
\$\begingroup\$

it will be better if your systems will return a list of entities that contain a certain component other than a list of the components themselves.

also frameworks like Ashley has a 'Family' class which is used to get all entities with a set of components.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.