Learn Cocos2D 2nd Edition: What’s New & Release Date

On September 30, 2011, in book, cocos2d, Kobold2D, by Steffen Itterheim

Scheduled for release on November 7th, 2011.

Tagged with: actions • Andreas Löw • apress • beginner • best practices • book • CCDirector • cocos2d • cocos3d • developer • development • edition • Essentials • game development • Glyph Designer • Introduction • kobold2d • learn • Particle • particle designer • physics • PhysicsEditor • pinball • release date • Retina • scene • source code • TexturePacker • uikit • upgrade • Xcode

The Complete (?) List Of Cocos2D Tools

On June 24, 2011, in book, cocos2d, tools, by Steffen Itterheim

For the second edition of the Learn Cocos2D book I compiled an alphabetically sorted list of tools that developers can use for cocos2d projects. Please let me know if there’s a tool missing from this list or if there’s one that won’t work anymore and hasn’t been updated in months.

The following tools can be used for development with cocos2d:

Building The Ultimate Cocos2D Project

On February 25, 2011, in Kobold2D, by Steffen Itterheim

The Ultimate Cocos2D Project is: Kobold2D!

Put simply: Kobold2D is designed to make Cocos2D developers more productive.

Original Post

First Friday update after the teaser post. I’m working on a new project. I’m still fleshing out the details of the “killer-feature” and making tests, so I can’t really talk about that. But I can tell you what I have already up and running.

The Ancestor: cocos2d-project

You may remember the Xcode Cocos2D project tutorial I wrote almost a year ago. The goal of that was to use Cocos2D as an external library in order to be able to update Cocos2D simply by pulling a new version from git, or just by replacing the Cocos2D folder. I gave the resulting project a boring, uninteresting, generic name (so typical for a programmer): cocos2d-project.

The new and improved cocos2d-project not only has a spiffy name (to be announced) but also raises the bar not one but two or maybe even three levels, depending on perceived value. It’s definitely leaps and bounds ahead of the Cocos2D distribution project, especially if you care for how source code projects should be composed.

One Xcode project for both iOS & Mac OS X Targets

One thing that really bothered me when Cocos2D became capable to build Mac OS X applications was that it required a separate Xcode project for each platform. If you’ve ever done cross-platform development you know this isn’t going to make you happy. Every action needs to be done twice, add a resource in one project, then you must also add it in the other. Change a build setting in one project, also change it in the other. Build and run in one project, then build and run the other project with a completely different window layout and probably duplicating all the floating windows aka “Is that the Mac OS debugger or is it the one for the iOS project?”. You name it.

I did some research, then a test, and It turns out: it’s entirely possible to target both the Mac OS X and iOS platform from within the same Xcode project. It works like a charm!

Really the only thing you need to keep in mind is that Xcode doesn’t give you the option to change the Active SDK by default. But if you click the Overview dropdown while holding down the Option key, you can select any SDK that’s installed on your system (see the image). The key here is to first change the Active Target to the Mac target, then Option-Click again and select Mac OS X 10.6 as the Active SDK. And the other way around to change back to iOS. So it’s a two step process but still way more comfortable than managing two seperate Xcode projects.

XCConfig Build Configuration

Behind the scenes there’s an additional step required to make this work, which I’ve been wanting to do for a long time: to use XCConfig files for build settings. Cocoaphony has a blog post Abandoning the Build Panel describing the technique. The good part is: there’s less confusion between project-wide and target-specific build settings. Even more importantly, if you build several different libraries you want to build them with the exact same settings - with XCConfig files this is easy to do, manually changing the build settings of several projects with multiple targets simply isn’t practical.

Plus you can document each setting and you can still use the Build Settings Panel for your own needs while allowing me to use system-critical changes to the Build Settings. For example, if a certain build setting causes issues (eg like the switch to LLVM GCC) then I can change the setting and release a new version of the project, or just the build config file separately. You can then replace that file and it should fix the build (assuming you haven’t change that exact setting in the Build Panel). All of your customized Build Settings will remain untouched of course.

Those are only two very fundamental improvements on a system engineering level which probably won’t excite you too much if you focus on making games with any means necessary. I’m keeping the good stuff for a future update, hopefully in 3 to 4 weeks I’ll be able to give you some first details about the “killer-feature”.

Tagged with: Cocoaphony • cocos2d • cocos2d-project • cross platform development • development • Friday • KK • Project • teaser

Linkvent Calendar, Day 2: Community-Driven iPhone Game

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

