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!


Madhed

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) {
        attackHandler.doAttack();
    }
    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.


PARTNERS