I've been reading a lot lately about component-based entity systems as opposed to classical object-oriented approaches. I don't like the classical approach for the reasons stated by numerous posters but I've never warmed to the component-based design either.

As evident in the many posts about component-based systems, interaction between components is difficult and often requires some sort of event system which complicates things even more. Also, spatial and other relationships between components are hard to express as components are stored as a list rather than a hierarchy. Above all, it is often overlooked that not all components are the same. Some are merely representative (like meshes or sound effects) whereas others control the entity or parts of it (like scripts, transforms, physics).

Apart from distinct components, I'd like to be able to add attributes to an entity which can be used and manipulated in scripts.

Here is an example of what a typical entity could like like:



So what I want is more like a mix between the two approaches.

I started implementing this design and here is what I have so far:

The component base class contains the virtual member function update( TransformComponent &, bool active ) which has to be defined by all inheriting classes. The transform component passed to this function is the parent transform itself. This also ensures that non-transform components (i.e. representatives) add child components.
A component can use its update routine to do whatever it has to do to ensure that it can represent its parent entity adequately or control/modify and update its children, respectively. a TransformComponent will multiply its transformation matrix with the provided parent transform, a RenderComponent will set its transformation matrix to its parent transform's and update its materials, etc.

The class Entity derives from TrasnformComponent and adds a map to hold attributes.

While controllers like TransformComponent can contain other components, representatives like RenderComponent can not. A component never knows about its parent so interaction between components is limited to the information passed down through the update routine.

The rendering of representative components is handled exclusively by the world and not the entity. The world renders all meshes, light sources, sound effects etc. relying solely on the information in the components themselves. It does not care which entity a component belongs to.

So far a TransformComponent merely provides transformation like translate, rotate and scale but it could be extended to handle perspective/orthographic transformations, physics interaction etc.

So what do you say? Good start or dead end?
Thank you!

[Edited by - Vexator on July 12, 2010 4:17:10 PM]

I achieve hierarchy by allowing data-defined groups of components to be used as components. E.g. I would group the transformation controller (probably a physics/rigid-body component) and the visual representation together into one entity (group of components), and then use that grouping in the car.

Regarding the virtual void Update paradigm - I've scrapped that in favor of letting each 'system' of components update their own type. E.g. the physics-system updates all RigidBodyComponents, the render-system renders all RenderComponent, etc.. Trying to fit all components into one abstraction for "update" always seems to get messy, plus if you group your updates by component-type like this then there's some good performance gains to be had.
In this example, I would have the physics-system update all the rigid bodies, which then output new transforms to their linked render-components. The render-system would then iterate through all the active render-components and draw them.

Quote:Original post by Sneftel
The whole point of an entity system is a flat mix-in-based collaboration structure, which your design doesn't support.

It's a bit hard to say what "the whole point" is... I'd say it's to make defining new entities and game-play code quick and easy through the creation of new data... Others might place the focus on the performance benefits of data-oriented design...

Quote:If components can't find or talk to other components of the same entity, what's the point of considering them as "components" at all?

As shown in my modified example, component names can be used to make communication simple (e.g. chassis.body fetches a RigidBodyComponent from a PysicalComponent). The usual GetComponent<RenderComponent>() can also be implemented (returning a list, gathered recursively though child component-groups), so the fetch-by-name paradigm is supplementary to the traditional fetch-by-type paradigm.

Thank you all for your replies! So your basic concern with my approach is the confusion caused by hierarchies.

But what exactly is the difference between my approach..


Hodgman's..


and WebJeff's?


In the end, there's a transformation which has to be applied to one or several components. With Hodgman's solution, this transformation would be controlled by a seperate component (AxleJointComponent) but I don't see how that's less complicated than my approach; with WebJeff's solution, the dependence is completely hidden in Vehicle4WheelComp/WheelComp.

Don't get me wrong, I appreciate your feedback and I'm sure your systems work great, I just want to understand how and why they work better than a system based on my approach could/would.

I modeled mine around the way that physics middleware works (in my experience). Usually you don't set up hierarchies of objects, you just create joints/constraints between them.
Furthermore, if the physics middleware is controlling the transformation of your scene's objects, then having a separate transformation-hierarchy in your graphical representation isn't very useful (another reason why traditional scene-graphs aren't very popular any more). Hence I've hooked it up so that the output from the physics-scene can be copied across to the graphics scene without there being any "transformation hierarchy" to be kept in sync.

So I'm arguing against the need for "transformation hierarchies" in particular.

I think Sneftel is arguing against the need for component hierarchies of any sort.

@Zipster - data-defined components (aka 'entity templates') go into a factory just like 'native' components do.

entity is a componententity has many componentsentity template is a component descriptorentity template has many component descriptorsfactory creates entities from entity templates

Native components register their constructors with the factory, so data files can pass fixed data (like sibling relationships) to them. Entity templates can also define 'data-driven constructors', which take arbitrary arguments and forward them on to child-component constructors. This whole registering constructors thing turned out pretty complex though, sometimes I wonder if I shouldn't have just used a map<string,string> constructor for everything, or implemented the templates/factory in Lua, etc ;)

Actually, we've discussed it before and you gave me the phrase "composition system" to differentiate it from the type of system Sneftel is describing ;)

[Edited by - Hodgman on July 13, 2010 6:53:15 AM]

Quote:Original post by Hodgman
I modeled mine around the way that physics middleware works (in my experience). Usually you don't set up hierarchies of objects, you just create joints/constraints between them.

Ok, that is a convincing argument.

Now let's say I wanted to add a particle system to the car's exhaust pipe or spot lights at the front - would you solve that using joints as well?