How to best deal with modular architecture and rigid entity descriptors?

[tobiasaxenbeck]

We are planning for an extensible architecture where it should be possible to add features quite dynamically and we are struggling with the concept that the shape of an entity has to be known upfront.
As an example let's assume we have army unit entities with a set of components shared by all kinds of units. Then there are multiple modules that might be enabled or not during runtime that add features (along with data components) to theses army units. Some of these features could be shared e.g. ranged attack or stealth and some are quite specific e.g. airplanes or naval units. Since all possible features are known at compile time we could create a descriptor from all army related components. This seems a bit cumbersome, but it is certainly doable - so ok. So all unit entities will have the same kind of components, even though not all of them are logically required. Since queries work on components something like - give me all flying stealth units - will still yield all armies and therefore does not give us what we want. As we understand it, the way to make this work is by using groups. So using this example we would declare a composite group like FlyingStealthUnits and either query from that group or do a belongs-to-group check while iterating the query result. This means for every feature we would create a group and would need composite groups for all permutations that have to be processed individually.
Our challenge is that we receive data for army units that can be of any type without knowing the specific type upfront. So it would be convenient to construct the type step by step on the fly, but the only way to go about it would be to parse the data to figure out the specific type, then create the entity from the appropriate descriptor and then initialise the components in a second pass. Is there a better way to go about this problem without resorting to ExtendibleEntityDescriptor and deal with its implications?

[Grigler]

Using ExtendibleEntityDescriptor is likely the best way to handle this rather than having all components on all entities, as it allows you to group common sets of components easily. Though I would still separate unique descriptors into separate groups (so their components align), your engines would be able to still operate on common sets of components by using the following syntax which would allow you to keep common behaviour generic and avoid the composite group permutations you decribed.

var groups = entitiesDB.FindGroups<SomeComponent>();
foreach(var ((componentsNB, count), group) in entitiesDB.QueryEntities<SomeComponent>(groups))
{
  // your logic
}

It's also worth noting that entity operations are able to be enqueued using the base descriptor, as the framework will find the actual set of components used by the entity you enqueue.

While it may not be advisable, there is also the DynamicEntityDescriptor but the misaligned components in the group would likely cause more problems than it solves.

[sebas77]

Be sure you check the articles https://www.sebaslab.com/whats-new-in-svelto-ecs-3-0/ and https://www.sebaslab.com/svelto-ecs-3-3-and-the-new-filters-api/

The DynamicDescriptors (that allows to add components at run time) and the ExtendibleDescriptors are great to add components until the entity is built. However remember that after that components are immutable. In order to change the behaviour of an entity (and therefore move the entity to different subsets for different engines) you need either to change group (using a group compound, which is better than exclusive groups) or use filters.

Both group compounds and filters are used differently according the level of abstraction of the engine:

very abstracted engines use FindGroups
semi-abstracted engines use the group compound tags or filters depending what you choose