Cocos2D Book Update: Progress Report

On May 29, 2011, in book, cocos2d, by Steffen Itterheim

It’s coming along great!

I completed the revisions on Chapter 1 through 5. The entire source code is now updated to use cocos2d-iphone v1.0.0 rc2. To make future code updates easier I also wrote a script that allows me to copy a newer cocos2d version to all projects, which essentially does Steps 1 & 2 described in the Updating Cocos2D in an Existing Project tutorial.

Most Notable Changes

Chapter 4 now includes a description of Glyph Designer for making Bitmap Fonts, and only mentions Hiero on the side. Glyph Designer is the better tool hands down.

Chapter 5 has seen a revision of the paragraph that explains subclassing from NSObject. I think I went too far off course here and subclassing from CCNode will make a lot of things easier while still giving the same benefits regarding class composition.

In Chapter 6 I decided to replace all descriptions of Zwoptex with TexturePacker as the preferred tool for making texture atlases.

For a while it looked like Zwoptex and TexturePacker would be competing on the same level. But recently Andreas Löw (TexturePacker & PhysicsEditor) made the move to work full-time on his tools, whereas Robert Payne is busy with a full-time job. I think the prospects are looking much better for TexturePacker now, and it is already leading in terms of features and update frequency.

That’s it for now.

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.

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.

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. :)

cocos2d Book, Chapter 6: Spritesheets & Zwoptex

On July 30, 2010, in Announcements, book, cocos2d, by Steffen Itterheim

Chapter 6 - Spritesheets and Zwoptex

In this chapter the focus will be on Spritesheets (Texture Atlas), what they are and when, where and why to use them. Of course a chapter about Spritesheets wouldn’t be complete without introducing the Zwoptex tool. The graphics added in this chapter will then be used for the game created in the following chapter.

The chapter will be submitted on Friday, August 6th.

Anything about Spritesheets you always wanted to know?

Just let me know. I’ll be researching what kind of issues people were and are having regarding Spritesheets. I want to make sure that they are all covered in the book.

Please leave a comment or write me an email.

Summary of working on Chapter 5 - Game Building Blocks

I finally found a better title for the chapter. A big part is about working with Scenes and Layers. A LoadingScene class is implemented to avoid the memory overlap when transitioning between two scenes. Layers are used to modify the game objects seperately from the static UI. I explain how to use targeted touch handlers to handle touch input for each individual layer, either swallowing touches or not.

The issue of whether to subclass CCSprite or not is discussed and an example is given how to create game objects using composition and without subclassing from CCNode and how that changes touch input and scheduling.

At the end the remaining specialized CCNode classes such as CCProgressTimer, CCParallaxNode and the CCRibbon class with the CCMotionStreak are given a treatment.

As you can see from the pictures, I’m also making good progress at becoming a great pixel artist. Only I have a looooooong way ahead of me still. But I admit, the little I know about art and how much less I’ve practiced it, I’m pretty happy about the results and having fun with it. The cool aspect of it is that this should be instructive art. It doesn’t have to be good. So I just go ahead and do it and tend to be positively surprised by the results. I’ll probably touch this subject in the next chapter about Spritesheets: doing your own art. It’s better than nothing, it’s still creative work even if it may be ugly to others, and it’s a lot more satisfying to do everything yourself, even if it takes a bit longer and doesn’t look as good. At least it’s all yours, you’re having fun, and learn something along the way. And you can always find an artist sometime later who will just draw over your existing images or who replaces your fart sound effects with something more appropriate.

Btw, if you’re looking for a decent and free image editing program for the Mac, I’ve been using Seashore for about a year now and I’m pretty happy with it.