Advantage of Sub Classing a CCSprite

Question

I wanted to know more about sub classing a CCSprite and the advantage over just creating the CCSprite on init.

New to iOS dev and Cocos2d.

My game creates several CCSprites on init and clones some of them on touch/drag/collision

Looking for implantation on subclassing as well

UPDATE:

Also my Sprites have a text label as well as an audio file and a image file that differ from each sprite slightly. Example all the sprites have the same image but text and audio are different. And on collision the image file might change

Answer 1

When you should subclass CCSprite:

• almost never
• only when you have to change how the sprite displays itself (custom draw)

Sprites are in Cocoa terms "views". So are all other nodes. The thing is, a Sprite is an object that renders a texture on the screen. Subclassing makes sense if you want to change how the Sprite is drawn, perhaps by blending two textures into one, but adding masking functionality, by running different shader code, by adding custom OpenGL drawing.

If that's not clear, ask the same question again but about a different view class:

"What's the advantage of subclassing UIButton? When does it make sense?"

Answer: only if you need to change how the button displays itself.

You don't subclass UIButton to make it move over the screen or to make it perform an action on a text field. That's the job of a view controller. The view controller allows you to use the view verbatim, as it is, no subclassing. What you want is a view controller, not a subclass of CCSprite. It's been done way too often already.

Long story short:

Subclass CCSprite (etc) only when you can't make it perform the intended tasks through its public interface.

Changing position, rotation, scale, texture, sprite frame, etc. are all properties you can change from an outside class (controller). The same goes for animating the sprite, be it with CCAnimation or running actions.

If you use a controller object like it's customary in MVC design, you almost never need to subclass CCSprite or any other node class. What's more, with the userObject property you can store the controller object with the node, so it gets deallocated when the node is deallocated.

Of course both approaches work, and at the end it only boils down to whether one wants to use best practices, or bad practices.

Answer 2

Generally the standard practice is to subclass CCNode and add a CCSprite to it during the init. Basically it comes down to if you are actually adding functionality to a the base sprite class that you would reuse over all your sprites or if you are just creating say a Player object that has health and mana or something. There is some really good info about it in this question.

Should I subclass CCSprite, CCNode, or NSObject?

As for creating a lot of sprites and cloning them you should have a look at CCSpriteBatchNode. Batch nodes will draw all of the sprites that have the same texture in one draw call which can really help with performance. Also you can use a texture atlas to combine the textures of many sprites into one texture and batch the whole thing. There are some great tools that provide this functionality and I highly recommend Texture Packer or this.

Texture Packer is also great for reducing memory usage if you are creating a lot of sprites like you say. All textures are stored in memory in power of two dimensions, so if you have a sprite that is 130x130 it is actually stored in memory as a 256x256 uncompressed image. This can add a large amount of memory to an application. Texture Packer avoids this problem by storing all your images in one power of two texture, cocos2d can then pull out only the parts it needs for each sprite.

More info about all of this and a great tutorial on Texture Packer and batch nodes is here:

http://www.raywenderlich.com/2361/how-to-create-and-optimize-sprite-sheets-in-cocos2d-with-texture-packer-and-pixel-formats