Learn & Master Cocos2D Game Development

Linkvent Calendar, Day 3: MVC with Cocos2D

On December 3, 2010, in Cocos2D Linkvent Calendar, by Steffen Itterheim

Today’s link is about the Model-View-Controller (MVC) design pattern and how to implement it in Cocos2D. Bartek Wilczyński from Poland has written a two-part tutorial about how to implement this design pattern, and explains why this is a good design choice:

How to implement MVC pattern in Cocos2D game – Part 1
How to implement MVC pattern in Cocos2D game – Part 2

While I was reading that, I remembered that Jeremy Flores had created a github repository with his implementation of a MVC pattern in Cocos2D. He dubbed his project Cocos2D-MNC, as in Model-Node-Controller. The code is published under the MIT license.

The MVC pattern is somewhat similar to a game object component system that I described here. For both systems, the general idea is not to subclass CCSprite and put your game logic in there. CCSprite already is a complete visual representation class for your player, enemy, and what not. But in some cases, you need more than one sprite, or a combination of a sprite and particle effects. Once you get there, it’s much better to have a CCNode containing (aggregating) all the visual elements of your game object, while handling all the game logic of that object and updating the visual elements. The CCNode becomes the controller, controlling the views. As the views (sprites, effects, GL drawings, etc.) move on screen, the controller node polls the visual nodes for state information and runs the game logic code, which in turn may update the views.

In very simple terms, this is my pragmatic approach of the MVC pattern that also works quite well. It’s definitely already a big leap forward compared to extensively subclassing the CCSprite class. If you notice that you’re doing that a lot, you should do yourself a favor and read up on the MVC design pattern.

Add your link to the Cocos2D Linkvent Calendar

Do you have something to share with the Cocos2D community? I haven’t received enough submissions to fill all the days until Xmas, although I do have enough links to post one each day, I’d rather post a link to your website or blog post.

Cocos2D Xcode Project on Github

On November 4, 2010, in cocos2d, tools, Xcode, by Steffen Itterheim

My Cocos2D Xcode project is now on Github. Open-source, free, properly MIT Licensed, includes the rootViewController and supports Cocos2D v0.99.5 rc0.

I’m also working on (with) a greatly enhanced version of the Xcode project. It integrates wax (Lua) and a Game Object Component System that i termed “gocos”. Also comes with a lot more useful convenience classes.

But the big idea is to actually upload (or link within github, if I can figure out if and how that works) all dependent projects into one repository, so that you can download everything at once and it works out of the box. Currently there are 3 projects referenced by cocos2d-project: gocos (let’s call it a library of convenience and gameplay code for Cocos2D), wax (Lua support) and obviously cocos2d-iphone. So everything that’s needed is going to be bundled in one big package, which voids all of the version incompatibility issues.

You can still experiment with different versions of these libraries but in that case I think you know what you’re doing and that issues are to be expected. But being a github repository, you can of course clone and commit changes.

Appetizer

Here’s what I’ve done with Lua. I’m currently using it only as a better plist replacement for settings. It’s better than plist because you can comment on each item, you can sort them easily, you can run functions and algorithms to generate values or load additional data, and in general it’s a lot easier to work with than the plist editor. Here’s a reduced config.lua that is loaded at runtime into a hierarchy of NSDictionary objects:

local config =
{
AccelerometerControls =
{
UpdatesPerSecond = 60, -- 60 Hz
Responsiveness = 0.997,
SensitivityX = -2,
SensitivityY = 2,
MaxVelocity = 100,
},
}

return config

And this line of code loads these values and assigns them to the correspondingly named properties of the target class:

[Config loadPropertiesFromKeyPath:@"AccelerometerControls" target:self];

That’s all you need to do to transfer the values from config.lua into a class instance. Huge timesaver! The only drawback is that it currently can’t differentiate between float, int and bool (due to NSNumber), so it currently only supports float properties.

