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.