Entity component system: efficient component retrieval?

Started by
13 comments, last by RobM 10 years, 3 months ago

There is an example of an ECS implementation, which is very efficient. I think it is based on a similar idea as noizex #2, but without a hard 64-bit limitation?

Look at the tutorial on the front page, it is quite easy to follow. It takes away most of the implementation details from the user.

[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/
Advertisement

Check out the articles in my signature for how I do my components. They're basically just arrays of components (one per type) and another array of component masks. An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on). It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


I'm not sure I agree that components must be data-only and you also specified that systems operate only on groups of components when they all exist. Not sure what you meant by that but doesn't that negate the plug-and-play nature of ECS?

The 'component mask' is sometimes also called a 'key':

http://gamedev.stackexchange.com/questions/31473/role-of-systems-in-entity-systems-architecture/31491#31491

http://gamedev.stackexchange.com/questions/4898/are-there-existing-foss-component-based-frameworks/4966#4966

Check out the articles in my signature for how I do my components. They're basically just arrays of components (one per type) and another array of component masks. An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on). It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


I'm not sure I agree that components must be data-only and you also specified that systems operate only on groups of components when they all exist. Not sure what you meant by that but doesn't that negate the plug-and-play nature of ECS?

Nope, my system is perfectly plug-and-play. The systems read the component mask to determine if they should act upon the component data for that entity. If you're "adding" or "removing" a component, you're just modifying the component mask to change the visibility of the component to the systems.

"So there you have it, ladies and gentlemen: the only API I’ve ever used that requires both elevated privileges and a dedicated user thread just to copy a block of structures from the kernel to the user." - Casey Muratori

boreal.aggydaggy.com

Check out the articles in my signature for how I do my components. They're basically just arrays of components (one per type) and another array of component masks. An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on). It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


I'm not sure I agree that components must be data-only and you also specified that systems operate only on groups of components when they all exist. Not sure what you meant by that but doesn't that negate the plug-and-play nature of ECS?

Nope, my system is perfectly plug-and-play. The systems read the component mask to determine if they should act upon the component data for that entity. If you're "adding" or "removing" a component, you're just modifying the component mask to change the visibility of the component to the systems.
I see that makes sense now

This topic is closed to new replies.

Advertisement