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:
[cc lang=”lua”]
local config =
{
AccelerometerControls =
{
UpdatesPerSecond = 60, — 60 Hz
Responsiveness = 0.997,
SensitivityX = -2,
SensitivityY = 2,
MaxVelocity = 100,
},
}
return config
[/cc]
And this line of code loads these values and assigns them to the correspondingly named properties of the target class:
[cc lang=”objc”]
[Config loadPropertiesFromKeyPath:@”AccelerometerControls” target:self];
[/cc]
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.
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.
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
// 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.
