Jump to content

  • Log In with Google      Sign In   
  • Create Account





Design Flaw

Posted by yckx, 21 September 2011 · 292 views

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.

Edit:
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 entity_system.CreateAndAttachComponent( entity, COMPONENT_TYPE, component_type_data_struct ). 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 :(




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

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

April 2016 »

S M T W T F S
     12
3456789
10111213141516
17181920212223
2425262728 29 30

Recent Entries

Recent Comments

Recent Entries

Recent Comments

PARTNERS