Hi all,

I recently decided to move my game from an inheritance based architecture to entity-component based one. I have the whole Component system set up, but I'm having problems figuring out how to store and pass them around. Below is a bad image of my architecture.

[attachment=26133:Game Architecture.png]

Right now the operations are as follow:

The Game class passes information and objects between classes as well as contains the mainloop

The LevelLoader class reads the tile info from a .tmx(TIled) file and generates the tile Entities, storing them in one of three vectors based on type: foreground, background and collision box. I separated them to make rendering and collision simpler. After loading is complete ALL the Entities are transferred to the GameObjectManager class.

Every frame after this is processed as follows, the GameObjectManager updates all its entities, which update their components, then Game extracts the entities vector from GameObjectManager and hands either the vector or elements of the vector individually to the different systems.

The Systems handle their operations and this cycle repeats.

This is where I feel like I'm making a mistake. I have the entities and I have the component, I just don't know how to give the different systems (Physics,Renderer Input etc.) access to them. Currently I just get the std::vector<Entity> container from the GameObjectManager class and pass it into each system, but it just doesn't feel right. Objects that have no physics component have to be iterated over in the Physics system and ones that are just empty collision boxes get passed to the Renderer.

One idea that came to mind was having a vector of pointers for each type of component and passing the corresponding vector to the corresponding system. This would certainly help the game run smoother, but I think adding new component types would become more difficult.

Another is to sift through the vector of entities in the Game class and just pass the entities components to the right system:

for (int i = 0; i < entity.size(); ++i)
{
	if (entity[i].hasComponent("phsyics"))
	{
		physicsSystem.Update(entity.getPhysicsComponent());
	}
	if (entity[i].hasComponent("render"))
	{
		renderSystem.Update(entity.getRenderComponent());
	}
....

}

With all this said, my question is, what is the most efficient way of handling entity/component storage and accessing. Should I throw them all in a single container and just pass it around and let the systems sift through? Or should I manually sort the components beforehand and pass the systems only what they need? Is there a better/smarter way of handling this?

As you may be aware, there are a large number of different implementations of component based systems.

Especially in languages such as C++, the benefits of ECS designs can be the ability to employ contiguous memory. If you have each system allocate a pool of components, then you can reduce the frequency of cache misses, and hence improve performance of system updates.

Hence, when you register a component with an entity, it makes sense to request it from a system, which will maintain an internal pool (and therefore update internally) of components.

IComponent* physics_component = physics_system->create_component();
entity->components.push_back(physics_component);

// Some time later
double delta_time = 1.0/60;
physics_system->update(delta_time);

This has its difficulties when you have systems which share components with other systems. Generally speaking, avoiding this dependency helps a great deal.

[...]The LevelLoader class reads the tile info from a .tmx(TIled) file and generates the tile Entities, storing them in one of three vectors based on type: foreground, background and collision box.[...]

Thing to remember is that ECS is for game objects. I'm not sure whether you consider here to wrap everything into an entity. That is not necessarily a god idea.

Another is to sift through the vector of entities in the Game class and just pass the entities components to the right system:
Code here

That approach is definitely not what you want, because that code snippet processes each entity individually from input down to rendering in one go. That is almost ever wrong. Instead you want to want let all interested entities be input processed, then let all interested entities ..., then let all interested entities be rendered. (In the meanwhile Krohm has posted an image that shows what I mean ;))

As you may be aware, there are a large number of different implementations of component based systems.

Especially in languages such as C++, the benefits of ECS designs can be the ability to employ contiguous memory. If you have each system allocate a pool of components, then you can reduce the frequency of cache misses, and hence improve performance of system updates.

Hence, when you register a component with an entity, it makes sense to request it from a system, which will maintain an internal pool (and therefore update internally) of components.

IComponent* physics_component = physics_system->create_component();
entity->components.push_back(physics_component);

// Some time later
double delta_time = 1.0/60;
physics_system->update(delta_time);

This has its difficulties when you have systems which share components with other systems. Generally speaking, avoiding this dependency helps a great deal.

This makes all of the sense. Thank you. I had been following the "Game Coding Complete 4" book, but I couldn't find where the actual components are created, so I thought "just toss em on the heap".

I would separate low-level systems and high-level systems:

My current issue was(is) with passing the information within the components. I'm not sure how this separation of systems would help.

I'm currently trying out Krohm's/Angus's solution. Its not as clean as having everything come out of a factory, but I can see how it would be better of the performance side.

It was just a general system I added for the sake of explaining my situation, but will do.