Supporting Entity Pooling - disabled entities, setting exclude-by-default components, and more?

[BrodyHiggerson]

Hello all,

I have a set of archetypes of entities built up by processing json and creating one entity per file in a separate registry, keyed to an entt::hashed_string, with all of the components and their values set up as per that file, using entt's meta. When I want to create one of those entities, I simply pass in e.g. "Projectile"_hs, and my entity spawning code will find the archetypal entity keyed to that name, and then clone it into the provided, real-world registry, component-by-component.

In situations where I'd like to create a lot of these, the stamp can be a bottleneck.

I propose instead some possible features that could help in this and other situations:

1. The ability to create an entity (or even mark an already-created entity) as "disabled", excluding it automatically from all calls to at least view, and possibly get, has, and so on (design TBD). It would occupy space in the storage as normal, but would simply not appear when iterating a view. Using this, in my example, I could create 1000 "disabled" entities set up according to my projectile archetypal entity during the loading screen, and from then on have them ready to go - as soon as game code wants one, we grab a spare and flip it from disabled to enabled, and from then on it acts like any other entity, completely bypassing the stamping costs mentioned above.

An advantage of this approach is that we could potentially add a signal for when the entity is enabled/disabled, and execute that either for the entity itself only, or to call it on each component that it has. That way, if you wanted to react to the construction of, say, the projectile's ProjectileComponent, you could react to the enabling of it instead if it's going to be pooled (because it might not be useful to react to the creation of a component for an entity that's disabled, for example). But those are just some thoughts on the signalling, that could be totally different.

2. In addition to, or instead of, the above idea (or as a way to build 1.), it could be useful to be able to push excluded types to the registry as whole, and from that point onwards, not have to pass them to the view. This would allow for object pooling in a different way - adding a "DisabledEntityTag" to each entity in the entity pool, and then calling registry.add_excluded_type(), thereafter excluding any entity with that tag from showing up in a view. In this scenario, 'activating' the entity would involve removing the tag.

---

Either way, the goal here is to avoid requiring the user/game code to remember to always pass in the right exclude to avoid accidentally iterating entities still in the pool. Entity pooling should be able to be transparent from that POV, in my opinion - you ask for a Projectile in game code, you get a Projectile! And that's it, you shouldn't care how it was made/pooled.

Thanks.

[skypjack]

Soooooo....... I thought about this a little. Before flooding you with a wall of text 😅 let me ask this: are you familiar with the new entity storage and the way it works? Cuz I think it fits somehow your request or is a good starting point for a proper implementation at least.

[BrodyHiggerson]

I can't yet see the connection just yet, so please, flood me as much or as little as you desire. I'm guessing something related to

The each function iterates only the entities in use, that is, those not marked as ready for reuse. To iterate all the entities it's necessary to iterate the underlying sparse set instead.

[skypjack]

First week after a short vacation. It was a busy one, sorry. 😅
Briefly, the entity storage never drops its elements. Instead, it moves deleted entities on a side of the pool (as in at the top or the end, still tightly packed). This is because it wants to keep track of versions and whatnot. Discarding would make it more complicated to do.
Therefore, you've all entities all the time, both alive and deleted ones (the latter are recycled as soon as you create a new entity).
The sparse set has a built-in policy named swap-only to do that, aside the swap-and-pop (default) and in-place (pointer stability) policies. Moreover, it offers scoped iterators to the caller. That is, iterators that skip deleted elements automatically (or, well, the elements to ignore since they are there in fact).
As you can guess, all views use these scoped iterators during iterations. If you combine a view with an entity storage, it never goes through deleted entities, no matter what. This both helps to save performance and avoids nasty bugs.
In all cases, you can still iterate the whole set of entities by using standard iterators rather than scoped ones. The range returned by these iterators is at least as large as the one returned by their counterparts or bigger if there are deleted entities.
That's it. I re-read your post and I find that this behavior/design/policy fits pretty well with the requirements. Overall, I think it's also a good approach for a storage that supports disabled elements.
However, note that one cannot have pointer stability and disabled elements at the same time with this techinque. It's a matter of performance though. Mixing the two introduces two levels of, let's say, checks to know if an entity is good to go. That said, I also think that a way exists to combine the two in a performing manner but I need to think about that a little longer.
Does it make sense so far btw? Let's share our thoughts and try to refine it for the best. 👍