current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 0 down vote favorite

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?

share|improve this question
    
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 –  Grimshaw 15 hours ago
1  
"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? –  Byte56♦ 15 hours ago
    
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. –  twilightends.com 14 hours ago
    
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. –  twilightends.com 14 hours ago

1 Answer 1

up vote 0 down vote

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. :).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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