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.

... 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 sure, all roads lead to Rome, and nothing exists that can be looked at as a standard component based entity system. However, for me it sounds that you stopped on half the way: Behavior is modeled by components, but data is still monolithic (IMHO, this is rather the strategy pattern than a CES). If I'm right, then what's the reasoning for this decision? The intention of composition is just to avoid "monolithicism" ...

If what you have is working for you, than I don't recommend making any huge changes unless you start running into problems. But for your next project, you might want to consider some of these other approaches.

It doesn't make much sense to me to have an entity with several fields that might or might not be used depending on whether it is renders le, collidable, etc. So my data is held by the components. Most components also hold a reference to a functor. Components such as position/orientation don't. My game is set up as several systems or modules: an entity system, a render system, a physics system, an audio system, an AI system, etc. The entity system maintains a list of entities for each of the other systems. So, in the game loop, for each system that needs processing, the game polls the entity system for a collection of entities to process. For example, you can ask for all entities with a renderable component. The entity system provides a first and last iterator that are then fed to the render system. The render system iterates through, calling each renderable component's functor. I use functors because 3D models, sprites, UI elements, etc. needs to be handled differently, so I have a different functor for each type of renderable processing needed, which allows me to avoid having to hardcode a lot of specific algorithms and routines into the various systems.

I haven't touched my code in a long while, but when I finally get back to it, I'd like to replace the components' functors with handles to lua scripts.

Thanks for the feedback everyone.

To those who are wondering my decision to have components but have a monolithic entity class, the answer is flexibility and ease of prototyping. Anytime during my design if I think "you know what, so-and-so Entity would be cool, I will need x new property, y new component, and I can reuse a,b,c component" all I have to do is create a new property in the giant Entity class, toss in some already made components, and create the new component that I need for this entity.

I alaso didn't mention that I use Lua scripting for entity initialization and behavior. the components essentially only fire "triggers" (and perform lower level tasks such as sprite batching) which call Lua scripts that are attached to entities on initialization. These scripts are what perform actual game logic.

Entities are ordered in the entity manager by ID, and components are ordered in the entity by a map of component type, to components. When an aspect of the game is updated, such as physics, the entity manager calls update on each entity with physics components.

I'm sure there's a more efficient, "sexier" way to handle this than having a bunch of different, unrelated data in one class. I'm pretty much a novice at this

Edit: yckx I like that approach, I might fork and experiment..