Tagged with: App • appetizer • cocos2d • cocos2d-iphone • component • component system • convenience • game object • github • Lua • NSNumber • open source • repository • Wax • Xcode

Back from the devs

On October 5, 2010, in Announcements, by Steffen Itterheim

I’m back from Macoun, and it was nice meeting you all! Well, actually since that conference was just a 90 minute ride away, so I wasn’t really gone, except mentally. I spent a lot of time last week to prepare my presentation (in german), and fighting a cold. The subject was a game component system that I wrote on top of cocos2d, to encapsulate most of the cocos2d CCNode stuff and allowing me to focus on writing re-usable gameplay components. The system works but it’s not production tested. Still it’s proven very promising from my initial tests and opens some interesting opportunities, for example the re-use of components is a huge timesaver, and you can totally get rid of any class hierarchy and remain flexible throughout development. Due to writing the book and other things I hadn’t had the time to develop it as much as I wanted to. I’ll release it eventually but for the moment, I have a different focus.

For one, I’m late with the Game Center chapter due to the Macoun conference preparations, an upcoming wedding and an apartment renovation of the soon-to-be-wed as their wedding gift. So I’ll try to cram writing both the Game Center chapter and the final chapter in this week, before turning my attention to updating the Line-Drawing Starterkit and Xcode project. I did not intend to support non-beta versions of cocos2d, but given how long the recent betas last and how many developers actually use the latest beta (probably due to HD support) and how significant the breaking changes are this time, I’m going to update the starterkit and Xcode project with HD support while keeping the old project for those who would rather use the stable 0.99.4 version of cocos2d. Once that’s done, it’ll be mid of October and another project, only partly concerning cocos2d, kicks in full speed. No time to lose.

Speaking of the Starterkit, September went by and I made 10 sales, without advertising it or anything, so those numbers are at the lower end of the “potential sales” spectrum. That’s a sum (over $1,500) that I can live with. Well, actually, that’s a sum that I can live off of. On a related matter, I recently found a page detailling the traffic stats of the cocos2d-iphone.org website. If those stats are correct, the unique visits are over ten times that of my site. Now, frankly speaking, every time I get those little facts and stats from here and there over the past couple months, and then added up the numbers, compared them with mine, applied reasonably pessimistic estimations and caution, I do wonder: why the hell isn’t cocos2d run like a business?

If you ask me, with those traffic stats and a reasonable conversion rate of 0.1% per unique visitor (mine is over 0.2%), one could easily pay 3 people to develop cocos2d, test it, write documentation, moderate the forum, and in general adding more business value. Which in turn grows the business, speeds up the development of the engine, tools and by-products and will make everyone benefit from that. I don’t get it. Because at this point, it’s either going to be that, or a slow decline to a niche product over the next couple years due to the increasingly strong competition from other iOS engines. Especially those that offer cross-platform support, since that’s what contractors are asking for, or even demanding, more and more.

Anyhow, for my part, I decided that now would be a good time to start doing the Indie thing full-time, still accepting contract work but I’m able to be a lot pickier about it. I have a goal set out for myself, and it’s not a simple one. I’ve always enjoyed most to help my colleagues, to fix their problems, to support them and in general, to help them achieve excellence. I know, that sounds like something you’d find in EA’s job matrix – and in fact, you do. Helping others achieve excellence, throughout my professional career, that’s what I’ve been doing and enjoying the most. Now I find myself doing that for cocos2d developers, enjoying it and being able to support myself in the process. Well, I think I’ll have to thank you, my dear readers, for that.

As a thank you back, I’ve started working on a bigger project about 3 months ago that will be useful and helpful to many indie game developers, regardless of the engine you may be using. Hence it deserves its own website and a cool name (darn, that is hard!). I’m looking forward to really getting into high gear with it after I’ve submitted the remaining book chapters. Stay tuned.

