CocosSharp – The Building Blocks

This post is part of my Mobile Game Development series. Start at the beginning to catch up. This series was inspired by the things I learned developing a new game for Android and iOS called Mirror Maze.

Let’s talk about some of the elements that make up the building blocks of your CocosSharp game: CCNode, CCScene, and CCLayer. All of your elements will either be one of these types or will derive from one of them.

CCNode is the base class for all things visual. It provides a ton of functionality out of the box and you can instantiate one directly, if you want. All the other types ultimately derive from CCNode. There’s a lot to understand about CCNode, but I want to cover a couple of other key things first, so we’ll come back to this one shortly.

CCScene is the root element of what you see on the screen. A Scene is a logical collection of functionality in your application. You can have as many scenes as you want in your application, but only one will ever be showing at a time. Well, technically you can have CCScenes stacked up, but that’s really frowned upon because hidden scenes will consume resources and potentially slow your game down. CCGameView has a Director which controls which CCScene is currently being displayed. You can supposedly transition from one scene to another with a nice fade, or some other such transition. However, I was never able to make that work and treated it as essentially a hard cut from one scene to the next. In Mirror Maze, I have a MenuScene and a GameScene. The MenuScene handles displaying the game options and letting the user select which maze to start with. The GameScene does everything related to the actual game play.

The next element in the hierarchy is CCLayer. CCLayer essentially represents the concept of a layer. Your app can have as many layers as you want, but each scene needs at least one. The layer itself isn’t a visible element. Think of it more like a clear surface that you can place things on. The things you place on it are visible, but the layer itself is not. Layers can be handy for grouping things that you want to show/hide or move as a group.

Now, let’s say that you want to add a layer, but you want that layer to have a solid color background instead of being clear. CCLayerColor is your buddy. You can select a predefined color from the CCColor4B static properties, or you can create your own with RGBA values. Placing a CCLayerColor instance on top will cover up everything beneath it.

Ok, let’s get back to talking about CCNode. CCNodes aren’t visible in and of themselves, but they can contain children which are visible. What CCNodes DO provide are the ability to be positioned, scaled, and rotated. CCNodes have an inherent ContentSize (how wide and tall the contents of the node are) which, coupled with position, can give you the BoundingBox of the node. Think of the BoundingBox as the footprint of the node. The BoundingBox is a bit of an animal itself, so I’m planning to write up a post specifically to help understand just that.

While it’s totally acceptable to instantiate a CCNode instance and put it to use, you’re more likely going to either use one of the child types provided out of the box or create your own classes that inherit from CCNode and provide your own functionality.

In the next few posts, I’ll dive into some of these child types and implementing your own node types.