67 replies to this topic

[l0k0]

I'm writing my own component entity model in C++. At the moment, it is somewhat similar to the framework used for Unity Scripting (particularly in C# with templates). Since I'm still in the early phases of the project, I just used type info to handle the type based retrieval of components like so:

template<class T> T * getComponent() {
	for (int i = 0; i < componentList.size(); ++i) {
    	if (typeid(*componentList[i]) == typeid(T)) {
        	return componentList[i];
		}
	}
	return NULL;
}

However, RTTI (along with exceptions) is typically best left disabled in frameworks and engines if possible. What would you recommend for a minimalist way to get this functionality for components only? I'm willing (and hoping) to use the preprocessor to declare classes and assign them a "type id" kept inside the components themselves. The tricky issue is that this must also support subclasses. So if I call getComponent on a base class it must also return a subclass if it is found.

Is a 32 bit type id determined at compile time my best option here? Any tips from people who have implemented the thing themselves?

[crancran]

What I have typically seen is that there is a unique numeric value assigned to each family of components. You can assign this value either by doing it at compile-time in your code or by using some factory/class registration mechanism that handles the assignment at run-time.

[RobTheBloke]

#define ADD_RTTI(BASE_TYPE, ID) public: enum { kTypeId = ID; }; bool isDerivedFrom(uint32_t nodeType) const { return  nodeType == kTypeId ? true : BASE_TYPE :: isDerivedFrom(nodeType); }  

class Base
{
public:

  enum { kTypeId = 0; }

  virtual bool isDerivedFrom(uint32_t nodeType) const { return  nodeType == kTypeId; } 

  template<typename T>
  T* asType() 
  {
    return isDerivedFrom( T::kTypeId ) ? (T*)this: 0;
  }
  template<typename T>
  const T* asType() const  
  {
    return isDerivedFrom( T::kTypeId ) ? (const T*)this: 0;
  } 
};

class Foo : public Base
{
  ADD_RTTI(Base, 1);
};

class Bar : public Foo
{
   ADD_RTTI(Foo, 2);
};
void rttiTestBar(Base* obj)
{
  Bar* bar = obj1->asType<Bar>();
  if(bar )
  {
    std::cout << "obj is Bar\n";
  }
  else
  {
    std::cout << "obj is not Bar\n"; 
  }
}
void rttiTestFoo(Base* obj)
{
  Foo* foo = obj1->asType<Foo>();
  if( foo )
  {
    std::cout << "obj is Foo\n";
  }
  else
  { 
    std::cout << "obj is not Foo\n"; 
  }
}
int main()
{
  Base* obj1 = new Foo();
  Base* obj2 = new Bar(); 
  rttiTestFoo(obj1);
  rttiTestBar(obj1);
  rttiTestFoo(obj2);
  rttiTestBar(obj2);  
  delete obj1;
  delete obj2; 
  return 0;
}

[GorbGorb]

I use this solution:

inline unsigned int new_id()
{
	static unsigned int previous_id = 0;
	
	++previous_id;
	return previous_id;
}

template< class Type >
class id_container
{
public:
	const static unsigned int value;
};
template< class Type >
const unsigned int id_container< Type >::value = new_id();

template< class Type >
unsigned int type_id()
{
	return id_container< Type >::value;
}

Keep in mind though that this won't work across dll boundaries, and you should make the new_id() function thread safe if you want to use type_id in mutliple threads.

[OutputGenerator]

Simliar to GorbGorb's solution:

Code:

template < typename T >
inline unsigned int GetRTTI() 
{
   static char s_rtti;
   return &s_rtti;
}

Pro:
One of the quickest implementations ever. Don't have to write much at all.
Fast comparisons.
Low memory overhead

Con:
RTTI values are not absolute and will vary with memory layout. Tracking bugs between different code executions may be difficult.
May want more info other than a memaddress.

[fastcall22]

class TypeId {
public:
    virtual unsigned getTypeId() const = 0;

    template<class Type>
    bool isInstanceOf() const {
        return getTypeId() == Type::getClassTypeId();
    }
};

template<class Type, class GUID>
class AcquireTypeId : public virtual TypeId {
public:
    unsigned getTypeId() const {
        return GUID; 
    }

