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.

I have an Entity class and a Component class. The Entity class has a list of attached components, and each component also has a member variable that is a reference to the entity that it is attached to (cyclical design).

Then, there is the EntityManager class, which has a list of (you guessed it!) entities, and each entity also has a reference to its encapsulating entity manager.

The reason for this cyclical design is due to data reliance. To explain further, my Entity class is essentially just a giant bucket of data: any data any type of entity needs already exists on this class when it is instantiated. However, in order to make use of this data, the Entity needs the relevant components attached. For example, my Rendering component takes the Entity's spriteData member and draws it to the backbuffer. Without a rendering component, spriteData is not utilized. Since my components need to access the Entity's member variables, each component needs a reference to the Entity it is attached to.

For an example of why my entity needs a reference to the entity manager, it is because some components (such as collision) need to access other entities' data buckets in order to function (for collision, this would be checking nearby entities' position vector and comparing it to the component's referenced entity).

There is more to it than this, but I just wanted to highlight the central idea of what I was doing, and wanted opinions on whether a cyclical approach like this (with little data encapsulation as well..) is a good idea or not. Maybe I'm just overthinking it /shrug. Opinions on how to steer the design would be hugely appreciated, as well.

share|improve this question

closed as primarily opinion-based by Sean Middleditch, Nathan Reed, Patrick Hughes, bummzack, Byte56 Aug 26 '13 at 14:42

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Welcome to GDSE. Unfortunately this is not an opinion or discussion site. If you have concrete questions which can have a specific "correct" answer, this is your place. Otherwise try something like gamedev.net. –  Sean Middleditch Aug 24 '13 at 6:23
    
I apologize, won't happen again. I took your advice and posted it on gamedev.net instead :) –  user2687268 Aug 24 '13 at 19:46

1 Answer 1

up vote 1 down vote accepted

Entity systems do exist since years, your design decision is not new. For example take a look at the Artemis framework, or my own implementation.

To provide some feedback on your system, I wrap it the other way around. Your current approach is to have an entity class and attach properties to it.

class Property
{

};

class Entity
{
    std::vector<Property*> properties;
};

std::vector<Entity*> entities;

Instead, you could drop the entity base class, represent entities by integer ids, and group the properties of the same type together in maps.

std::unordered_map<int, SpriteProperty> sprites;
std::unordered_map<int, PositionProperty> positions;

Which sprite corresponds to which position is given by the id thus the integer key. The advantage of this design is that it leads to more data oriented code. It is much faster, to loop over all PositionProperties and update them (which could even be done in parallel), than to loop over all entities and each update all their different properties.

Using ids to represent entities also has the advantage that you could easily store them to disk and load them back into the system without loosing their identity.

share|improve this answer
    
You should refrain from posting "answers" for discussion "questions" that don't belong on the site. :) –  Sean Middleditch Aug 24 '13 at 18:29
    
@SeanMiddleditch Okay I understand that. By the way, are those question going to be deleted or just closed? I think many question could be formulated in a more objective way. –  danijar Aug 24 '13 at 18:47
    
I really appreciate this (insightful) feedback, and I like this approach way more than what I am currently doing. Will take a shot at something similar. thank you. –  user2687268 Aug 24 '13 at 19:49
    
@danijar: generally closed, though maybe not if rephrased first, or it can be reopened if edited. I agree that they can be objective, but anything asking for feedback is pretty much right out. I personally feel any architecture question not asking for a solution to a particular concrete problem is in the "opinion" category since there are about as many generally viable architectural designs as there are game programmers, but note I'm not the authority on GDSE topicality. :) –  Sean Middleditch Aug 24 '13 at 21:17
1  
@SeanMiddleditch I encountered that many questions about architecture get closed, too. But since architecture is a very important part of a game or game engine, it definitely should part of this site. Maybe we could add some advice, about how to ask those questions in a way producing objective answers, to the FAQ. –  danijar Aug 24 '13 at 21:33

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