Component entity system - Updates and call orders

Question

In order to get components to be able to update every frame (and leave this functionality out of components that don't need to) I got the idea to make an UpdateComponent component. Other components like MovableComponent (which holds velocity) would inherit from the IUpdatable abstract class. This forces MovableComponent to implement an Update(gametime dt) method and another RegisterWithUpdater() that gives UpdateComponent a pointer to the MovableComponent. Many components could do this and then UpdateComponent could call all of their Update(gametime dt) methods without having to care about who or what they are.

My questions are:

1. Does this seem like anything that is normal or used by anyone? I cannot find anything on the subject.
2. How could I maintain an order to the components like physics then position change? Is this even necessary?
3. What are other ways of insuring that components that should be process every frame are in fact processed?

EDIT
I think I will be concidering how to give the entity manager a list of types that are updatable. Then ALL of the components of that type can update rather than managing it per entity (which are just indexes in my system anyway).

Still. My questions remain valid to me. I don't know if this is reasonabl/normal, or what others tend to do.

Also, the people at Insomniac are awesome! /EDIT

Boiled down code for previous example:

class IUpdatable
{
public:
    virtual void Update(float dt) = 0;
protected:
    virtual void RegisterAsUpdatable() = 0;
};

class Component
{
    ...
};

class MovableComponent: public Component, public IUpdatable
{
public:
    ...
    virtual void Update(float dt);
private:
    ...
    virtual void RegisterWithUpdater();
};

class UpdateComponent: public Component
{
public:
    ...
    void UpdateAll();
    void RegisterUpdatable(Component* component);
    void RemoveUpdatable(Component* component);
private:
    ...
    std::set<Component*> updatables_;
};

Answer 1

One of the primary benefits of a component system is the ability to take advantage of caching patterns - good icache and prediction because you run the same code over and over, good dcache because you can allocate the objects in homogeneous pools and because the vtables, if any, stay hot.

The way you have structured your components, this advantage disappears completely, and in fact can become a performance liability compared to an inheritance-based system, as you're making far more virtual calls and more objects with vtables.

What you should be doing is storing pools per type, and iterating each type independently to perform updates.

Does this seem like anything that is normal or used by anyone? I cannot find anything on the subject.

It's not as common in large games because it is not advantageous. It's common in plenty of games, but it's not technically interesting, so no one writes about it.

How could I maintain an order to the components like physics then position change? Is this even necessary?

Code in languages like C++ has a natural way to order execution: type the statements in that order.

for (PhysicsComponent *c : physics_components)
    c->update(dt);
for (PositionComponent *c : position_components)
    c->update(dt);

In reality, that doesn't make sense because no robust physics system is structured that way - you can't update one single physics object. Instead, the code would look more like:

physics_step();
for (PositionComponent *c : position_components)
    c->update(dt);
// Updates the position data from the physics data.

Answer 2

What you're talking about is reasonable and fairly common, I think. This might give you some more information.

Answer 3

I like these approaches:

• Evolve Your Hierarchy
• Entity Systems are the Future of MMOs Part 5

Shortly: Avoid keeping update behavior within components. Components are not behavior. Behavior (including updates) can be implemented in some single-instance subsystems. That approach might also help to batch-process similar behaviors for multiple components (maybe using parallel_for or SIMD instructions on component data).

The IUpdatable idea and Update(gametime dt) method seems a bit too restrictive and introduces additional depencencies. It might be fine if you are not using subsystems approach, but if you do use them, then IUpdatable is a redundant level of hierarchy. After all, the MovingSystem should know that it must update the Location and/or Velocity components directly for all entities which have these components, so there is no need for some intermediate IUpdatable component.

But you could use Updatable component as a mechanism to skip updating some entities despite of them having Location and/or Velocity components. The Updatable component could have a bool flag which can be set to false and that would signal every Updatable-aware subsystem that this particular entity currently should not be updated (although in such context, Freezable seems to be more appropriate name for the component).