[Rayhem]

Sure. If your monsters have health, then their health is going to need updating pretty much by definition. Option 1 would be to make each entity responsible for updating itself with an overloaded `update` function in sort of a "classical OOP" fashion:

    for(auto &entity: entities) {
        entity.update();
    }

You're then responsible for weaving the health changes into your update (or getting it from your parent). Weird stuff can happen if one entity updates before another, too: you likely want all of the health updates to occur after all of the damaging events. So now this update function has to register a deferred health update to occur down the line.

Option 2 with something like an Entity-Component-System design would have a "Health" system that handles health updates across the board.

    for(auto &damageEntity: entitiesThatDoDamage) {
        damageEntity.registerDamage();
    }

    for(auto &healthEntity: entitiesWithHealth) {
        healthEntity.updateHealth();
    }

Neither of these options is strictly better than the other. Option 1 is good if you need a lot of bespoke logic for health updates (dragons update differently from humans which are different from vehicles etc.). Option 2 is better if everyone has `newHealth = oldHealth - damage`. Things are generally more similar than they are different, so you end up changing all values of a single "kind" (structures-of-arrays) more often.

[munksbeer]

So, in option two, you'd be using SoA with a

  double health[];

which is the value that would be updated by healthEntity.updateHealth() ? So because you're sequentially updating only that attribute it should lend itself to being cache friendly and potentially prefetch prediction? (can't remember the term)

[Rayhem]

Yes, exactly. If you have to update everyone's health (you do) and the updates are pretty much the same (they are), then things don't get any more cache friendly than this.