ecs: add very early-stages entity component system #156
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the very, _very_, early stages of an entity component system for Mach. It's not ready for any real use, but rather is a starting point for further development. This spawned after [this research issue](#127) in which I got tons of great information, tips, etc. and much more research that I did after the discussion in that issue. The idea is to start with this, and continue moulding it into what we want. As development continues.. * I've created [a room in the Matrix server for anyone who wants to chat](https://matrix.to/#/#ecs:matrix.org) * I'll be maintaining a blog detailing eerything I've learned and how I'm approaching development of this (as I plan to do for all key parts of Mach.) The first article in the series: [Let's build an Entity Component System from scatch (part 1)](https://devlog.hexops.com/2022/lets-build-ecs-part-1) Signed-off-by: Stephen Gutekanst <[email protected]>
Closed
emidoots
pushed a commit
that referenced
this pull request
Mar 19, 2022
In the past: * #156 was the initial ECS implementation detailed in https://devlog.hexops.com/2022/lets-build-ecs-part-1 * #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](#157 (comment)). 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 * 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 <[email protected]>
1 task
emidoots
pushed a commit
that referenced
this pull request
Mar 19, 2022
In the past: * #156 was the initial ECS implementation detailed in https://devlog.hexops.com/2022/lets-build-ecs-part-1 * #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](#157 (comment)). 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 * 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 <[email protected]>
emidoots
pushed a commit
to hexops-graveyard/mach-ecs
that referenced
this pull request
Apr 5, 2023
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](hexops/mach#157 (comment)). 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 * 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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the very, very, early stages of an entity component system for Mach. It's not ready for any real use, but rather is a starting point for further development.
This spawned after this research issue in which I got tons of great information, tips, etc. and after much more research after that discussion this is what I've landed on initially. I'm positive this will change dramatically in the coming weeks/months, the idea is to use this just as a starting point and continue molding it into what we want.
As development continues..
The first article in the series: Let's build an Entity Component System from scatch (part 1)
Signed-off-by: Stephen Gutekanst [email protected]