"Simpler" component/composition entity system

Started by
16 comments, last by pulpfist 14 years, 4 months ago
Hey. I've been looking around these forums, and the net in general, about composition for entities in my game over huge inheritance trees. However, most of them deal with,imho, a lot larger scale game, with registering each component and managers and the suchlike. Whereas I plan on having just a basic thing:

class Entity
{
BehaviourObj behavObj;
DrawObj drawObj;
etc. 
}
I picked this up through numerous articles. However, I'm not sure which one of the following I should go for. 1)

class Player(or Enemy, or Bullet, or whatever): public Entity
{
}
Where each object has a single level of inheritance. 2)

class Player(etc.)
{
Entity * entity;
}
And have each object separately, but containing an Entity object. I am not overly sure. -Thanks.
Advertisement
The way I've currently got my system laid out is by having 1 single entity class which can have components added to it, and a bunch of components to serve simple tasks. Basically the idea is I would compose a game object like so:

GoEntity | |- contains - RenderModel |- contains - RigidBody |- contains - SoundSource


That being a simple entity which has a model, is a rigid body in a simulation, and can emit sound. Each component derives from GoComponent, which contains virtual initialise, update, and render. I didn't really want the render as it seems a bit specific - but it's there nonetheless.

The GoEntity itself contains a transform for where it is in relation to it's parent (normally a GoWorld), and a list of components it updates and renders.

Codes been written for a while, however it's not really been put to the test yet - spent a lot of time writing the engine and editor, so it's probably got a few flaws I'm yet to find.
Adventures of a Pro & Hobby Games Programmer - http://neilo-gd.blogspot.com/Twitter - http://twitter.com/neilogd
I don't know what you did, but you made something click from when I did XNA and GameComponent derived stuff. =P

I assume, therefore, that every entity would be an instance of GoEntity?

Also, btw, what do you mean by rigid body? I take it to be something to do with 3D collision?

Thanks, that definitely helped. :D
-TCD.
Yes - every entity would be an instance of GoEntity. Nothing derives, it is a concrete implementation with barely any functionality of it's own. To implement new functionality you would derive and implement it as a new component. I'm tempted to put basic properties into it, but it's also tempting to have a PropertyComponent to do that, however that might be going over the top.

By rigid body, I mean a, well, rigid body - a body with physics applied to it, collision shape, collision response. This is implemented using Bullet or ODE. Basically the component wouldn't need to know about the render model, and the render model wouldn't know about the rigid body - they would interact via the GoEntity. RigidBody would set the transform, and RenderModel would get the transform for rendering.
Adventures of a Pro & Hobby Games Programmer - http://neilo-gd.blogspot.com/Twitter - http://twitter.com/neilogd
Thanks for clearing that up.
+Rate.
-TCD.
I've adopted an outboard component system and it's worked pretty well so far. In a nutshell, it works like this:

An entity is created and a message is sent out to interested listeners. Listeners inspect the entity and, if they're interested, create internal 'subsystem-level' component representations. A graphics subsystem, for example, might create a Renderable for each visual entity. From then on each subsystem does its own thing, querying the entity for any information it doesn't store internally.

It's pretty simple to set up once you get your head around it, and I haven't run into any complications yet. Let me know if you have any questions [smile]
Quote:Original post by Ariste
I've adopted an outboard component system and it's worked pretty well so far. In a nutshell, it works like this:

An entity is created and a message is sent out to interested listeners. Listeners inspect the entity and, if they're interested, create internal 'subsystem-level' component representations. A graphics subsystem, for example, might create a Renderable for each visual entity. From then on each subsystem does its own thing, querying the entity for any information it doesn't store internally.

It's pretty simple to set up once you get your head around it, and I haven't run into any complications yet. Let me know if you have any questions [smile]


How does the entity track its Renderable? Does the component manager create and keep track of the object and the entity just gets an id? Or is like a pointer passed into the event message and is filled out by the manager?

That's the nice part - the entity doesn't have to track its Renderable. Only the graphics system needs to know that the entity has a Renderable at all. When the entity is first created, a pointer to it is distributed via the messaging system to interested listeners. Any of these listeners can create their own subsystem-level components, like Renderables for graphics, which will keep this pointer so they can access the entity when necessary. The entity doesn't need to know anything about it.

Having said that, I still have components register with their entities so components in different subsystems can communicate if they need to. This kind of inter-subsystem communication is pretty rare, though. It looks something like this: pEntity->GetComponent<Renderable>().GetSceneNode();
I've been reading everything I can find on component systems (It feels like annnny second now it's going to click!) but I'm struggling to understand some of the implementation details. (Does anyone know of a simple (perhaps the most simple!) implementation of say, a pong game or even just a demo?)

The part I am stuck on at the moment is: does each component have to know how to deal with every single "type" of entity? For example, if you have MovementComponent which updates each entity... how do assign the algorithm for the different types movement? When set the component up for an entity do you give it a type... for example
entity.addComponent(Movement, MovementType.WALKING);
and do something like this for each entity inside it's update method?
switch(entity.MovementType)	case MovementType.FLYING: entity.y--;entity.x++;	case MovementType.WALKING: entity.x++	case MovementType.CIRCLING: entity.x = sin(entity.x++)...	etc?!
Then if you had a CollisionComponent how would you make rules like: "If the current entity a player and it collides with an entity of type enemy then die, but if it collides with enitity type wall then stop..."

It seems like every component would need to know about every entity type to implement rules? Is that right?
Quote:(Does anyone know of a simple (perhaps the most simple!) implementation of say, a pong game or even just a demo?)
Simple, or even complex-ish games, don't NEED an entity/component system. Applying one just makes things more confusing, without clearly showing the benefits or even the purpose of such systems.
Quote:
The part I am stuck on at the moment is: does each component have to know how to deal with every single "type" of entity? For example, if you have MovementComponent which updates each entity... how do assign the algorithm for the different types movement? When set the component up for an entity do you give it a type... for example

entity.addComponent(Movement, MovementType.WALKING);

and do something like this for each entity inside it's update method?
I'm not sure what you're describing here. If you had different types of movement, you'd probably have different subclasses of MovementComponent, each one with a different type of movement, and you'd put the correct one into each entity. That's just one approach, though.

This topic is closed to new replies.

Advertisement