ecs: third major redesign/rethink of implementation #185

Merged

emidoots merged 1 commit from sg/ecs-r3 into main

2022-03-19 17:59:26 +00:00

emidoots commented

2022-03-19 17:38:04 +00:00

(Migrated from github.com)

In the past:

hexops/mach#156 was the initial ECS implementation detailed in https://devlog.hexops.com/2022/lets-build-ecs-part-1
hexops/mach#157 was the second major redesign in which we:
- Eliminated major limitations (e.g. inability to add/remove components at runtime)
- Investigated sparse sets
- Began thinking in terms of databases
- Enabled runtime introspection

Our second revision of the ECS, however, still had archetypes exposed as a public-facing user concern. When a new component was added to an entity, say a weapon, the table storing entities of that archetype changed to effectively have a new column ?Weapon with a null value for all existing entities of that archetype. We can say that our ECS had archetypes as a user-facing concern AND this made performance worse: when iterating all entities with a weapon, we needed to check if the component value was null or not because every column was ?Weapon instead of a guaranteed non-null value like Weapon. This was a key learning that I got from discussing ECS tradeoffs with the Bevy team.

This third revision of our ECS has some big benefits:

Entities are now just IDs proper, you can add/remove arbitrary components at runtime.
- You don't have an "entity which always belongs to one archetype table which changes"
- Rather, you have an "entity of one archetype" and adding a component means that entity moves from one archetype table to another.
- Archetypes are now an implementation detail, not something you worry about as a consumer of the API.
Performance
- We benefit from the fact that we no longer need check if a component on an entity is null or not.
Introspection
- Previously iterating the component names/values an entity had was not possible, now it is.
Querying & multi-threading
- Very very early stages into this, but we now have a general plan for how querying will work and multi-threading.
- Effectively, it will look much like interfacing with a database: you have a connection (we call it an adapter) and you can ask for information through that. More work to be done here.
Systems, we now have a (very) basic starting point for how systems will work.

Some examples of how the API looks today:

github.com/hexops/mach@979240135b/ecs/src/main.zig (L49-L87)

github.com/hexops/mach@979240135b/ecs/src/entities.zig (L625-L656)

Much more work to do, I will do a blog post detailing this step-by-step first though.

Signed-off-by: Stephen Gutekanst stephen@hexops.com

By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

In the past: * hexops/mach#156 was the initial ECS implementation detailed in https://devlog.hexops.com/2022/lets-build-ecs-part-1 * hexops/mach#157 was the second major redesign in which we: * Eliminated major limitations (e.g. inability to add/remove components at runtime) * Investigated sparse sets * Began thinking in terms of databases * Enabled runtime introspection Our second revision of the ECS, however, still had _archetypes_ exposed as a public-facing user concern. When a new component was added to an entity, say a weapon, the table storing entities of that archetype changed to effectively have a new column `?Weapon` with a null value for _all existing entities of that archetype_. We can say that our ECS had archetypes as a user-facing concern AND this made performance worse: when iterating all entities with a weapon, we needed to check if the component value was `null` or not because every column was `?Weapon` instead of a guaranteed non-null value like `Weapon`. This was a key learning that I got from [discussing ECS tradeoffs with the Bevy team](https://github.com/hexops/mach/pull/157#issuecomment-1022916117). This third revision of our ECS has some big benefits: * Entities are now just IDs proper, you can add/remove arbitrary components at runtime. * You don't have an "entity which always belongs to one archetype table which changes" * Rather, you have an "entity of one archetype" and adding a component means that entity _moves_ from one archetype table to another. * Archetypes are now an implementation detail, not something you worry about as a consumer of the API. * Performance * We benefit from the fact that we no longer need check if a component on an entity is `null` or not. * Introspection * Previously iterating the component names/values an entity had was not possible, now it is. * Querying & multi-threading * Very very early stages into this, but we now have a general plan for how querying will work and multi-threading. * Effectively, it will look much like interfacing with a database: you have a connection (we call it an adapter) and you can ask for information through that. More work to be done here. * Systems, we now have a (very) basic starting point for how systems will work. Some examples of how the API looks today: https://github.com/hexops/mach/blob/979240135bbe12d32760eed9f29f9795ead3c340/ecs/src/main.zig#L49-L87 https://github.com/hexops/mach/blob/979240135bbe12d32760eed9f29f9795ead3c340/ecs/src/entities.zig#L625-L656 Much more work to do, I will do a blog post detailing this step-by-step first though. Signed-off-by: Stephen Gutekanst <stephen@hexops.com> - [x] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.