[Feature request] Tags: Revenge

[skypjack]

More than once I've been asked to reintroduce tags in v3.
However, the previous implementation had some design flaws and problems and I don't want to restore it.

The purpose of this issue is to discuss common uses and requirements (ie should tags be assigned to entities or not?), then try to find an implementation that works and makes sense.

I'd like also to understand if it's something that most of the users want back or not, so please add at least a 👍 to the issue if you want to see tags also in v3 but you don't want to participate to the discussion.

Thanks.

[vblanco20-1]

Personal opinions from my own experiments and projects.

A "singleton component" is something ive allways used, a lot of times. I tended to use the tag feature before, but when it got deleted i just implemented my own.
My singleton implementation just consists of reserving one entity, and you have functions that mirror get, accumulate, and set, but have no entity. This methods will just affect the singleton entity.

The usage of singleton components is very common when you want "engine-wide" globals. I have a GameTimeComponent, wich holds pause state, delta time, and other similar values, and then i use it everywhere. I also use singleton components to store System related data, like an acceleration structure. This lets me have multiple different systems that affect the same acceleration structure, or query it to do physics. Very useful to have all your "system state" in components like this, and keep the systems themselves stateless. It allows you to store the ecs state into a file, or resume things, or have a system that caches it later, or debug menus...

I think a possible implementation is just to go with that singleton entity, as its barely a couple lines of code, and even lets you have multiple of the same "singleton", if you create a new entity and assign that component, as the singleton entity will still appear in Views.

[danielytics]

To me, the name tag sounds essentially like what EnTT’s labels are. A singleton component is useful, but please don’t call it tag 😝

I also like he idea of sharing a component betweeen multiple entities (groups of entities sharing components, not a singleton component), but it’s already easy to do this by having components store a handle or id for some shared resource, so EnTT doesn’t need anything here.

I do think the tag concept is a useful one to support and I’d welcome its return. But with that said, I haven’t found them necessary either because I already use handles to a resource system and service locator to access that, and then tag my entities with label components as necessary, or store entity ids in systems state where I would have selected by tag before, although tags do let you to add other components in a view.

[pgruenbacher]

I like the idea of singletons being tied to the registry mainly because
a) if I have multiple registries for simultaneous simulations, i'd want multiple singletons for each
b) I like to think of the registry as the ultimate source of truth of data
c) easier for system functions to access the singleton data if associated with the registry. allows for updateSim(Registry) instead of updateSim(Registry, cameraSingleton, timeSingleton), not the best example but essentially anything that reduces my system function signature sizes is helpful, and passing a registry around everywhere for function data inputs gets to be very useful pattern.

[skypjack]

Added a note the to the TODO list. Not sure I'll reintroduce them with v3, but I'll do my best to do it. 👍