2

Say I have three classes: EntityManager, Entity, and Component.

Entity has an array of components (pointers), and each of these components have a field that is a pointer to the encapsulating Entity.

EntityManager has an array of entities, and each entity has a pointer to its encapsulating EntityManager.

The reason for this design is data reliance. Components need access to the encapsulating entity's fields and some components depend on other entity's fields (pointer to entity manager).

Is this "cyclical" design a bad practice? Should I rethink my design?

tshepang
  • 12,111
  • 21
  • 91
  • 136
user2687268
  • 113
  • 1
  • 5
  • 4
    It's not necessarily 'bad practice' or 'bad design'. The point is to get the pointer ownerships/references right. – πάντα ῥεῖ Aug 28 '13 at 07:39
  • 2
    I don't see a problem with this. I would suggest you put the logic that add/remove reference at the same place. You don't want to end up with an entity that was a manager but the manager not having the entity. – the_lotus Aug 28 '13 at 17:49

1 Answers1

1

Anything cyclical is only bad in regards to resource shared/locking resources, particular in regards to multithreading.

Besides, it doesn't even look like this is cyclical. It's more of a side by side design, that is of course that to get EntityManager fields, a Component has to go through the Entity. Or, to get a Component, an EntityManager has to go through an Entity.

In terms of design I would worry about what happens if you need to change the fields of an EntityManager that an Entity or Component are dependent on?

JoeManiaci
  • 435
  • 3
  • 15