Nate Weiss, author of the commercial iPhone Game Kit, would like you to help build the first community driven RPG game for the iPhone. Read his announcement.

He wrote a game design document for you to wet your appetite and learn what needs to be done. It’s an ambitious project that I believe would be awesome to take part in, especially if you don’t have the time and energy to build a complete game project by yourself, but you still like to take part in fruitful game development activities. What the game needs most is to design levels using the popular Tiled Map Editor, and new artworks for tiles, characters and cutscenes.

You do need to have a copy of the iPhone Game Kit to participate, but currently it’s on sale with 30% off and costs only $69. For that you get the complete source code and assets for the Quexlor action RPG and a 150 page game development eBook. I think his product and ebook are excellent and well worth the money, and I’m currently running two ads for Nate on a voluntary basis. You can learn more about the pros and cons of the iPhone Game Kit from these independent reviews:

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.

Tagged with: action rpg • blog • cocos2d • community • development • eBook • game kit • Kit • Nate Weiss • product • Quexlor • source code

Raising awareness: memory usage & leaks

On July 25, 2010, in cocos2d, Programming, Speaking From Experience, by Steffen Itterheim

While helping others solve their cocos2d project issues over the past year it became obvious that many projects have at least one major problem in one of these areas:

memory management
resource management
code structure

Examples

Memory management issues normally range from allocating too much memory, either by loading too many textures up front which are only going to be needed later, or by memory leaks such as scenes not deallocating when switching scenes. Resource management problems range from not adding the right resources to the right target, often resulting in increased App size because resources are added to the bundle but never used by the App. It could also mean loading identical resource files except that they have different filenames (copies?), using up additional memory. Or not tightly packing sprites into Texture Atlases but instead using one Texture Atlas per game object - while this is understandable from a standpoint of logical seperation it does waste opportunities for optimization.

Finally, code structure or lack thereof regularly leads to “everything in one class” code design which is most likely an evolutionary process rather than intentional. It’s not uncommon to see classes with thousands of lines of code, sometimes even going past 10,000 lines of code in one class. Other things are using too many CCLayers without them adding a clear benefit, for example just to group all nodes at a specific z order together or to group them by functionality, eg one layer for enemies, one for players, one for background, one for UI, one for score, one for particle effects, and so on - without any of these layers being used for what they’re really good at: modifying multiple nodes at once, like moving, scaling, rotating or z-reordering them. And of course there’s the copy & paste hell, large blocks of code reproduced in various places only to modify some parameters instead of creating a method which takes the modifiable parameters as arguments. Even professionals I worked with got so used to doing that it became hard just to overcome the resistance of letting go of old habits. But they learned.

Summary

Nothing of this code design and structuring strikes me as odd or surprising. I’ve written code like this myself. I also believe if it’s good enough and works, then why the hell not? It’s a matter of experience and it’s only with experience that you clearly see how to improve things. This boils down to the regular learning curve where only training and tutoring and just simply making mistakes and learning from them helps in the long run. That’s how we learn things.

On the other hand, the things like Memory and Resource Management can also be learned but they have a different nature. They can be statistically assessed, they could be calculated and verified automatically. This makes me wonder if there isn’t some kind of automation and information tools that would help developers achieve better results in terms of memory usage and resource management? In the meantime it’s all about raising awareness …

Raising Memory Awareness

Most importantly I think we need to raise more awareness to these issues to cocos2d developers. One step towards that would be for cocos2d to display a “available memory counter” alongside the FPS counter. I used to patch CCDirector to simply display memory instead of FPS since that was always more important to me. Fellow cocos2d developer Joseph sent me his version to display both - I simply didn’t think of the obvious. So if you’d like to see FPS and available memory next to each other I think you can handle the changes to CCDirector outlined here:

// CCDirector.h, add below @interface:
+(double) getAvailableBytes;
+(double) getAvailableKiloBytes;
+(double) getAvailableMegaBytes;
// CCDirector.m, add as appropriate:
#include <sys/sysctl.h>  
#import <mach/mach.h>
#import <mach/mach_host.h>
[...]
+(double) getAvailableBytes
{
	vm_statistics_data_t vmStats;
	mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT;
	kern_return_t kernReturn = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount);
	if (kernReturn != KERN_SUCCESS)
	{
		return NSNotFound;
	}
	return (vm_page_size * vmStats.free_count);
}
+(double) getAvailableKiloBytes
{
	return [CCDirector getAvailableBytes] / 1024.0;
}
+(double) getAvailableMegaBytes
{
	return [CCDirector getAvailableKiloBytes] / 1024.0;
}
[...]
-(void) showFPS
{
	frames++;
	accumDt += dt;
	if ( accumDt > CC_DIRECTOR_FPS_INTERVAL)  {
		frameRate = frames/accumDt;
		frames = 0;
		accumDt = 0;
		// the only change in showFPS is this line:
		NSString *str = [[NSString alloc] initWithFormat:@"%.1f   %.1f", frameRate, [CCDirector getAvailableMegaBytes]];
		[FPSLabel setString:str];
		[str release];
	}
}

