Sign in to follow this  
Followers 0
l0k0

Unity
Component Entity Model Without RTTI

67 posts in this topic

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:

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

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?
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[code]
#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;
}
[/code]
0

Share this post


Link to post
Share on other sites
I use this solution:

[code]
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;
}

[/code]
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.
0

Share this post


Link to post
Share on other sites
Simliar to GorbGorb's solution:

Code:
[code]
template < typename T >
inline unsigned int GetRTTI()
{
static char s_rtti;
return &s_rtti;
}
[/code]

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

[b]Con:[/b]
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.
0

Share this post


Link to post
Share on other sites
[code]
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> {
};
[/code]

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...
0

Share this post


Link to post
Share on other sites
This is my implementation of your entity class:

[code]
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;
};
[/code]
0

Share this post


Link to post
Share on other sites
Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "[i]get child component by type[/i]" function whatsoever [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] -- 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.
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1324860026' post='4897366']
Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "[i]get child component by type[/i]" function whatsoever [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] -- 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.
[/quote]
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?
0

Share this post


Link to post
Share on other sites
[quote name='l0k0' timestamp='1326152893' post='4901125']
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?
[/quote]

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.
1

Share this post


Link to post
Share on other sites
[quote name='l0k0' timestamp='1326152893' post='4901125'][quote name='Hodgman' timestamp='1324860026' post='4897366']Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "[i]get child component by type[/i]" function whatsoever [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] -- 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.
[/quote]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?[/quote]It depends on what your use-cases are for the "[font=courier new,courier,monospace]GetComponent<T>()[/font]" 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 [font=courier new,courier,monospace]parent->GetComponent<Transform>()[/font] 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 [font=courier new,courier,monospace]parent->GetComponent<Health>()[/font] 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 [u][i]spooky action at a distance[/i][/u], 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 [u][i]there can only be one[/i][/u] 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 "[i]entity is a vector<component*>[/i]" abstraction, you could write something like this:
[code]Transform* transform = new Transform();
Health* health = new Health();
entity->Add( transform );
entity->Add( health );
entity->Add( new RocketLauncher(transform, health) );[/code]
N.B. these ideas also translate over to the "[i]entity is an int, and systems are a map<int,T>[/i]" abstraction.
3

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1326158891' post='4901151']
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.
[/quote]Seconded.
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
[quote name='phil_t' timestamp='1326185543' post='4901227']
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?
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote name='phil_t' timestamp='1326185543' post='4901227']
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.[/quote]The underlying point about hidden dependencies being bad engineering practice remains, regardless of the actual example content...
Actually, you can even ignore the "[i]there can only be one[/i]" 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.[/quote]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" ([i]which is a transform struct[/i]) and a "transform hierarchy" ([i]which is an array of transform structs[/i]), 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 "[i]there can only be one[/i]" constraint, and you also say that "[i]entity is a component[/i]". If you do this, then you've got all the same benefits you had before ([i]there's nothing you could've made before that you can't make now[/i]), you're violating less engineering principles, and you get your "pre-fab" system for free ([i]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]).
2

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1326239248' post='4901458']
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" ([i]which is a transform struct[/i]) and a "transform hierarchy" ([i]which is an array of transform structs[/i]), 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.
[/quote]

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

[quote name='Hodgman' timestamp='1326239248' post='4901458']
However, you can also solve this with a smaller framework if you don't implement the "[i]there can only be one[/i]" constraint, and you also say that "[i]entity is a component[/i]". If you do this, then you've got all the same benefits you had before ([i]there's nothing you could've made before that you can't make now[/i]), you're violating less engineering principles, and you get your "pre-fab" system for free ([i]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]).
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote name='phil_t' timestamp='1326242167' post='4901468']It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).[/quote]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?[/quote]The easiest is for the rocket's links to it's "holder"/"user" to be weak links ([i]in UML terms: an aggregation/uses link, not a composition/owns link[/i]) - 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).[/quote]The point is that any links are [b]not coded[/b] and automatic; the designer who authors the rocket monster creates the connections [b]as data[/b].

e.g. a quick description of the RocketMonster in Lua could look like:[code]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[/code]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.
3

Share this post


Link to post
Share on other sites
[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).
[/quote]

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?
0

Share this post


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

[CODE]
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]);
}
[/CODE]

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?
0

Share this post


Link to post
Share on other sites
[quote name='ZBethel' timestamp='1326318426' post='4901766']
Is that close?[/quote]
Getting closer, certainly...

I'd take to task your decision to have components attached to entities though. Just give each joint a reference to each transform it is connected to, and process them all as generic joints.
1

Share this post


Link to post
Share on other sites
Would each joint still be an entity though? I guess I see your point. There is no reason to attach components to each other if you don't have a reliable way to query for a specific type (or would want to). The car still needs to have some level of ownership of the joints though, otherwise they get created and then lost in the void. How would you destroy them later? Are you suggesting that the car entity just keep specific references to what it needs rather than use some generic attachment mechanism?
0

Share this post


Link to post
Share on other sites
Yes, pretty much.

When you create a joint you pass it the two transforms it requires. When you create the car, you would pass it a list of associated joints, because the car needs to keep track of joints, and destroy them when it too is destroyed (given that both the wheels and the chassis will likely survive the destruction of the car itself)
1

Share this post


Link to post
Share on other sites
Would recommend then the car itself not create the joints, but instead merely be assigned them by whatever function creates the car? It seems to me that the car should be responsible for creating the joints and maintaining them. Otherwise the system creating the car has to worry about internal details. Do you see a benefit to doing it the former way?
0

Share this post


Link to post
Share on other sites
it depends how much flexibility you are going for.

I would say that a car is any entity with 'Wheel's, a 'WheeledVehicle' behaviour, and a 'VehicleController' attached. What makes it specifically a 'Car', is that it is produced by a 'CarFactory' function, that incidentally sets up an 'OnDestruct' handler to destroy the joints.

(the joints have nothing to do with the Car-as-entity, they have to do with the Car-as-wheeled-vehicle, and as such, I don't see that the Car entity needs to know or care about them)
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0