Creating Games with Cocos2d for iPhone 2
Feb 21, 2013—
A Little Bit About Me
I’ve been a Mac developer for well over 10 years now, and while I’ve mostly been creating applications I have always had a fondness for games as a hobby. Over the years I’ve created several games in several different languages, different APIs and frameworks, and a few game engines along the way. With all of that experience, you’d think I’d have used the most popular game development framework for the most popular Apple platform for the past several years, but somehow I’ve yet to find the time, which is why I was excited to finally sit down and learn more about Cocos2d by reviewing the book Creating Games with cocos2d for iPhone 2 by Paul Nygard.
Who this Book is For
I think in my excitement to start reading the book I overlooked one small detail. Having no hands-on experience with cocos2d I was expecting a book to take me from complete novice to confidently competent, but then I saw this little gem:
“This book is written for people who have basic experience with cocos2d, but want some guidance on how to approach real-world design issues. Although the book does revisit some basic concepts, we hit the ground running, so having a basic understanding of cocos2d is recommended. At least some knowledge of Objective-C is also strongly recommended.”
After reading that prior experience was needed, I admit I was a bit intimidated but I dived straight in anyway. Luckily, I soon found out that although Nygard does not hand hold the reader, explaining everything in detail about the class organization of cocos2d, it was very easy for me to follow along, and nothing cocos2d-specific tripped me up. While a complete beginner to game programming might not have the terminology and concepts down (what a sprite is, a spritesheet, the idea of a hierarchal connection of nodes, etc) anyone who is already familiar with them in any other framework or a general sense, should have no problem with the book.
One of the reasons I was interested in this particular book versus many of the others available on cocos2d, is that it approached the subject by taking the reader through the process of creating nine different games. Instead of laying out an agenda that goes through each class in the cocos2d package and teaching you how to use it, this book takes the practical approach of choosing a game, and then walking through everything needed to create it.
The nine games created in the game are:
- A basic card matching game
- Bejeweled clone
- Brickout clone
- A Tron-like Lightcycle game
- A top-down shooter
- A 2d sidescrolling endless runner
Each game was chosen well, as they get progressively more complex and cover a variety of game genres. The first game is very basic: a grid of cards are face down, and you flip any two at a time to make a match until all are found or you run out of chances. While the game itself is certainly not going to win any awards, it does teach the reader the fundamental concepts which are then used to make a Bejeweled clone in chapter 2.
In the third chapter, while creating the Whack-A-Mole-style game, the reader is first introduced to using the
update: method called for each frame of the game. While the first two games were event-based, responding only to user input, the Whack-A-Mole game needs to always be spawning and moving new moles. The game is simple, but focuses on that core concept, which is then expanded on in Snake.
Later on the use of
update: and physics are combined in the Brickout game. Here the reader is first introduce to Box2D, a 2D physics library that is used to provide realistic Newtonian movement as well as collision detection and response. A Brickout game is a perfect introduction to using real physics, and sets up the reader nicely for the Billiards game later on.
The shooter game has two control modes: one uses the device’s tilt capabilities to move around, and the other uses a touch joystick for the left thumb. Including a game using these two mechanisms is a solid addition to the book, since these are popular control schemes, and getting a handle on using the acclerometers can be a bit tricky.
The content of the book, as far as the games that are created and the overall approach to them, is good, and is what I expected, but the book is not without its flaws. During my reading, several things kept bothering me and I think they mostly stem from the fact that this is Paul Nygard’s first book.
First, I was confused on who the audience for this book is, and I think it even shows right in the Preface. The Preface remarks that the reader should have basic cocos2d experience, and that “at least some” knowledge of Obj-C is recommended, but apparently is not required. However to have experience with cocos2d, you must have already been using Obj-C in the first place. Sporadically throughout the book, Nygard attempts to handhold the reader explaining basic concepts such as memory management, Objective-C syntax, the use of @
#import, and even fundamental concepts such as instance variables. The explanations themselves are brief and therefore vague and not very useful, so any reader not familiar with these concepts already will be lost very quickly. It’s puzzling to me that these little “time outs” to explain a concept are scattered throughout the book.
The second major critique I have, is that of technical prowess. Every programmer has their own code style and practices, and there have been countless debates on which is best. The issue I have with this book is not really about picking the “right” style, but about picking a style and using it consistently. For example:
- Most instance variables do not use an underscore prefix, but many do without any discernable pattern.
- The spacing in method signatures and calls varies throughout the code.
- Sporadic use of dot syntax with no pattern. (Used in exactly one spot in the first 100 pages, for example.)
- Inconsistently follows widely-practiced conventions. For example, class factory methods should start with the type name itself.
Although in the above cases it obviously doesn’t affect how the code runs, in other cases there are potential problems:
- An instance variable named “size” in a CCLayer subclass to refer to the CCDirector’s winSize, when it could easily later conflict with any other local variable named size.
[object performSelector:withObject]for no apparent reason except to avoid having to add an #import. If the method in the called object was later renamed, compiling would produce no errors.
Additonally, there are structural decisions in a few places where I feel the alternate choice would have resulted in smaller simpler and cleaner code. For example, in Chapter 3, using a two dimensional array would have simplified a lot of code where multiple nested loops were involved. Oddly, there was one spot where Nygard agreed and created a temporary 2d array for one method, but I’m not sure why he didn’t go all in and use it everywhere to save himself and the readers from trying to understand a series of more-complicated-than-necessary nested loops.
“…a good read for any novice game developer.”
Each of the games created in this book are not all that complicated to create, if you already know how to do it. One of things that experience gives you in game development (and in any programming, really) is the ability to “see behind the curtain” intuitively, and know how a game might work.
It’s a bit like watching a magic show: If you’ve never seen how the tricks use slight of hand, distraction, and purposefully mislead the audience, you can’t comprehend how the illusion is peformed. However, once you’ve seen enough “behind the scenes” shows exposing how each trick is performed, soon enough when you see new tricks you can quickly get an idea of how the illusion works, realizing there’s simple a body double in a hidden compartment. What this book does, by covering each of these games is provide the reader with those “aha!” moments, so that they have a good foundation to go on and create other games using the practical techniques learned.
“In game programming, there are always many ways to solve the same problem, there is no single right answer.” – Paul Nygard
In this, the author is correct. Although there are some technical issues with the book, overall it’s a good read for any novice game developer. While a refactored second edition would be a better read (and annoy people like myself less), fundamentally all of the content is sound, useful, and accomplishes exactly what I expected it to.
About the Author
Seth Willits has been a member of iDevGames since 2002, and is now the “Cmd-R In Chief” running the website. He is a full time Objective-C developer creating applications for Mac OS X, creating games here and there in his spare time.