    static unsigned getClassTypeId() {
        return GUID;
    }
};

//
// Elsewhere!
//

class Component : public virtual TypeId {
    /* Stuff */
};

class SpecificComponent
    : public Component
    , public AcquireTypeId<SpecificComponent, 0xF5B30CDF> {
};

Advantages:
+ Identifiers are static
+ No macros
+ Virtual inheritance allows for components to be written in script

Disadvantages:
- Unable to determine parent-child relationships
- Virtual inheritance
- No macros and no names; just a bunch of numbers
o V-table lookup required

Though my design can be improved by embedding the type-info with the object; thus avoiding the virtual inheritance and v-table lookup...

[GorbGorb]

This is my implementation of your entity class:

template< class Type >
void destruct_function( void *obj_mem )
{
  static_cast< Type* >( obj_mem )->~Type();
}

class entity
{
public:
  ~entity()
  {
	for( auto it = components.begin() ; it != components.end() ; ++it )
  	( *it->first )( it->second );
  }
  template< class Type >
  Type *query()
  {
  	auto it = components.find( &destruct_function< Type > );
  	if( it != components.end() )
    	return static_cast< Type* >( it->second );
 	else
   	return 0; 
  }
private:
  std::map< void (*)( void * ) , void * > components;
};

[l0k0]

Thank you very much for all of the recommendations!

[Hodgman]

Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "get child component by type" function whatsoever -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.

[l0k0]

Hodgman, on 25 December 2011 - 06:40 PM, said:

Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "get child component by type" function whatsoever -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.

Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?

[phil_t]

l0k0, on 09 January 2012 - 05:48 PM, said:

Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?

You could have lists that consist of all the components of a particular type for all the entities that have that component. Then you would ask that list "Give me the component for entity id=1234".

So with that way, the entities don't actually store the components - instead all the components of one type are stored together. I think this is what the Artemis framework does.

Since most logic would generally iterate over all components of one type, rather than all components of one entity, that kind of memory layout is more favorable for reducing cache misses.

[Hodgman]

l0k0, on 09 January 2012 - 05:48 PM, said:

Hodgman, on 25 December 2011 - 06:40 PM, said:

Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "get child component by type" function whatsoever -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.

Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?

It depends on what your use-cases are for the "GetComponent<T>()" function, but I'll use an example to illustrate what I assume to be some common use cases:
* We're writing a "rocket launcher" component.
* When firing, it searches it calls parent->GetComponent<Transform>() in order to know where to spawn the rocket from.
* Rockets have a chance of mis-firing, which does damage to the holder - when this happens, it calls parent->GetComponent<Health>() to know where to apply the damage.

The user of the system is now happy that when they add a rocket launcher to an entity, it magically knows from where it should fire, and where it should apply "mis-fire" damage.

In my opinion, the above magic is exactly what makes this design a completely awful piece of architecture -- it makes the software engineering part of my brain feel dirty for hiding known dependencies away under an abstraction in order to achieve spooky action at a distance, which is never a good thing when it comes to being able to reason about the state and interactions in your program.
It also has the problem of enforcing the there can only be one philosophy onto the user -- each entity can only have one transform and one health component -- which may seem like a trivial burden at the time of writing, but at some point your users will find a reason for there to be two of something, and will be forced to construct ungracious work-arounds involving several entities cooperating to function as one "entity".

All of these engineering taboos can be easily avoided if the rocket launcher is simply told in advance which health/transform components it is going to be interacting with, instead of acquiring them by magic (type). This could simply be done by giving the rocket launcher component some properties that the user can set, which contain the names of the linked components.

Another example of how you can connect them is during construction, e.g. in the "entity is a vector<component*>" abstraction, you could write something like this:

Transform* transform = new Transform();
Health* health = new Health();
entity->Add( transform );
entity->Add( health );
entity->Add( new RocketLauncher(transform, health) );

N.B. these ideas also translate over to the "entity is an int, and systems are a map<int,T>" abstraction.

[Krohm]

Hodgman, on 09 January 2012 - 07:28 PM, said:

All of these engineering taboos can be easily avoided if the rocket launcher is simply told in advance which health/transform components it is going to be interacting with, instead of acquiring them by magic (type). This could simply be done by giving the rocket launcher component some properties that the user can set, which contain the names of the linked components.