Tagged with: business • cocos2d-iphone • Competition • component system • Components • composition • contract work • contractor • documentation • indie • inheritance • line-drawing • macoun • niche • presentation • starterkit • website

cocos2d Book, Chapter 9: Particle Effects

On August 21, 2010, in Announcements, book, cocos2d, by Steffen Itterheim

Chapter 9 – Particle Effects

Those tiny specks which you can see on your touchscreen after a sneeze.

Not exactly. Of course I mean the cocos2d particle system and its built-in particle effects which will be the focus of this chapter. And no discussion of particles would be complete without describing the workflow revolving around the Particle Designer tool.

Summary of working on Chapter 8 – Shoot ‘em Up

This certainly wasn’t the easiest chapter for me to write. I had very ambitious goals, maybe too ambitious for 27 pages. I did manage to sneak in quite a lot though, here’s a partial list:

how to refactor existing code to make it work better with the new features
how to pool bullets and enemies together for easier access and better performance
how to not use too many subclasses, instead relying on type switches
how to use cocos2d’s node hierarchy as a simple component system for writing reusable game logic components
how to implement basic movement, shooting and a healthbar as components
how to detect collisions between bullets and enemies

The not so easy part was striking the right balance. Not going too technical. Not doing too much at once. Not dividing things into too many tiny pieces. But most of all I frequently encountered various bugs in the code, or just unexpected behavior of cocos2d which forced me to spend more time debugging and sometimes backtracking changes than I was prepared for.

After a long and hard work week, paired with physical exhaustion and an late-summer allergy burst, my concentration didn’t allow me to work at 100% capacity. In the end I did manage but it took longer than I had planned, I’m over a day late to submit this chapter. The next one will be easier though, and it has to be as I’m preparing for a short trip near the end of next week. I certainly am looking forward to a couple days off now.

Tagged with: apress • Chapter • cocos2d • collision • collisions • component • component system • Components • composition • Designer • enemies • healthbar • hierarchy • inheritance • movement • Particle • particle effects • shooting

Prefer Composition over Inheritance

On June 11, 2010, in Programming, Speaking From Experience, by Steffen Itterheim

When the question came up whether to subclass CCSprite or use some model class to build your game entity hierarchy in the cocos2d forum, i stressed that one should try not to use inheritance and keep the inheritance hierarchy to as few levels as possible. I’ve worked with codebases with hundreds of thousands of lines of code, and hundreds of different types of actors in the world. Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

The answer lies in composition, often referred to as Game Components by engines like TorqueX and the PushButton Engine (a Flash game engine from the original Torque developers). This video from the PushButton lead developer Ben Garney explains it very well and also illustrates the problem with inheritance over-use in game engines. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use – i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

You can read more about PushButton’s Components system in their documentation. How they implemented Components in TorqueX and what the differences are to XNA Game Components further enhances understanding of the concept.

For further reading and arguments read the Wikipedia article on component based software engineering. As a matter of fact, the Objective-C language was invented to be able to create re-usable software components!

Scott Bilas’ GDC 2002 talk about A Data-Driven Game Object System (PDF) as used by Dungeon Siege contains more pointers on why inheritance fails for game developers and what the advantages (but also some caveats) are with component-based game engines. The talk may be old but it’s still as valid today as it was back then. In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

During GDC 2009 a similar presentation was held by Radical Entertainment’s Marcin Chady. The talk was called Theory and Practice of Game Object Component Architecture (PPT).

Mick West wrote an article Refactoring Game Entities with Components which describes the challenges and benefits of changing the Tony Hawk codebase from an inheritance model to a game component system.

A somewhat more advanced read on component use is a collaborative paper called Dynamic Game Object Component System for Mutable Behavior Characters which talks about components in context of finite state machines and NPC behaviors with a rule-based activation system.

The Game Architect blog calls it an Anatomy of Despair and sums up very good what the cons of inheritance-based class design is and how composition solves them.