// CCDirector.h, add below @interface:

+(double) getAvailableBytes;

+(double) getAvailableKiloBytes;

+(double) getAvailableMegaBytes;

// CCDirector.m, add as appropriate:

#include <sys/sysctl.h>

#import <mach/mach.h>

#import <mach/mach_host.h>

[...]

+(double) getAvailableBytes

{

vm_statistics_data_t vmStats;

mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT;

kern_return_t kernReturn = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount);

if (kernReturn != KERN_SUCCESS)

{

return NSNotFound;

}

return (vm_page_size * vmStats.free_count);

}

+(double) getAvailableKiloBytes

{

return [CCDirector getAvailableBytes] / 1024.0;

}

+(double) getAvailableMegaBytes

{

return [CCDirector getAvailableKiloBytes] / 1024.0;

}

[...]

-(void) showFPS

{

frames++;

accumDt += dt;

if ( accumDt > CC_DIRECTOR_FPS_INTERVAL) {

frameRate = frames/accumDt;

frames = 0;

accumDt = 0;

// the only change in showFPS is this line:

NSString *str = [[NSString alloc] initWithFormat:@"%.1f %.1f", frameRate, [CCDirector getAvailableMegaBytes]];

[FPSLabel setString:str];

[str release];

}

Raising awareness to leaking Scenes

In addition I highly, strongly and with utmost reinforcement (without pulling out a gun) recommend to cocos2d developers to frequently check your scene’s dealloc methods. Preferably add a breakpoint there, or at the very least add the logging line: CCLOG(@”dealloc: %@”, self). If you want a more visible but less intrusive method you could do something like flashing the screen or playing a sound whenever the last scene is deallocated, so that you get so used to it that when you’re not seeing or hearing it anymore it immediately raises your attention.

If at any time during the development of your project the dealloc method of a scene isn’t called when you change scenes, you’re leaking memory. Leaking the whole scene is a memory leak of the worst kind. You want to catch that early while you can still retrace your steps that might have caused the problem. Once you get to using hundreds of assets and thousands of lines of code and then realize the scene isn’t deallocated, you’ll be in for a fun ride trying to figure out where that’s coming from. In that case, removing nodes by uncommenting them until you can close in on the culprit is probably the best strategy, next to using Instruments (which I haven’t found too helpful in those cases).

I ran into such a problem once because I was passing the CCScene object to subclasses so that they have access to the scene’s methods. The subclass retained the scene and was itself derived from CCNode and added to the CCScene as child. The problem with that: during cleanup of the scene it correctly removed all child nodes but some of the child nodes still retained the scene. Because of that their dealloc method was never called, and in turn the scene was never deallocated.

Tagged with: CCLayer • CCLOG • CCNode • CCScene • cocos2d • cocos2d-iphone • code structure • dealloc • design • developer • development • Director • game object • memory • memory leak • memory leaks • memory management • memory management issues • resource files • resource management problems • showFPS

Line-Drawing Game Starterkit finally available for sale!

On July 19, 2010, in Announcements, Marketing, by Steffen Itterheim

I’m pleased to announce that the Line-Drawing Game Starterkit is finally available for sale! It’s a source code project for anyone interested in developing a line-drawing game. The gameplay is modelled after the famous Flight Control game. The Starterkit works with the latest cocos2d v0.99.4 version and will at the very least receive compatibility upgrades for future cocos2d versions.

Hop on over to the product page to check out the feature list, the API documentation and a source code sample. You can also download the Starterkit App for iPhone from iTunes. The iPad Edition is still in approval.

Note: for the reminder of July 2010 you can get the Starterkit at an introductory price for only $179!

Positioning of the Starterkit

I’m sorry that you’ve had to wait one and a half months compared to the initially planned release date of June 1st. I double and triple checked every decision I made and you can see some of the results on the Starterkit product page.

I’ve also decided to increase the regular price from the initially intended $199 to $299 effective from August 1st, 2010. One of the reasons being that I initially planned to have multiple licenses including Indie and Commercial ones. I thought long and hard about positioning the Starterkit and eventually decided to sell only Site Licenses. For the individual developer it costs a bit more but for small and commercial teams it’s great news, and small teams and established, dedicated developers is who I am targeting. Those who really appreciate the value of commercial source code saving days and weeks of research and development, and all the trouble, sweat and pain associated with it. And I’m here to help if you have any questions regarding the Starterkit’s source code.

I don’t have plans to make another Starterkit and in all likelihood it will remain the only commercial cocos2d-related product for the remainder of this year.

Book Chapter about Line-Drawing Games

For those who are disappointed about the new price, either grab the Starterkit before August 1st or wait until December for the Learn iPhone and iPad Cocos2D Game Development book I’m writing. It will contain a chapter covering some of the basic aspects of a line-drawing game but without the finer details and complex interactions conveyed in the Starterkit. It’ll be Chapter 12 so in about 8 weeks (Mid-September) I’ll mention it in my weekly book chapter posts.

Closed Sales Period, Summary of

And here’s for transparency: exactly 10 days ago I informed the 668 subscribers of my Newsletter of the closed sales period. The password-protected Starterkit product page received just over 200 unique visitors. During the last 10 days I made 9 sales amounting to about $1,530 with Plimus’ 5% fee already deducted but obviously before tax. All sales were made within the first 4 days after I sent the Newsletter and for the last 6 days sales were absolutely zero. Although I’ve been in contact with several interested parties who didn’t want to or simply couldn’t buy it right now for various reasons. If you’re one of them: you’ll get it for $179 no matter when you make the purchase, just contact me beforehand.

Right now I’m curious to see how sales will be now that the Starterkit is publicly available.

Starterkit Promotion

I’d appreciate if you would tweet and re-tweet this post and mention the Starterkit to all fellow cocos2d-sians! If you would even go so far as writing a serious and honest review on your blog, please get in touch with me.

Just don’t test the waters by mentioning the Starterkit in the cocos2d community forum.

Stance Lance

I wish Ricardo had taken the time to be considerate and then talked to me instead of running off making an assumptive, excessive, and for the most part irrelevant (off-topic) stance post which only served to cause a big commotion among his community while allowing his forum rule “Treat people with respect.” to become a farce.

In Conclusion

In hindsight I’m glad that the whole thing got me thinking in so many new directions. Most importantly it got me in contact with a lot of developers who consciously don’t post on the cocos2d forum. To get those encouraging words and positive feedback and gaining interesting insights from other developer’s perspectives - especially those who tag along silently - really helped me understand the cocos2d development community better. Thank you, you know who you are!

The whole shebang also served as a great motivational factor to pour my everything into the cocos2d book, which came at just the right time to let off steam in just the right way. I’m writing it to be the cocos2d documentation it deserves and the one I always wished it had. I can’t even begin to describe how satisfying it feels to write this book. So much in fact that it hurts to stop writing every time I reach the 27 pages each chapter is expected to have.

Tagged with: api documentation • cocos2d • cocos2d-iphone • commercial source • Competition • developer • developers • development • documentation • feature • feature list • game • introductory price • ipad • Kit • learn • license • line-drawing • product • product description • release • release date • sale • sample • source code • starterkit

I’m writing a Book: Learn iPhone and iPad Cocos2D Game Development

On July 1, 2010, in Announcements, cocos2d, by Steffen Itterheim

I’m writing a book for Apress:

Learn iPhone and iPad Cocos2D Game Development: The Leading Framework for Building 2D Graphical and Interactive Applications

I guess someone wanted to be very precise and thorough. 😀

I will blog about the book’s progress here and when it’s published I will add additional materials so readers can continue their journey here. Since this journey is just beginning - I’m submitting the first chapter aptly titled “Introduction” tomorrow - and writing a whole 400 pages book is an entirely new experience to me, I want to let you in on the journey.

Help me help you by providing feedback to the book’s content as I’m writing it!

For the coming weeks, I will announce the current book chapter title and a short description and ask you what you’d like to see in this chapter. I will make these posts every Friday starting tomorrow until the book is complete. In this post you could start by telling me what you’d expect from this book or what you’d like to see in it just given its title? I guess your answer will be “a lot” given the title’s elongated nature. :p

I hope you forgive me if content updates to this website will not be as comprehensive over the coming months, in favor of writing the book and coding sample games. Plus I’m cooking up something special on the side, but all in due time.

Oh, by the way, if you happen to know what kind of fruit that is on the cover I’d like to know. I could just ask my editor but I’d like to see if we can figure it out without the help from Apress. It doesn’t really look like a coconut to me, which would have been fitting given the subject. If you have any ideas what fruit it is, let me know! It sure looks exotic and it’s definetely not a banana nor a lemon. So what is it? The first to post the correct answer in a comment, together with a link to Wikipedia or some other website as proof, gets a copy of the book for free when it’s out (or $40 now)!

And now for something completely different …

As a side note, the Xcode project files from the Xcode Tutorial are now available for download here. I used to ask you to join my Newsletter but I don’t feel too good about hooking you up with my Newsletter using the project as a dangling carrot, so joining the Newsletter will now be a completely voluntary thing. I only send newsletters for substantial updates and important news, at most once or twice per month, so that’s the thing you want if you are already struggling with RSS overflow.

Tagged with: apress • blog • book • cocos2d • code • development • game development • how-to • Introduction • Newsletter • Project • providing feedback • RSS • template • tutorial • writing a book • Xcode

Starterkit: Line-Drawing

On May 27, 2010, in , by Steffen Itterheim

Line-Drawing Game Starterkit

Site License! Unlimited Apps!

Royalty Free! No Attribution!

60 day money-back guarantee!

Made with the popular cocos2d-iphone game engine.

Compatible with cocos2d-iphone v1.1 and v2.0, Xcode 4.6 and iOS 6.

Includes ARC enabled versions of the starterkit!

Sale - only $49 !

All Starterkit project artwork provided by Arezou Ipakchi Design. Promotional images created by Justin from CartoonSmart.

What it is:

Get a head-start for your Line-Drawing game and save days if not weeks of your time! You’ll get gameplay code modelled after the extremely popular Flight Control game. You’ll learn how to draw lines, detect touches on objects, have objects follow a path - and much, much more! Written by a professional game developer and game industry veteran (me) the source code is annotated with lots of comments explaining my rationale and written with readability in mind.

Contains separate iPhone & iPad targets!

The Starterkit includes targets for iPhone and iPad using the same code if you don’t want to create a Universal app, for example to reduce your app’s size or to be able to charge more for the iPad version. If the iPad Target is selected hi-res iPad images will be used. Image selection is done automatically by loading those images whose filenames have the “-ipad” suffix, the same suffix cocos2d uses.

What others are saying:

“Code is quite clearly written and decently documented […] definitely a fine investment.”
From: Commercial cocos2d Code review from Alex Curylo.

“It was an awesome moment when I found the source for a line draw game of this caliber.”
-Franklin Lyons, SpinFall

“Especially the path and movement system is saving me lots of headaches.”
-Martin Hoffmann

Games made with this Starterkit:

Launch Control

Ferries HD

Feature List:

cleanly seperated and well-structured GameScene code design with a minimum of dependencies
easy to add new objects and extend object parameters
touch object & draw a path for it (whether it’s already following a path or not)
path drawing ends when path is drawn over appropriate target location (eg airstrip for airplanes, respecting angle of approach)
path drawing ends when arbitrary point limit is exceeded (to avoid slowdowns)
path is drawn when dragged with thick transparent line style like Harbor Master, without glitches
path is split into equal length pieces no matter how quickly user moves finger
objects spawn outside screen, locations can be re-defined and extended
objects display incoming warning marker at screen border
objects display collision warning when any two of them are getting too close
objects follow path to end - then fade out and increase score or continue moving
objects always rotate in movement direction
objects bounce back at screen borders
motivational Labels for successful landings, precached
Score and HighScore Labels
HighScore saved to disk between play sessions
supports both Landscape orientations with autorotation
loads correct resource files depending on Target (iPhone or iPad)
proper Pause handling for incoming calls, SMS
many generally useful Math Helper functions included
lots of comments explaining rationale and giving tips for improvement
assertive coding style to help catch coding errors early on
offline and online documentation
you can choose between using cocos2d-iphone v1.1 and v2.0
you can choose between using ARC or classic manual reference counting
compatible with iOS 5.0 and newer, including iOS 6
compatible with Xcode 4.6 (the most recent versions also work)
easy setup: just unzip, open Xcode project, select build scheme, build and run

Questions? Need Help?

Just send me an email.

Legal Disclaimer

Cocos2D is a registered trademark of Ricardo Quesada. Steffen Itterheim, the Learn & Master Cocos2D website and the Line-Drawing Game Starterkit are neither affiliated with nor endorsed by Zynga or Ricardo Quesada.

Try Before Buy!

Demo App for iPhone
Demo App for iPad

Browse the API Documentation

View a Code Sample