Wouldn’t it be awesome if you could update your game’s assets while your app is running? It turns out you can, and it’s not even very complicated.

Whether you want to tweak a game setting or experiment with a variety of image styles on the fly, this will be one of the things you wish you had been using all along! Either for faster development or as a design feature for your game.

In this case, we’ll build a New York Traffic Webcam viewer with Cocos2D. You will learn how to download files to your app at runtime with the iOS SDK and cocos2d-iphone, and how to check if the file on the web server has actually been modified.

Along the way you’ll understand how to use the Mac OS X built-in web server to speed up your development by replacing game assets on the fly. By copying files to a specific directory on your Mac you can make immediate changes to your running app!

And you don’t need any experience with HTML, Apache, or any other web server or web services technology. In fact, I consider myself to be an web-illiterate because I’ve hardly done anything programming-related with web services and servers in the past.

As usual, the project is available from my LearnCocos2D github repository under the MIT License. The project’s name is Cocos2D-UpdateFilesFromWebServer. To improve readability of the article I removed error checking from the code in the article.

Continue reading »

In Depth iOS & Cocos2D Performance Analysis with Test Project

On November 17, 2011, in idevblogaday, by Steffen Itterheim

I took Mike Ash’s performance measuring code from 2008 with the improvements made by Stuart Carnie in early 2010 and turned that into a performance measuring project for 2012.

I know it’s still 2011, consider this a forward-looking statement. In any case, the test project is available for download, ready to run, includes Cocos2D v1.0.1 and is relatively easy to modify for your own needs. This project is also available on my github repository where I host all of the iDevBlogADay source code.

Since numbers are so dry and hard to assess, you’ll find the rest of this post garnered with charts and conclusions based on the results obtained from iPhone 3G, iPod 4 and iPad.

Continue reading »

Cocos2D Sprite-Batch Performance Test

On September 8, 2011, in cocos2d, idevblogaday, Kobold2D, by Steffen Itterheim

While writing the Learn Cocos2D book I was surprised to find that Cocos2D’s CCSpriteBatchNode was only able to increase the performance of several hundred bullet sprites on screen by about 10-15% (20 to 22.5 fps). I wanted to re-visit that scenario for a long time because as far as I understood, the more sprites I was drawing the greater the impact of CCSpriteBatchNode should be.

But even Cocos2D’s own sprite performance tests (compare columns 9 and 10) revealed a performance difference of under 20% (39 to 42 fps). It’s only when all sprites are scaled and rotated, or most of them are outside the screen area, that sprite batching seems to have a bigger impact (25 to 60 fps). Surely that scenario is not applicable to most games. So I started investigating.

Continue reading »

A helpful CCSprite code gem …

On January 14, 2011, in cocos2d, Programming, by Steffen Itterheim

I often start out with new code using dummy graphics. Until I figure out what exactly I need and what is going to work, I work with single image files added to the project’s resources. Creating a texture atlas is always the last step I do, once everything is settled. Creating and updating a Texture Atlas adds just a few extra steps but I always strive to avoid any unnecessary extra steps during a creative working period. Especially while experimenting. Any repetitive task hampers creativity.

But eventually, I will have to go in and change every CCSprite initialization code from spriteWithFile to spriteWithSpriteFrameName. Except, I don’t.

The following is a simple extension category for CCSprite that extends CCSprite with a spriteWithSpriteFrameNameOrFile initializer. It looks for the given file name in the CCSpriteFrameCache. If it exists as CCSpriteFrame, it uses that sprite frame and otherwise it reverts back to loading the sprite from file. Very easy, very helpful.

// CCSpriteExtensions.h

#import "cocos2d.h"

@interface CCSprite (Xtensions)
+(id) spriteWithSpriteFrameNameOrFile:(NSString*)nameOrFile;

// CCSpriteExtensions.m
#import "CCSpriteExtensions.h"