Seconded.

[phil_t]

Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense. I don't have that much experience in this area, so perhaps I haven't thought it through enough?

[crancran]

phil_t, on 10 January 2012 - 02:52 AM, said:

Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense. I don't have that much experience in this area, so perhaps I haven't thought it through enough?

That is how I have seen it often modelled in the past. Typically the rocket launcher entity contains a component called "EquippedBy" or "UsedBy" that holds a reference to the using entity when equipped. So when the rocket launcher's fire logic is invoked, if it misfires or properly fires, you know both the entity to apply the misfire damage to as well as the location of where the shot originates.

The benefit of it being treated as a separate entity is that if you ever wish to model this launcher in a preview frame or want to animate it being dropped in favor of another weapon, you can do so by simply dropping the equipped by component from the entity. The rocket continues to hold onto it's mesh and other components as a free standing entity in the game world. Additionally when you want to animate death sequences and animate the dropping of the gun when the player dies, you can easily do so by again removing a single component from the weapon entity.

[Hodgman]

phil_t, on 10 January 2012 - 02:52 AM, said:

Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

The underlying point about hidden dependencies being bad engineering practice remains, regardless of the actual example content...
Actually, you can even ignore the "there can only be one" advice, and the point about dependencies still remains.

Quote

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense.

It's the same as the Singleton pattern. At the time you assume that "there can only be one" isn't going to get in the way, even though there's actually no requirement for you to implement that constraint. Adding a constraint that isn't required isn't often a good idea - all it's going to do is box future work into a constrained framework for no reason, other than laziness in the present... but if you think using singletons is a good design... ;p ;)

As for multiple transforms - I'm working on a sports game at the moment where each player is made up of over 50 transforms. Different parts of the code need to connect to different ones - the "look at" component connects to the head, the "catch"/"ball" components want to connect to the hands, the AI wants to connect to the feet, player-interaction actions want to connect different parts of different players together...
You could alternatively implement this by having each player own a "root transform" (which is a transform struct) and a "transform hierarchy" (which is an array of transform structs), or by treating skeletons as a special case that shouldn't be handled the same as other transforms, but then I've got to implement several extra components (and a whole bunch of special case logic) instead of just using the existing, simple, system.

This all also depends on what an entity means to you. If an entity is a single "prop", that you can easily instantiate, then yeah anything you want to be able to spawn by itself in one go should be an entity.
But what about when I want to spawn a monster holding a rocket, or a car with 4 wheels? Suddenly I've got to create two or five entities in order to create my one logical "prop" --- so you work around this by adding another concept of "templates" or "pre-fabs", which are collections of entities that you can spawn together in one go. Ok, problem solved, no big deal, right?
However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).

[phil_t]

Hodgman, on 10 January 2012 - 05:47 PM, said:

As for multiple transforms - I'm working on a sports game at the moment where each player is made up of over 50 transforms. Different parts of the code need to connect to different ones - the "look at" component connects to the head, the "catch"/"ball" components want to connect to the hands, the AI wants to connect to the feet, player-interaction actions want to connect different parts of different players together...
You could alternatively implement this by having each player own a "root transform" (which is a transform struct) and a "transform hierarchy" (which is an array of transform structs), or by treating skeletons as a special case that shouldn't be handled the same as other transforms, but then I've got to implement several extra components (and a whole bunch of special case logic) instead of just using the existing, simple, system.

It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).

Hodgman, on 10 January 2012 - 05:47 PM, said:

However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).

How does the rocket component know the monster died and the links to its health/transform component are no longer valid? What code is responsible for possibly wiring up the rocket component to another entity? Won't that code need to somehow find specific Health and Transform components for that new entity? (In which case you have the same "hidden" dependencies as you would have if the rocket was a separate entity that had a changeable parent whose Health and Transforms properties it requested - only you had to write extra code).

I'm just not yet convinced this simplifies anything.

[Hodgman]

phil_t, on 10 January 2012 - 06:36 PM, said:

It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).

Transforms and "look at's" are just data, and the "look at system" uses both those pools of data to modify some transforms.

Quote

How does the rocket component know the monster died and the links to its health/transform component are no longer valid?

