Best way to handle gameobjects and sceneobjects?

[polylux]

Dude, even if you put it in CAPS, then what doesn't state at all what we should help you with. Is it how these objects should then interact with each other? Game mechanics? Network distribution? Hierarchy?

[AReichl]

I will never get an answer to this for the rest of my life.

> Is it how these objects should then interact with each other?
Yes

> Game mechanics?
?

> Network distribution?
That's the last thing i can worry about.

> Hierarchy?
?

I am just asking for a piece of code. Maybe a class with name "CEntity" and one with name "CComponent".
And maybe an "EntityManager". ANYTHING as a starting point.

[odenter]

Maybe you should open an thread on you own and ask your questions. You could post there how you think your CEntity class should look like and the discuss your decision.

[polylux]

I just leave this piece of code out of a base class here for your consideration:

Code: Select all

//!The constructor.
    /**Normally, an OFLGameObject always provides a pointer to an ISceneNode it's connected
    with. If for some reason this is obsolete, omit the parameter.
    \param n: The pointer to the geometry node. Note that OFGO expects the scene node to be already added to the scene.**/
    OFLGameObject(u32 objID, scene::ISceneNode* n = 0);
    //!The destructor.
    /**The OFGO automatically takes care of removing the associated scene node from the scene.*/
    virtual ~OFLGameObject();
    //!Assigns a name to the OFLGameObject.
    /**Allows to name the model. Note that the name is stored separately and not within ISceneNode.
    \param newname: The name the game object should be set to.**/
    virtual void setName(const core::stringw& newname);
    ///retrieve the name
    virtual const core::stringw& getName() const;
    const u32& getObjectID() const;
 
    virtual void setModel(scene::ISceneNode* n);
    virtual scene::ISceneNode* getModel();
    
    ///used by the CombatManager to store a pointer to the mesh's triangle selector
    scene::ITriangleSelector* selector;
    ///gets the object's current position
    virtual const core::vector3df& getPosition() const;
    ///gets the object's current rotation
    virtual const core::vector3df& getRotation() const;
    ///gets the object's current scale
    virtual const core::vector3df& getScale() const;
    ///sets the object's current position
    virtual void setPosition(const core::vector3df& pos);
    ///sets the object's current rotation
    virtual void setRotation(const core::vector3df& rot);
    ///sets the object's current scale
    virtual void setScale(const core::vector3df& scale);
    //!Assigns this OFLGameObject a parent object
    /**Normally, this doesn't have to be called explicitly. It's used by the
    addChildObject function to mark the child having a parent.
    \param parentObject: An OFLGameObject to be its parent.**/
    virtual void setParentObject(OFLGameObject* parentObject);
    //!Adds a child to the current object, if possible.
    /**This function goes through the list of allowed OFLGameObjects for the
    current one and adds it in a free slot. If no slot is free, it replaces one.
    \param childObject: A OFLGameObject to be used as the current's child.
    \return True if childObject is a valid child and was added to its parent. False otherwise.
    \see attachChildModel() to be used if special attachment rules apply for a specific OFLGameObject derivate.**/
    virtual bool addChildObject(OFLGameObject* childObject);
    //!Removes a child from the object, if possible.
    /**This function accordingly removes a child from the object given it is
    currently in such a relation. For detachment, the protected function \see detachChildModel()
    is called to allow deriving classes to handle detachment respectively.
    \param childObject: A OFLGameObject to be removed as the current's child.
    \return True if childObject is a current child and was properly detached. False otherwise.
    \see detachChildModel() to be used if special detachment rules apply for a specific OFLGameObject derivate.**/
    virtual bool removeChildObject(OFLGameObject* childObject);
    //!Requests whether the current object can basically use another object of a given type.
    /**The function goes through the list of specified "usables", normally there should be no need to override that.
    \note This function is intended to be used to generally request whether objects are compatible. For a more specific
    test, use canUseObject(), as this is more specific. For example, just because it is a
    magazine, it does not necessarily fit into a specific weapon.
    \param obj: An ObjectType to be requested as usable for the current object.
    \return True if the object can use this type. False otherwise.
    \see OFLGameObject::ObjectType.**/
    virtual bool canUseObjectType(const OFLGameObject::ObjectType& obj) const;
    //!More statefully inspects whether one object can be used with another one.
    /**Contrary to canUseObjectType, this function thoroughly checks whether two objects
    are compatible. Use it whenever possible. This check is also performed whenever two objects are tried to be assigned
    to each other.
    \param obj The object the compatibility check should be performed with.
    \return Whether the objects are truly usable with each other.*/
    virtual bool canUseObject(const OFLGameObject& obj) const;
    ///Returns if the object is currently assigned to another -> has a parent.
    virtual bool isAssigned();
    ///Get the object's parent object, 0 if no parent assigned.
    OFLGameObject* getParent() const;
    ///Get the object's type.
    const ObjectType& getObjectType() const;
    //!Retrieve the current list of child objects
    const ChildObject* getChildObjects() const;
 
    GameSides gameSide;
 
 
 
    private:
    OFLGameObject();
 
    protected:
    core::stringw name;
    OFLGameObject* parent;
//    OFLGameObject::ObjectType objTypeList[32];
//    OFLGameObject* childList[32];
    ChildObject childList[32];
    ///in case of special attachment rules for deriving game objects, override this function
    virtual void attachChildModel(OFLGameObject* go);
    ///in case of special attachment rules for deriving game objects, override this function
    virtual void detachChildModel(OFLGameObject* go);
    ///if implemented, this is called in the game's main loop. Used for various stuff, like draw specific HUD information, ...
    virtual void loop(video::IVideoDriver*);

[AReichl]

NOW we are talking!

> Maybe you should open an thread on you own and ask your questions.
or we could "hijack" this thread. It would fit the topic.

> I just leave this piece of code out of a base class here for your consideration:
What i see here is a class that wraps a scenenode. That's fine for learning C++.

Ok - maybe you really don't understand what i am searching for.
Google "Actor-Framework", "Anax", "Artemis", "Coment", "EntityX" then you get
an idea. I already tried to combine one of this frameworks with Irrlicht but failed
( maybe the framework was the wrong one or Irrlicht did not fit into it or most
probable i did not understand enaugh at that time ).

My biggest problem was physics. Sound could be added as a component, but physics
is an independent subsystem and gave me headaches. For example IrrBullet has "animators"
for irrlicht, but they are more like "extensions" to the scenemanager of Irrlicht, no independent
components you can just add to a gameobject.

What i am searching for is an entity-component system that fits nicely with Irrlicht.

[odenter]

I would say you're talking about game engine subsystems (sound, physics and so on).

A game entity component for me is a health component or a shield component which is attached to on or more gameobjects and represents everything related to health or shield properties. Basically just an encapsulation.

I've never done physics stuff but why should it fit into irrlicht? You just apply the result of some calculations back to your scenenodes (position, rotation, etc.).