@implementation CCSprite (Xtensions)
+(id) spriteWithSpriteFrameNameOrFile:(NSString*)nameOrFile
  CCSpriteFrame* spriteFrame = [[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:nameOrFile];
  if (spriteFrame)
    return [CCSprite spriteWithSpriteFrame:spriteFrame];
  return [CCSprite spriteWithFile:nameOrFile];

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 Book, Chapter 7: Side-Scrolling Shooter

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

Chapter 7 – Side-Scrolling Shooter

The shooter game will be controlled with a virtual joystick using SneakyInput. The background parallax scrolling will be implemented not with the CCParallaxLayer, as it does not support endless scrolling (as far as I know, please correct me if I’m wrong). The rest will be gameplay code, mostly spawning enemies, moving them and collision tests.

The chapter will be submitted on Friday, August 13th. Yup, Friday the 13th. Scary.

Summary of working on Chapter 6 – Sprites In-Depth

I decided to rename this chapter to Sprites In-Depth as it deals mostly with Sprites, Sprite Batching (formerly known as Sprite Sheets), Texture Atlases and Zwoptex as well as general texture memory management. All the while laying the foundation for the game to be made in Chapter 7.

While working on this chapter I noticed that it’s awfully complex to create a CCAnimation class, especially if you’re not using a Texture Atlas. So I decided to illustrate how to add helper methods by adding them via a Objective-C Category to the CCAnimation class. Now you can create a CCAnimation with just one line of code, instead of around ten.

Once more I created some of my now famous doodle artworks. If anything this should show that even a programmer can do art. Or, well, at least something that vaguely resembles art.

I was a bit surprised by one thing though, and that is how little the use of the CCSpriteBatchNode contributed to the framerate in this particular case. I added all the bullets to a CCSpriteBatchNode and found only a 15% increase in performance, it went up from 45 fps to a little over 50 with all those bullets flying. I sort of expected a bigger impact from previous experiences.

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.

cocos2d Book, Chapter 4: First Simple Game

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

Chapter 4 – First Simple Game

After Chapter 3 covered the fundamentals of the cocos2d game engine, this chapter will put to use what you’ve learned. The simple game is all about droping enemies that you have to avoid via accelerometer controls. Sort of like an inverse Doodle Jump. But it’s not just about the gameplay itself, I want the game to be reasonably complete with a main menu, scene transitions, game over and of course audio.

The chapter will be submitted on Friday, July 23rd.

Do you have any suggestions for the game?

What do you think should be in a first cocos2d game? Let me know!

Summary of working on Chapter 3 – Essentials

When I started the chapter I wasn’t really sure about its focus and progress was a little slow. Eventually it clicked and I found myself ending up having written more pages than needed and still having a great number of things left untold. The key was looking at the cocos2d API reference documentation and remembering what it was like when I was a beginner. Sure, every class, method and property is there but for a beginning cocos2d developer the API reference is just a huge list of names. In other words, if your experience was or is anything like mine was, it’s frustrating to work with the API reference.

I ended up writing about the cocos2d engine design and its scene graph first, the remaining 80% of the chapter explain in detail with lots of code samples how to use those darn CCNode classes. All the important ones are covered: CCNode, CCScene, CCLayer, CCSprite, CCLabel, CCMenu, CCMenuItem* as well as the Director, Transitions and Actions. Besides the code samples and how-to I’ve added numerous caveats, common mistakes, best practices and other nodes which are so very much needed to make any documentation complete.

For example, how Layers are best used for grouping other nodes together and of course how to enable touch and accelerometer input by adding the required functions which aren’t mentioned in the API reference since they are part of the iPhone SDK API. There’s also some weird recommendation floating around not to use too many Layers because they’re slow. I can’t find the source but what I did find was that this is only true if the Layers enable touch or accelerometer input, because that’s what costs a lot of performance. So what you don’t want to have is several layers accepting input, otherwise use as many Layers as you need – which shouldn’t be many anyway. And if you do need multiple Layers accepting input, why not just use one master Layer (possibly using a Targeted Touch handler) which forwards the input events appropriately to the other Layers?

Page 1 of 212