0ef13eb1cc
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: * |
||
|---|---|---|
| .. | ||
| src | ||
| build.zig | ||
| README.md | ||
mach/ecs, an Entity Component System for Zig 
mach/ecs is an Entity Component System for Zig built from first-principles.
Design principles:
- Clean-room implementation (author has not read any other ECS implementation code.)
- Solve the problems ECS solves, in a way that is natural to Zig and leverages Zig comptime.
- Avoid patent infringement upon Unity ECS patent claims.
- Fast. Optimal for CPU caches, multi-threaded, leverage comptime as much as is reasonable.
- Simple. Small API footprint, should be natural and fun - not like you're writing boilerplate.
- Enable other libraries to provide tracing, editors, visualizers, profilers, etc.
⚠️ in-development ⚠️
Under heavy development, not ready for use!
As development continues, we're publishing a blog series "Let's build an Entity Component System from scatch".
Join us in developing it, give us advice, etc. on Matrix chat or follow updates on Twitter.
Known issues
There are plenty of known issues, and things that just aren't implemented yet. And certainly many unknown issues, too.
- Missing multi-threading!
- Currently only handles entity management, no world management or scheduling. No global data, etc.
- Lack of API documentation (see "example" test)
- Missing hooks that would enable visualizing memory usage, # of entities, components, etc. and otherwise enable integration of editors/visualizers/profilers/etc.
- We have dense and sparse data, but no shared data yet.
- If many entities are deleted, iteration becomes slower due to needing to skip over entities in the free_slots set, we should add a .compact() method that allows for remediating this.
- If tons of entities are deleted, even with .compact(), memory would not be free'd / returned to the OS by the underlying components arrays. We could add a .compactAndFree() method to correct this.
- It would be nicer if there were configuration options for performing .compactAndFree() automatically, e.g. if the number of free entity slots is particularly high or something.
- Currently we do not expose an API for pre-allocating entities (i.e. allocating capacity up front) but that's very important for perf and memory usage in the real world.
- When entity is deleted, maybe via systems / an event/callback, need a way to be notified of destruction. Same with updated maybe.
See also the numerous TODOs in main.zig.
Copyright & patent mitigation
The initial implementation was a clean-room implementation by Stephen Gutekanst without having read other ECS implementations' code, but with speaking to people familiar with other ECS implementations. Contributions past the initial implementation may be made by individuals in non-clean-room settings (familiar with open source implementations only.)
Critically, this entity component system stores components for a classified archetype using independent arrays allocated per component as well as hashmaps for sparse component data as an optimization. This is a novel and fundamentally different process than what is described in Unity Software Inc's patent US 10,599,560. This is not legal advice.