Jump to content
  • Advertisement
Sign in to follow this  

Unity Component Entity Model Without RTTI

This topic is 2316 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


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.

Share this post


Link to post
Share on other sites
Advertisement
[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 "get child component by type" function whatsoever wink.gif -- 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?[/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 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.

Share this post


Link to post
Share on other sites

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.

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?

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?


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.

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.
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.
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" (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).

Share this post


Link to post
Share on other sites

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


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.

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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?

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:


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);

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


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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!