Tuesday, July 24, 2012

Zissou2d Part 1: An overview











In this post I'm going to talk about how Cocos2d works in general,  and I'm also going to try to translate that into our project. I'm going to look at these concepts and see how we can integrate them by using GLKit.

One thing that helped me while going through the documentation of Cocos2d is that I had already used an animation software when I was younger (I was one of those kids making stick figure deaths). If you've ever used Abobe (Previously Macromedia) Flash to animate or try to make a game, these concepts will be very familiar to you.

To animate something in any animation software, you first need a single image, or a collection of images. In Cocos2d, the object that loads these images (or textures) are called sprites. These sprites can load a texture atlas containing a collection of graphic objects to be animated. These sprites are responsible for drawing themselves because they have all the information to actually put something on the screen.

Just like in Flash, these sprites, or objects, can then be placed on a scene. Cocos2d also has scene objects. The scene is also responsible for drawing itself, but will actually ask for each sprite it contains to draw itself when needed.

Another important concept are layers. Flash, Cocos2d and Photoshop all have them. Layers are there so that you can group sprites together. One of the reasons you might want to do that is for ordering. You might want to have a layer which only contains background objects. This layer will be drawn first when the scene has to draw itself so that it doesn't hide anything important in the foreground.

Last but not least is the object that controls the scenes. This object is responsible for showing the right scene at the right moment. In Cocos2d, this object is called the Director, which kind of makes sense. There is usually only one director when you're animating something, and that also makes a lot of sense.

Here's a nice little screenshot of the Adobe Flash UI to illustrate the analogy:

Adobe Flash

Now how does all this translate into code?

Well, in CC, the CCDirector class has access to a view where everything (OpenGL stuff) is drawn. This class is a singleton and can be accessed from anywhere to push scenes to display.

In our case, we want to use the GLKView and the GLKViewController. The GLKView is where everything is drawn. The GLKViewController which is attached to the view sets itself as the view's delegate, and you then have to define a drawInRect method where you write the code defining what should be drawn. What we can do is subclass the GLKViewController and make it our director. Let's call that controller Steve for our API. If I make a little recap of what Steve can do:
  • It can be accessed from anywhere in the code
  • We want it to be accessible to push scenes  to be displayed
  • It holds the context and the view where we do the drawing
  • Once it has a scene to display, it asks that scene to draw itself (The scene will then go through each layer and ask the sprites to draw themselves)

Now, there are other things the Director should do, but those other things already come with the GLKViewController:
  • Setting the desired frame rate for the animation
  • Define an Update method where we can update our models, or sprites, on every frame (position, health, etc)
  • Pause/Start the animation
  • Provide a time since last update so that the animation doesn't depend on the processing speed

In the next post, I'll start coding our director (Steve) and I'll start talking about scenes, layers and sprites in more details.

No comments: