Should I inherit my objects, e.i. Player, or bullets, e.t.c… from CCSprite, CCObject, CCNode? Or some other class?
And why?
I’d suggest that you make a GameObject class which can contain a sprite, physics body, and whatever else a GameObject may need. Composition and components are (IMO) much easier to manage versus inheritance.
The GameObject is a sprite.
versus
The GameObject has a sprite.
Here is a good link on info about component systems: http://stackoverflow.com/questions/1901251/component-based-game-engine-design
Dynamic component systems can get very complicated, so if it seems overwhelming I’d suggest you start simple and just put a pointer to all the things that can go into a GameObject(sprite, physics, etc); then set the pointer to 0 if that component is not being used.
Thanks for the quick reply.
Ok. Lets say I do want to go with GameObject HAS a sprite method.
What classes should my GameObject class inherit from then?
Should it inherit from CCTargetedTouchDelegate if I want it to be clickable?
How do I manage the autoRelease stuff?
Would it be possible to post an example of a GameObject class that you could create, just so I can get an Idea of how you would manage the sprites during cleanup and stuff. And see how to manage touches, and its own cleanup.
If someone could do this, I would be forever greatful.
What classes should my GameObject class inherit from then?
The GameObject class probably shouldn’t derive from anything in Cocos2d. Remember, the GameObject has a sprite. This will help tremendously if you ever decide to move your code to another engine. Here is a quick and dirty example:
class GameObject
{
public:
GameObject();
~GameObject();
bool usesPhysics(){ return m_body != 0;}
protected:
CCSprite* m_sprite;
b2Body* m_body;
};
You could then derive specific types of objects from the GameObject class
class Zombie : public GameObject
{
public:
Zombie();
~Zombie();
void EatBrains();
protected:
CCSprite* m_shadow;
}
There are many ways to structure your GameObjects. The example above is not dynamic. In my engine I wrap everything up into three or four component types. CocosBaseEntity for static sprites and optional physics body. CocosEntity is the same as CocosBaseEntity except it supports animated sprites. CocosMenuEntity contains either a graphical or text menu. Then I can mix and match what goes into my GameObjects even at runtime.
Should it inherit from CCTargetedTouchDelegate if I want it to be clickable?
Honestly I’ve never had to make anything clickable other than a menu. Maybe read the FAQ or look at the tests folder. My menus work using an abstract callback class which is then derived to a more specific callback which defines the action to take when the menu is clicked.
How do I manage the autoRelease stuff?
You should see the FAQ or this thread:
http://www.cocos2d-x.org/boards/6/topics/4621
I manage cleanup in the GameObject deconstructor.
Thanks for your example with the GameObject.
Just one more quesion about this.
How would you add your sprite, to the layer or scene? Do you have to pass the scene into the constructor and hold a reference to it in your class, then go m_sceneReference->addChild(m_sprite)?;
Sure, passing the scene to a GameObject is one way of doing it. I personally use a factory/blueprint pattern to build the Cocos components and my factory has a pointer to the scene. The GameObjects can then access the factory that created them if needed.
Thank you. your question is so cool. it is my code.
class Charater : public CCSprite, public CCTargetedTouchDelegate
{
>
CCSprite* m_pSprite; // sprite를 사용해서 file을 받는다.
>
public:
typedef enum
{
>
STANDING = 0,
RUNNING,
JUMPING,
DIED,
MAX_MOTION_TYPE
} MotionType; // Animation Type
>
typedef enum
{
>
// touch flag. It is same test tutorial Paddle.
TOUCH_GRABBED, .
TOUCH_UNGRABBED
} ControlState;
>
Charater();
virtual ~Charater();
>
>
// you must make a method for sprite create factory function like spriteWithFile or Texture
static Charater* charaterWithTexture(CCTexture2D* aTexture);
static Charater* charaterWithFile(const char *pszFileName);
bool initWithTexture(CCTexture2D* aTexture);
};
However. It has a lot of problem
also It has a lot of profit.
I think Kevin Hawkins code is so gooooooooood. more than my code.
my code is just one of reference.
Please think of using the following Component engine. The license is LGPL v3.
http://code.google.com/p/cistron/
Actually, I just started switching my code to using this engine after reading the post of Kevin Hawkins.
I haven’t tested the API above throughtly. Please let me know if this engine is useful.
Right now my current progress stuck on how to sync the position of Sprite component and Physics component.
Thanks for the cistron link. Looks good. You’ll need to register that the sprite component requires the physics component. Then the sprite component should be able to access the physics component each frame in order to get the position.
After researching cistron a little more it handles component communication through messages. If you have a game with a large many entities this can become a bottleneck.
“The problem with broadcast systems is that messages can become a bottleneck. If you have 1,000 NPCs moving, the movement controller of each of which is sending a”I moved" message, then 1,000 animations need to filter 1,000 “I moved” messages each just to get the right message. With pointers, you cut down N-squared to the optimal N. There’s also the question about how this object dies — everything needs to hear about “entity 1234 died” so it can remove itself from the world."
source: http://www.enchantedage.com/xna-world-entity-pattern
The alternative is for a component to grab pointers to all of its dependencies and access the dependencies directly instead of through messages. Just food for thought.
The description in http://code.google.com/p/cistron/ mentions the following statement.
“Cistron is designed as a light-weight, fast and flexible framework for use in environments where these frameworks are often not considered because of the overhead they cause through their message interactions. It does not depend on any libraries besides the C++ standard library, so it is easy to integrate in any project.”
I’ve checked the presentation from Karel Crombecq (The author of Cistron) for using Cistron
http://www.codeximperium.be/stuff/Component-based%20programming.pdf
The author mentions the pros/cons of using direct and indirect communication. Cistron implements indirect communication between components that use messages. Your approach is for direct communication that requires more dependencies between components. I suppose it works better for components that frequently update. The structure is similiar as follows.
class GameObject : Component
{
GraphicsComponent* graphics;
PhysicsComponent* physics;
...
}
class GraphicsComponent : Component
{
Component* parent;
CCSprite* sprite;
...
}
class PhysicsComponent : Component
{
Component* parent;
b2Body* body;
...
}
Both GraphicsComponent (CCActions) and PhysicsComponent (Physics) may affect the position of GameObject. The system should call back the “parent” GameObject for further actions when either one changes position.
For my game, I’ve finaly decided to make my BaseGameObject derive from CCNode.
Then I create the sprites i need and put it in that node from its class definition.
This way I can have an update scheduled e.t.c… And when the objects are scaled, rotated, or moved, all of the children that represent that object follow.
This seems to be working great for now. It has other advantages to.
Just about all objects that go on the scene derives from BaseGameObject, which derives from CCNode.