• Advertisement
  • entries
  • comments
  • views

Design Flaw

Sign in to follow this  


I've realized a design flaw in my entity/component system: I don't have a good way to actually initialize component data! Looky here:
[source lang="cpp"]
Entity e = entity_system.CreateNewEntity();
entity_system.AttachComponent( e, COMPONENT_XFORM );
/* e can now have position, scale and rotation, but how to initialize it? It
* feels kludgy to dispatch a message or fire an event *after*
* creating/attaching the component to initialize it, so I'm thinking of adding
* a parameter to AttachComponent() to pass a struct of initialization data.
* I don't really want to derive all component data structs from a base type,
* but templates don't feel right either. Le sigh...
[/source]I guess I'll spend some time pondering my approach.

For the moment, I've changed my approach somewhat, to this:
[source lang="cpp"]
Entity entity = entity_system.CreateNewEntity();
BaseComponent* bc = entity_system.CreateComponent( COMPONENT_RENDERABLE );
dynamic_cast< RenderableComponent* >( bc )->SetData( data );
entity_system.AttachComponent( test_entity, bc );
[/source]I don't really like the idea of handing out pointers to components, but it is workable enough for me to move forward until I can come up with a cleaner solution. I guess what I really need to do is something like [font="Lucida Sans Unicode"]entity_system.CreateAndAttachComponent( entity, COMPONENT_TYPE, component_type_data_struct )[/font]. After thinking about it, it really seems the cleanest way from an interface perspective. Unless someone has a better idea.

But it's 1a.m. and I really need to try to resume a more normal sleep schedule or I'm going to sleep through my early morning Important Doctor's Appointment on Monday. So no more coding for me tonight :(
Sign in to follow this  


Recommended Comments

Wouldn't the initialization be a part of the COMPONENT_XFORM struct? Or is that an enumeration value???

Where is the actual structure that holds the position, scale, and rotation being held?

Share this comment

Link to comment
In my system, the AttachComponent (equivalent) call will call the constructor of a new instance of the component and pass e to it. The component is then responsible for initialising itself in the context of entity e, which may require loading it from disk or deriving it from other data.

Arguably, my system isn't without problems - my components can see each other (through indirection via e to e's components), so my 'movable' component can get and modify the 'position' component. I wonder how brittle that's going to end up later...

Share this comment

Link to comment
One requirement for my entity-component system was that it had to work with .NET serialization, which was actually pretty tricky. When instantiating an object from disk, the deserializer calls the class's zero-argument constructor (throwing an exception if one does not exist) and then sets all the property values one by one.

I basically made another initialization function that I call after getting the object out from the deserializer. Then you can write your components under the assumption that all your properties have been initialized.

The advantage of this approach is that you can code your factories the same way. Create a new component, assign some properties, then call your custom initialization function. It's not the most elegant approach, but it works.

Share this comment

Link to comment
[quote name='Jason Z' timestamp='1316636270']
Wouldn't the initialization be a part of the COMPONENT_XFORM struct? Or is that an enumeration value???

Where is the actual structure that holds the position, scale, and rotation being held?
AttachComponent() creates a new component and attaches it to the entity. COMPONENT_XFORM is an enum, letting entity_system know what component type to create and attach. What I'm struggling with is how best to set component data at the time of entity creation--what it's position and orientation are for the Xform component, or what mesh to reference for a Renderable component. Defaults just don't make sense, so I need to find a good and elegant way of passing these params to the component. If it requires a complete overhaul of the entity/component system then so be it, but I'd like to avoid that if I can ;)

These are the kinds of things that come with experience, and experience is what I'm developing now, I guess ;)

Share this comment

Link to comment
The solution our engine took,. which I proposed, was to remove entity ownership of components completely. Each system (or subsystem) such as graphics, physics, etc maintains its components rather than the entity. This reduces the need to pass around a large entity structure, if you use a separate thread or dynamically loaded library for example, and it also increases encapsulation. At the core I gave each Entity the same basic information: location, rotation, scale, and id. This is a simple struct that is passed around to each system to process. When a component is created it is given a pointer to its owner entity, not the other way around like most entity-component designs suggest. Each system stores the components is an array mapped to each entity id. This allows us to process all graphical components for entity n at the same time.

Share this comment

Link to comment

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

  • Advertisement