cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   vargonian
   Member

   Hi,

   I often find myself asking the question: Should my game object classes contain a sprite/sprites as a member, or should they inherit from CCSprite? I have a habit of always containing CCSprites as members, but I'm curious to know what I'd gain by inheriting from CCSprite. Obviously I could add my game objects directly to the scene, but then how would I deal with game objects that are composed of multiple sprites? I could add children to a root sprite, I suppose. I'm just curious to hear people's thoughts on these two different approaches.

   Thanks!

   Posted 2 years ago #
2. 

   MikeSz
   Member

   had same problem a few weeks ago and decided to go with... neither ;)

   my gameobjects inherit from CCNode and contain things like CCSprite, Box2d bodies etc

   you generally only move/rotate the CCNode and copy its position/rotation/scale to the sprite(s) on the update

   but frankly speaking - only reason I did it this way was because I couldnt subclass CCSprite

   Posted 2 years ago #
3. 

   Lam
   Member

   @MikeSz
   "only reason I did it this way was because I couldnt subclass CCSprite "

   Haha. Me too! Have you looked at that class! It's pretty complex that I won't dare inherit from it.

   Posted 2 years ago #
4. 

   MikeSz
   Member

   exactly :)

   and one other reason containing is often better than sublciassing CCSprite - you can freely use physics bodies without being any sprite. makes much more sense during prototyping

   Posted 2 years ago #
5. 

   David994A
   Member

   I too had this dilemma last week! I tried many things to subclass a CCSprite (one that is a child of a CCSpriteSheet) including trying to override the CCSprite creation methods in CCSpriteSheet but nothing worked so I ultimately created a new class that "has a" CCSprite.

   Posted 2 years ago #
6. 

   Blue Ether
   Member

   I also subclass CocosNodes and keep Sprites as properties. The reason for using a CocosNode instead of an NSObject is so I can schedule selectors using the director. Also, I frequently override methods like setVisible, setPosition, setOpacity, etc to pass the values through to the component Sprites. In this way, you can keep an object's component pieces together fairly easily even though they aren't children of the same parent. So, I can add an action such as FadeTo to the data object, and since the setOpacity method that FadeTo uses is overriden to pass the values on to the component pieces, its the same as adding that action to each of the components.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.