Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 13 Jun 2001
Offline Last Active Today, 04:24 PM

Posts I've Made

In Topic: C++ duck typing with optional members

25 August 2015 - 06:02 AM

My god... it's beautiful and terrifying.

In Topic: C++ | Storing different types in a unordered_map

24 August 2015 - 02:04 PM

Maybe you are still misunderstanding what is generally considered a component-entity-system.


I would suggest you read up on the resources posted earlier in the thread. Also this is a very nice, albeit pretty advanced introduction: http://www.richardlord.net/blog/what-is-an-entity-framework


This leads towards the question, how do we know what system is responsible for which component?
How to retrieve them?



You would have a render system that, when asked to render all the stuff, iterates over all entities that contain both a position and a mesh and renders those.

To speed things up the render system can maintain an internal cache of those objects that is updated whenever an entity is removed/added or components are added to/removed from an entity.


I guess my example is a bit misleading since there can also be systems that don't manage their own component type.

In Topic: C++ | Storing different types in a unordered_map

24 August 2015 - 10:58 AM

Why do you want to store all components in one structure?

What's so bad about this?

template<class T> class System {
    std::vector<T> components;

System<Position> positionSystem;
System<Health> healthSystem;

(Not necessarily valid c++)

In Topic: C++ | Storing different types in a unordered_map

24 August 2015 - 07:59 AM

There already exist standard containers for what you are doing yourself:


std::multimap and std::unordered_multimap


The other points still hold true though. This is usually not how ECS are implemented.

In Topic: Structure of object-to-object interaction? (And other questions!)

20 August 2015 - 05:24 AM

I think these types of mutual interations are better handled through a mediator.

Creature::attack() {
    world.attack(this, enemy, AttackType::MELEE_ATTACK);

World::attack(Creature attacker, Creature enemy, AttackType type) {
    attackHandler = attackHandlers.get(attacker, enemy, type);
    if (attackHandler) {
    else {
        // No AttackHandler found for interation between attacker and enemy

MeleeAttackHandler::doAttack() {
    if (attacker.att > enemy.def) {
        enemy.applyDamage(max(0, attack.damage - enemy.shield));

    if (badluck() > 0.1 && enemy.def > 8) {
        attacker.applyDamage(10); // hurt your hand while punching enemy


This prevents your creatures from directly altering the state of the other creatures and allows you to add specialized attack handlers later on if you want to expand.
A similar system could also be used for other interactions between two or more entities, for example reacting to sounds made by a creature.