0
\$\begingroup\$

I am working on an entity system for a game. I have read that cache is very important with the common operation of iterating over entities and their components.

Currently I have a class World that contains the list of entities, and a list of each component.

class World {
  vector<Entity> entities;
  vector<PositionComponent> position_components;
  vector<SpeedComponent> speed_components;
  ...
};

The idea of this, is to have entities and components contiguous in memory to be cache-friendly.

The problem is that you have to write specific code for each different component, as it is hardcoded in the source code. One solution could be to have a matrix of Component*, where the i-th row of the matrix are all PositionComponents, and so on. The problem with this, is that with the pointers you don't have the memory continuous and break with the cache-friendly.

What would the best way to write generic code and still have cache-friendly data?

\$\endgroup\$
3
  • \$\begingroup\$ Wanting same code for example for handling position component and graphics component? Why would you need an abstraction like this? \$\endgroup\$
    – wondra
    Commented Aug 22, 2015 at 22:42
  • \$\begingroup\$ The part with the same code, would be the functions with to add/get/remove components, that would have to look at some ID, and then, is an ifelse/switch to treat each ID differently. And this may happen in other parts as well. \$\endgroup\$
    – user3909742
    Commented Aug 22, 2015 at 22:52
  • \$\begingroup\$ You have to specify the type somehow. I can imagine something like template<typename... Args> T * Add(T*(*loader)(K, Args...), K arg, Args... args) as completely generic Add(), but you still need 1)pass type 2) pass logic the only difference is you write type in <> brackets and you dont call function directly, you just pass pointer. \$\endgroup\$
    – wondra
    Commented Aug 22, 2015 at 23:30

1 Answer 1

Reset to default
1
\$\begingroup\$

The main purpose of the ECS pattern is to be programmer friendly, not speed. So this is essentially an architecture problem, although I will also address your cache-friendliness concerns.

It seems like you're setting your components up like data records, whereas they should contain all the relevant behavior for their subject. Think

  • PhysicsComponent
  • SpriteComponent
  • SoundEmitterComponent

Rather than

  • SpeedComponent
  • PositionComponent
  • RotationComponent

Thus, your component container should be the abstract "Component" type. Behavior specific to each component should be contained entirely within the specific component class.

The more important thing to cache friendliness is combining components that need each other's data. Position and speed will usually be accessed very close to each other. Same with position and, say, rotation. So put them all that data in a physics component with the physics behavior. So rather than trying to optimize all the components in aggregate, focus on the actual function of each component. Basically, assume the cache will be wiped between each component update and structure your data accordingly.

\$\endgroup\$
3
  • \$\begingroup\$ The reason I am using the components as a mere data container is because I based the entity system on this: t-machine.org/index.php/2007/11/11/… \$\endgroup\$
    – user3909742
    Commented Aug 31, 2015 at 17:58
  • \$\begingroup\$ I think you've misunderstood it, though he doesn't do a very good job of identifying the architecture. Not sure if he understands the idea himself. Refer to the original article: cowboyprogramming.com/2007/01/05/evolve-your-heirachy \$\endgroup\$
    – jzx
    Commented Aug 31, 2015 at 20:06
  • 2
    \$\begingroup\$ @user3909742 Indeed, for convenience, separate the idea of an ECS from t-machine's article and concentrate on just using component-based design and how that affects your general design and architecture of game systems. The cache-friendliness of your components matters waaaay less than you think it does, even in the AAA space; your components probably aren't where your performance bottlenecks are going to be. \$\endgroup\$
    – Sean Middleditch
    Commented Oct 23, 2015 at 2:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .