How Practical is: entities_with_components(...) ? about entityx

[DanoThom]

Hi,
@IgnatusZuk

For information purposes, the Artemis implementation uses a bit of reflection and polymorphic bitmasking to fire off 'add', 'remove' and other useful events (which can be expanded as necessary) which allows you to take various actions when new entities and components have been added/removed from particular systems etc. Quite handy for many scenarios. I'd recommend taking a quick browse through the code:

https://github.com/vinova/Artemis-Cpp

eg:

void EntitySystem::change(Entity& e) {
        bool contains = (systemBit & e.getSystemBits()) == systemBit;
        bool interest = (typeFlags & e.getTypeBits()) == typeFlags;

        if(interest && !contains && typeFlags.any()) {
            actives.add(&e);
            e.addSystemBit(systemBit);
            added(e);
        } else if(!interest && contains && typeFlags.any()) {
            this->remove(e);
        }
    }

[alecthomas]

@DanoThom EntityX supports all of the operations required to implement that approach.

One thing that is bothering me is the fact that each system has to iterate through ALL entities in order to find entities with the appropriate components, and it's doing that on every update() call. Is that really necessary? That's a hell lot of bitmask checks and temporary tuples constructed and destroyed.

Yes, it is possible that this approach is not appropriate for some entity creation/destruction/usage patterns. For example, in a game where each component is used by just one system, the sparsity of the component vectors might result in unsuitable performance. But in my experience that is rare. Most systems share components.

One alternative is to somehow associate compact component vectors with all systems interested in those components. This brings its own set of problems. Insertion and deletion of components from the middle of vectors is expensive. This also means that component vector lookups by entity are not constant time, as they are of variable length.

Another alternative is (as described by @DanoThom 's example) to track entities with the components you're interested in. But again, what data structure are you going to use? A hash map? A list? Is the secondary data structure bookkeeping overhead going to be a win? It depends.

There are other data structures that are more suitable for different patterns, but the simplicity and cache characteristics of simple vectors of components is appealing.

In the end, it will depend on your usage patterns.

Finally, the bitmask checks are very cheap and there is minimal overhead in acquiring a Component handle. The handle is just a pointer to the EntityManager, and a 64-bit Entity::Id. There is no destructor.

Now imagine 1,000,000 entities (particles and stuff) and 50 fairly small systems. On each game update we have to do 50 million bitmask comparisons just to find out what entities we're interested in.
So really... is this practical?
How's the performance when the list of entities grows?

Benchmarks are included, so you can check this yourself. On my system I get around 18M entity iterations per second with component extraction.

But if you have 1M entities being simulated each frame, any general purpose system will struggle. In particular, particle systems probably aren't a great fit for EntityX (at least, mixed with other entity types). For larger levels, it's unlikely you'd completely simulate all objects in every frame in a traditional system anyway. You would typically partition the simulation by visible or near-visible regions, partially simulate non-visible entities, etc.

Is it possible to have more than one pool of entities? e.g. Separate gameplay entities from GUI entities.

This is definitely possible. You can just instantiate a separate EntityManager. You could use this for a particle system, or other client-only entities, etc.

Could we register systems to events which will be notified when a particular component is added to some entity?

This is already possible.

Could we have non-dynamic systems that store all entities they're interested in?

You can achieve this with the event system, though I'm not sure what you mean by "non-dynamic"?

[iggyzuk]

@alecthomas excellent reply! this answers all my questions and concerns. I guess what's left now is to make a game with it and really find out how it stands vs traditional OOP. I'm especially excited about this; great things can be made with it. :)