This is a list of planned features for v3
Less but more powerful API calls, following a more declarative design as described here: https://gist.github.com/SanderMertens/40bf6cd98dc658443651125e6dee5c28
A hybrid model that supports archetype and sparse set storages. Applications will be able to upfront specify which components are stored in a sparse set, and which components are stored in an archetype. The API will work transparently with either storage. Queries will transparently query across sparse sets & archetypes if needed.
Applications will be able to partition the archetype storage, so that components for an entity can be stored in more than one archetype. This will allow for less components per table (improved add/remove performance) and reduced fragmentation (less archetypes). Queries will be able to query across partitions.
There will be no more builtin roles (CHILDOF, INSTANCEOF, etc). It will be possible to define new roles on the fly, like is possible with traits in v2. There will be 31 bits available for roles, vs 24 bits for traits in v2.
The archetype storage will support combining multiple archetypes into a single one by merging a role column. For example, if there are a n archetypes with Childof | n columns, the storage will allow folding these into a single Childof | * archetype.
The fold operation will support a ranking mechanism, where a rank is defined by a function that takes as input the original entity type. Entities will be grouped by their rankes within the archetype. This provides an application with the ability to refragment entities using a custom dimension.
Queries will have the ability to organize matched archetypes into N groups which can be enabled/disabled dynamically. This will enable an application to quickly enable/disable entities that are associated with a game mode (play, edit, menu) or location in the game (room_1, room_2). Since systems are entities, the group mechanism can also be used to enable/disable groups of systems.
An application will have the ability to configure "component groups", which are sets of components that always exist together. Adding one component of such a group will automatically add the others as well. Component groups can be stored in both sparse or archetype storages.
Queries will support prolog-style predicates that are created from facts and rules. A fact can be either a simple "has(Component)" or "likes(PersonA, PersonB)" which uses traits ("likes" is the trait). A rule can be composed out of multiple facts and/or other rules. When a query is matched against tables, its predicates will be evaluated against the entity/table type.
Applications will be able to create processing graphs that can be composed out of reusable system nodes, similar to how a VPL works. Nodes will operate on component arrays, and it will be possible to route outputs of a node to inputs of another node. A graph is a collection of nodes, but can in itself also act as a node. Regular component arrays from existing tables can act as input for a graph.
Nodes will be either of a Map or Reduce kind. A map node transforms all inputs to an equal number of outputs. A reduce node transforms N inputs into a single output. When node outputs are routed to inputs, both the component type and cardinality must match.
The graph API will have a pluggable "runner", which allows it to be reused as front-end for other graph-based features, such as shader graphs. For a proof of concept of the API, see: https://gist.github.com/SanderMertens/1bb74395e9e8ae2c63001853582b45b5
A new job API will replace the current pipeline system where instead of running systems sequentially, the main loop will process jobs that can potentially be scheduled on multiple threads. Jobs will be exposed to the external API, so that an application can use process jobs on their own threads.
V3 will have the ability to selectively load & unload component data from a world.
- Change tracking for single entities/components