3
\$\begingroup\$

Now, I'm implementing a component based game engine and I came to a thought: Which way should I access my components?

  • Have a list of Entities, which have a list of Components, and access them by going trough each entity, and updating/drawing/whatever on each component.

or

  • Have separate systems for each component type and acces them by going trough that systems components.

Or does it really matter? I think that the second way would seem faster...

\$\endgroup\$
4
\$\begingroup\$

I would recommend having both.

Entity/Component Graph

This defines which entities are attached to which components. In my engine, there is no such thing as an "entity", but any component can have child components. This graph is not used to draw or update components, but is only used for logical queries and events that are supposed to effect component sub-trees in the graph. The graph is just made of weak references to components (in C++, pointers. In other languages, unique identifiers), and doesn't contain the components itself.

For example, I have an "onDeath" event that uses the component graph to tell which components need to be destroyed when a parent component has died.

Component Lists and Systems

Parallel to the component graph is a set of component lists. For instance, there is a list of all the Physics components in the game, a list of all the Sprite components, and so on. These lists are aggregated into a big map of component type to component list called the ComponentManager.

ComponentManager is responsible for updating and drawing all components, one component type at a time. This is far faster than iterating through the component graph, because it has much better cache performance, and allows you to batch state of components before drawing/updating them.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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