entity / component system

Started by
2 comments, last by Stani R 14 years, 5 months ago
I'm still trying to understand the whole entity/component system over using traditional object hierarchy in a game (theres not enough info about it on the web). I have a simple door I wish to open when the player is within a certain distance. Using OOP I would have something like this:


class Door : public GameObject
{
public:

   void update(float dTime)
   {
      if(position.distanceTo(player->position) < radius)
      {
         this->open();
      }
   }

private:

   Vector3 position;
   float radius;
   Player* player;
};


(I won't go into the details of how the Door::open() function work) can someone show me how this would be done using entities and components?
Advertisement
Define a new component - event (a delegate in C#). Let it be called ProximityTrigger.

On each tick, test which entities moved. Pass them to ProximityTriggers. Those will, if needed, fire events to whoever registered to them.

Door will be listening on one of them.
my attempt:(

class ProximityTrigger{public:   ProximityTrigger(Vector3 position, float radius)      : position(position)      , radius(radius)   {   }   void test(Vector3* positions, int nPositions)   {      for(int i = 0; i < nPositions; ++i)      {         if(positions.distanceTo(position))         {            for(int j = 0; j < observers.size(); ++j)               observers[j]->trigger(this);            break;         }      }   }   class Observer   {   public: virtual void trigger(ProximityTrigger* pt) = 0;   };   std::vector<Observer*> observers;private:   Vector3 position;   float radius;};class Door : public ProximityTrigger::Observer{public:   virtual void trigger(ProximityTrigger* pt)   {      this->open();   }private:   Vector3 position;   Player* player;};



how do you know that entities even have a position? from what I've read an entity has no data until you add data in the form of components. And where do you store these proximity triggers? do they not need to be stored in an entity also?
As an alternative to Antheus' polling approach, depending on the specific problem, you can also try a pushing approach:

PlayerKinematicsComponent: //belongs to player    on update:        if(haveMoved):            container.postMessage(PLAYER_MOVED)BellBoyComponent: // belongs to door    on message:        switch(msg.type):        case PLAYER_MOVED:            if ( (msg.xyz - this.xyz) < threshold):                openDoor()


In this case, the player himself is the source of the event, and it is the responsibility of the container to broadcast or narrowcast it. This decouples the door from the player but introduces more complexity in the form of an agreed-upon language that both must talk. The tradeoff is speed vs. flexibility.

This topic is closed to new replies.

Advertisement