How to handle component-based objects in a game loop?

Question

I've been writing my own game engine and I was wondering the correct way to handle my game objects. Each game object is different. The only thing they have in common is a set of operations to handle their components. With that said, each game object will have different components that do different things. Ex: game object 1 has input, physics and display components; object2 has only a display component. I was wondering if it was best to

1. Loop around the list of objects and call an "update" on each of them and then run each "update" for each component the object holds; or
2. Have a list of components in my game loop and check for each component if they have the current component. If so run it, otherwise move on...

I see benefits and harm to both strategies.

• Benefit of 1 is that there isn't a lot of overhead, but things might get out of sync;
• Strategy two is basically the opposite of 1...

For sake of simplicity I'm not putting how I'll handle the gameloop tick and I'm using a generic language.

Example of code for 1:

gameLoop() {
  forloop on each game object as obj {
    obj->update()
  }
}

//obj
update() {
  foreach component as component {
    component->update()
  }
}

Example of code for 2:

gameLoop() {
  input = &event
  forloop on each game object as obj {
    if (obj->canHandleInput())
       obj->handleInput(&event)
  }
  forloop on each game object as obj {
    if (obj->hasPhysics())
       obj->updatePhysics()
  }
  forloop on each game object as obj {
    if (obj->canDraw())
       obj->Draw()
  }
  //audio...
  //other components
}

What is the currently the most accepted way to handle objects in a game loop?

Answer 1

Both approaches should result in the same result, so your choice really comes down to what makes the most sense architecturally.

But first, your example for approach #2 is incorrect. Each system should have a collection of components, so you do not need to have multiple loops over your game objects. That is:

foreach physicsComponent in physicsComponents {
    physicsComponent.update()
}
....

The advantage of #2 is it gives you more flexibility in how to implement system-specific updates. For example, for a physics-heavy game, you might perform a clustering pre-processing step so that you detect collisions only on pairs of nearby objects. It's also cache-friendly as you're repeating a small bit of code over lots of data in one go.

But the advantage of #1 is that you have more flexibility in how systems interact with each other. Suppose you have an animation system and you want to avoid updating it for far-away objects, since the player won't see them at all. But your physics system might depend on the animations as well - let's say your game is a fighting game where character animations change the physics shapes. You can easily handle this if you update on a per-game-object basis, whereas if you went with #2 you'll get a messy tangle of inter-system dependencies.

Answer 2

gameLoop() {
  forloop on each game object as obj {
    obj->update();
  }
}

//obj
update() {
  foreach component as component {
    component->update();
  }
}

No, not all components require an update. Instead, Write granular systems which handle tasks common to a subset of components, such as updating position by velocity, or computing your graphics transform from position.

Your game loop becomes:

void gameloop() 
{
    for ( auto s : m_systems )
    {
        s->update();
    }
}

Within each system, you have customised loops that only work with a small subset of components, as mentioned before.

It looks like your understanding of this has a few gaps, so I would recommend doing some more reading on Entity Component Architecture, before doing any more work on your engine. I think you will find it illuminating.