The easiest is for the rocket's links to it's "holder"/"user" to be weak links (in UML terms: an aggregation/uses link, not a composition/owns link) - when the monster is destroyed, the links are automatically broken / known to be invalid upon inspection. This is a common problem/solution in all entity systems, whether they're one-component-type-per-entity, other component-based, or even old-school-inheritance based...

You could have the rocket entity automatically transition into a 'dropped' state when it's owner link is broken, or alternatively, when creating the monster, you could manually connect it's OnDeath event source up to the rockets Drop event target. This manual connection would be made by the designer of the RocketMonster, at the same time as they were connecting the rocket's "owner" property to the monster.

Quote

What code is responsible for possibly wiring up the rocket component to another entity? Won't that code need to somehow find specific Health and Transform components for that new entity? (In which case you have the same "hidden" dependencies as you would have if the rocket was a separate entity that had a changeable parent whose Health and Transforms properties it requested - only you had to write extra code).

The point is that any links are not coded and automatic; the designer who authors the rocket monster creates the connections as data.

e.g. a quick description of the RocketMonster in Lua could look like:

function CreateMonster(pools) return {
  Transform = pools.transforms:Create(),
  Model = pools.models:Create("monster.model"),
  AI = pools.monsterAI:Create(),
  onConstructed = function(e)
    e.AI.location = e.Transform
    e.Model.transform = e.Transform
  end
} end

function CreateRocketMonster(pools) return {
  Monster = CreateMonster(pools),
  Rocket = CreateRocket(pools),
  onConstructed = function(e)
	e.Rocket.user = e.Monster
	e.Monster.AI.OnDeath:Add( function(e) e.Rocket:drop() end )
  end
} end

Ideally, you wouldn't have your designers writing Lua data manually though, so imagine instead that this is the output of their entity designer GUI, after they've created a "monster" entity made up of a transform/model/ai component, with the AI location linked to the transform and the model having a default path, and after they've then created a "rocket monster" entity made up of a rocket and monster entity, and with the rocket's user linked to the monster and the monster's AI component's on-death even linked to the rocket's drop event.

[ZBethel]

Quote

However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).

I understand this concept, but I'm struggling to understand how it translates into more complicated situations. Are the entities themselves independent, linked only by specific components? How would you go about creating an articulate physics model with this method? Say, a vehicle. Would each wheel of the vehicle be an entity with a physics component, connected to the base by an entity for the joint? Would the parent entity "own" the child entities or would they simply link the physics components together? It's cases like these that get me all confused.

Would you mind explaining how you would implement a more complicated example with say, a car or tank?

[ZBethel]

I thought more about this, and here's how I understand it to work. Please comment/correct as you see fit:

class IComponent {
public:
   // Not sure what to put in here. Maybe type information? I thought we were trying to get rid of that altogether though.
};
class Entity : public IComponent {
public:
	AttachComponent( IComponent *comp );
	DetachComponent( IComponent *comp );
};

class Transform : public IComponent {
    ...
};

class RigidBody : public IComponent {
    ...
};

class Joint : public IComponent {
    ...
};

// Create a car
class Car : public Entity {
public:
	...
	Create();
};

Car::Create(Vec3 pos)
{
	// Create transform.
	Transform *t = new Transform();
	t->SetIdentity();
	t->Translate( pos );
	AttachComponent(t);

	// Create car base
	RigidBody *base = new RigidBody(t, ...);
	AttachComponent(base);

	// Create car wheels
	RigidBody *wheels[4];
	wheels[0] = new RigidBody(...);
	wheels[1] = new RigidBody(...);
	wheels[2] = new RigidBody(...);
	wheels[3] = new RigidBody(...);
	for( i=0; i<4; i++ )
		AttachComponent(wheels[i]);

	// Create joints connecting the wheels to the car
	Joint *joints[4];
	Joint[0] = new Joint(wheels[0], base, ...);
	Joint[1] = new Joint(wheels[1], base, ...);
	Joint[2] = new Joint(wheels[2], base, ...);
	Joint[3] = new Joint(wheels[3], base, ...);
	for( i=0; i<4; i++ )
		AttachComponent(joint[i]);
}

The joints could then be destroyed and the wheels removed from the car entity, and they would still be free to bounce around the world.
Is that close?