<object type="Robot">
  <components>
    <component>Examine</component>
    <component>Movement</component>
  </components>
  <properties>
    <property name="Description">It's a useless robot!</property>
    <property name="MovementSpeed">50.0</property>
  </properties>
</object>

Quote:The only thing that pops into my head is that you create a list of all possible entities with their base values and then deep-copy / clone those entities as you need to create new ones? This could become a problem with very large games though.

Quote:Original post by GroZZleR
I've been doing some reading lately and noticed the new trend towards component-based entities

Quote:Original post by GroZZleR
The only thing that pops into my head is that you create a list of all possible entities with their base values and then deep-copy / clone those entities as you need to create new ones?

Quote:Original post by GroZZleR
This could become a problem with very large games though.

Quote:Original post by GroZZleR
Looks like cloning is probably the way to go -- in hindsight I suppose keeping a few extra unused entities of a few kilobytes isn't such a big deal.

Thanks guys.

Quote:Original post by AverageJoeSSU
I do what people say, except i am not deep copying raw data, only references to raw data (i have a feeling the other people in this thread are doing that too, one would hope).

Also, why are people saying that memcpy is a bad idea? its ridiculously fast, way faster than parsing an xml file. if you load an asset into a class, which describes what makes the object, then clone the asset and add things like position and create instances of things that the object needs on its own (like a collision actor).

class cComponentBase{};class cComponent{    cComponentBase *mMyBase;};class cWorldObjectBase : public cComponentBase{    cModel *mMyModel;};class cWorldObject : public cComponent{// implicit->  cComponentBase *mMyBase; <- tells you what model the object uses    cVec3 mMyPosition;    cOrientation mMyOrientation;}class cPhysicsBase : public cComponentBase{    float mMyWeight;};class cPhysics : public cComponent{// implicit->  cComponentBase *mMyBase; <- tells you what the weight is    cWorldObject * mMyWorldObject; // physics component REQUIRES the entity to have a world object component.    cVec3 mMyVelocity;    cVec3 mMyAcceleration;    cVec3 mForces;    void Update ( ); // Updates position, velocity and acceleration for the entity}// this is an entity base that has a world object and physics components (usually more data driven than this - using arrays of components etc.)class cEntityBase{    cWorldObjectBase *mWorldObject;    cPhysicsBase *mPhysics;}// this is the matching entity instanceclass cEntity{    cEntityBase * mMyBase;    cWorldObject *mWorldObject;    cPhysics *mPhysics;}

Quote:Making a clone of an entity doesn't sound like a good idea to me. The proper way to do this is using that good old idiom, instancing. Your xml file there defines an entity "Base" which contains everything about how that entity looks, acts, animates, sounds, etc. Then you create entity instances of that base. each instance doesn't need to store what models, sounds, etc. it uses, it just stores a pointer to the base object, and then has access to any information that it needs. The entity will also have to store any instance data that the base's components require. For example, if you have a "world object" base-component in the base type, then the entity needs a "world object instance" instance-component, which will store the current position of that entity instance.

So your entity has a component instance hierarchy that looks the same as the base, for every base component in the entity base, there is the equivalent instance component in the entity instance and any instance state data goes into the instance components, and any descriptor data goes into the base components.