Allow entities to store multiple components with the same type

[alice-i-cecile]

This tracking issue comes out of #1525. This feature is still very much up for debate, and this initial post paraphrases the initial definition by @cart from that PR .

Definition

Tags are archetype-specific by-value data that affects archetype identity

Usage

ArchetypeA could have [A, B, C] table components and [D(1)] "tag" component. ArchetypeB could have [A, B, C] table components and a [D(2)] tag component. The archetypes are different, despite both having D tags because the value inside D is different.

Implementation

Tags could potentially build on top of the archetype.unique_components added in #1525 for Resource storage.

[alice-i-cecile]

Relationship to Indexes

@alice-i-cecile:

These sound a lot like minimal versions of indexes (#1205), but run into the issues discussed by Sander with the "pluggable storage model" approach: namely, you're blending concerns and that you often want to be able to index the same component in more than one way. I don't think this is a great approach to a very real issue.

@cart:

I don't think its a "pluggable storage" (as described in the discord discussion) and it doesn't suffer from the "multiple indices" problem. You can have (and query for) any number of tags. Its just a different form of archetype identity other than "has(component)". I view it more as a more limited form of Sander's relationship stuff (which are also typed values that affect archetype identity).

[alice-i-cecile]

Naming and Use Cases

@Ratysz:

If we do, we really should think up a better name - I've seen people misunderstand what they are and confuse them with marker components.

@cart:

I think the primary motivator is to use them as "indices" (ex: give me everything with Parent(x), Handle, etc). We could call them that (and "market" them as such?).

I think one of the big issues with the legion implementation was that tags were required in every spawn api. Users were forced to think about them.

[alice-i-cecile]

Archetype Fragmentation

@Ratysz:

I remember that when Legion shed its tags (I think that was a thing that happened, it's been a while) folks were talking about there not being a real usecase for them, citing the fate of the same feature in Unity. When this feature was suggested for hecs, @Ralith raised concerns that overreliance on tags could fragment archetypes more than necessary, impacting performance; stateful queries should help here, though.

@Ralith:

They don't do anything about the fundamental "problem," which is that you're (intentionally!) fragmenting your archetypes. Since that's really the entire point of the feature, it's up to the user to do so iff it's beneficial, which is a nice option to have in theory but could be a footgun in practice, suggesting that the feature should be justified by a strong use case.

@cart:

Yeah its worth measuring. Our sparse iteration performance is pretty great now, but it will still have some indirection in this case because Tags serve as "non-table filters", which means we can't directly iterate tables. We'd instead need to iterate archetypes like we do for sparse sets (which has the potential to jump around positions in tables, although in practice they still tend to glob up in cache friendly ways). I expect perf to still big pretty good, but not as good as direct table iteration. But yeah maybe separate index storage is the right call.

[cart]

One more bit of detail here:

[...] I expect perf to still big pretty good, but not as good as direct table iteration. But yeah maybe separate index storage is the right call.

Storing the index in Archetypes wouldn't fragment tables but it would fragment access patterns in those table. Storing the indices in something that doesn't affect archetype identity (ex: a Map<Index, Vec<Entity>>) would still fragment access patterns.

This could be "optimized" by sorting the Entity list according to table order (both in the Archetype impl and in the "separate storage" impl). The benefit of doing that in the Archetype is that you only need to do the sorting once (and it would also improve "untagged" / normal mixed table+sparse set iteration performance)

[Ratysz]

[...] we really should think up a better name [...]

"indices"

I was thinking more along the lines of "flyweight". Back when Legion had tags, in one of the experiments I did with it I've stored immutable data common among kinds of entities in a tag, e.g. a copy of the base mob properties, and handles to sprites and sounds it used.

Although, this could very well be a niche case, since I've spawed entities fully-formed with all the components they would ever use, and the archetypes never changed after first being populated.

[tigregalis]

What would the usage API look like? How would you query for a specific tagged archetype?

[mtsr]

I was thinking more along the lines of "flyweight". Back when Legion had tags, in one of the experiments I did with it I've stored immutable data common among kinds of entities in a tag, e.g. a copy of the base mob properties, and handles to sprites and sounds it used.

So you could even have some kind of CoW components, that would be great for Bundles with lots of defaults.

[recatek]

This could be useful for batching/instancing entities for rendering. If entities that share the same mesh and material can be easily organized into groups, that saves trouble down the line. For reference, the Unity ECS system does exactly this and takes advantage of it for instancing.