There hasn’t been a new Cocos2D Podcast in over 4 months.
It was about time Mohammad Azam and I recorded another one.
This time our guest was Krzysztof Zabłocki, developer of the Foldify app and contributor to cocos2d-iphone.
Among other improvements Krzysztof added stencil buffering to CCRenderTexture.
Interviews with Mobile Game Engine Developers
The Mobile Game Engines eBook is now available!
One of the interviews is with me, about Kobold2D. KoboldTouch was at the time no more than an idea.
Jason Brownlee gave me permission to share the full interview with me (PDF, 18 pages). Go on, read it!
There are of course plenty more reknown game engine developer interviews in this book. Here’s the full list of interviewees: Continue reading »
I’m really happy and excited that YETIPIPI was released today in the iOS App Store! 
UPDATE: currently only available in german App Store due to delayed english localization.
Go grab it for $.99 (€.89) try it out and give it it’s (hopefully) deserved 5-Star review.
What’s the game about?
YETIPIPI was a contract project in collaboration with Doubleplus Digital Media Entertainment for Joscha Sauer. Joscha is one of germany’s most popular cartoonists and the mastermind behind the Nichtlustig cartoons (some of his cartoons are also available in english).
The game is inspired by one particularly famous comic strip, where a Yeti pees in a circle, leaving him (or in this case both) stranded in an unfortunate situation.
To survive, our Yeti must drink so he can pee the ice floes floating about in ever smaller pieces. You control the Yeti with the accelerometer to collect items, evade ice floes and to aim your stream of urine. Continue reading »
There are two classes of scrolling, "fake" and "real".
Altogether there are four ways to create a scrolling view in Cocos2D: with CCCamera, with CCFollow, manually moving a layer and "faking it".
I’ll discuss each approach and show their advantages and disadvantages as well as point out for which types of games they work best.
The example projects for this article can be downloaded from github.
Fake Scrolling - Creating the Illusion of Movement
Ideal for "endless scrolling" games. Typical genres include jumping or running games like Doodle Jump and Canabalt, as well as shoot’em ups.
These games mainly scroll along one axis, often scrolling only in one direction. The other axis has a limited range or is not scrolled at all. The fake scrolling approach prevents the coordinates of game objects to "explode" to similarly infinite coordinate points. This could introduce rounding errors in floating point values which may accumulate over time, causing inaccuracies at later stages of the game.
To create the illusion of scrolling, at least two background image sprites are needed. Four are needed if you also want to scroll a little along the minor scrolling axis. The background images must be repeating seamlessly, and each must be at least the size of the screen. The trick is to use the two or four images and move them in the opposite direction of where the player is supposedly heading. Continue reading »
Due to technical issues (blank page) I had to split the previous article (now focuses only on memory optimization) in two. This is the second part which (mostly) focuses on reducing the app bundle size.
Loading Assets In Sequence
Here’s the code that I use to load textures or other assets asynchronously (in background, on another thread).
Imagine loadAssetsThenGotoMainMenu being a scheduled method that runs every frame or perhaps less often. The assetLoadCount and loadingAsset variables are declared in the @interface as int and BOOL respectively.
|
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 |
-(void) increaseAssetLoadCount { assetLoadCount++; loadingAsset = NO; } -(void) loadAssetsThenGotoMainMenu:(ccTime)delta { NSLog(@"load assets %i", assetLoadCount); switch (assetLoadCount) { case 0: if (loadingAsset == NO) { loadingAsset = YES; NSLog(@"============= Loading home.png ==============="); [CCTexture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGB5A1]; [[CCTextureCache sharedTextureCache] addImageAsync:@"home.png" target:self selector:@selector(increaseAssetLoadCount)]; } break; case 1: if (loadingAsset == NO) { loadingAsset = YES; [self performSelectorInBackground:@selector(loadSpriteFrames:) withObject:nil]; } break; // extend with more sequentially numbered cases, as needed // the default case runs last, loads the next scene default: { [self unscheduleAllSelectors]; MainMenuScene* mainMenuScene = [MainMenuScene node]; [[CCDirector sharedDirector] replaceScene:mainMenuScene]; } break; } } |
When this method runs the first case statement is executed. To avoid accidentally loading the same image multiple times every time the selector runs, the loadingAsset flag is set to YES. When the texture cache has completed loading this texture, it will call the increaseAssetLoadCount. This then ensures that the next case statement is executed the next time loadAssetsThenGotoMainMenu runs.
The cool thing about this solution is that you can easily add more switch statements to add more textures to load. Because the default case is where the scene changes, and that only happens if there are no more switch cases to process.
Be sure not to skip a number in the switch cases because that will also run the default case.
Decreasing the size of your app
Besides the memory usage advantage, reducing the color bit depth of textures to 16 bit will also significantly reduce their size. But there are other options that will allow you to reduce your app’s size, perhaps significantly.
TexturePacker PNG Optimization
If for some reason you still want to use PNG files instead of the highly recommended .pvr.ccz file format, TexturePacker has a slider named “Png Opt Level” to help reduce the size of PNGs (doesn’t affect loading time though):
As far as I understand it, it tries a given number of optimizations and picks the one that creates the smallest file size. The downside is that the maximum level can take very long for large texture atlases, in some cases 10 to 20 minutes on a Late 2009 27″ iMac. The task is multi-threaded, so it should be a lot faster on quad core systems.
Fortunately there’s really no need to do this unless you’re ready to release the app. Question is, how much can it reduce the size of PNG files? Continue reading »
I’m currently completing one last contract project. One of the last things I had to deal with was to optimize the game’s memory usage.
In today’s iDevBlogADay article I’ll explain how I was able to cut down memory usage by about 25-30 MB (down to 90-95 MB, ie fixing memory warning related crashes) as well as reducing the size of the app bundle from around 25 MB to below 20 MB (which would have been more awesome if Apple hadn’t already increased the over-the-air download limit from 20 MB to 50 MB some time ago).
I’ll also explain how to animate the loading screen while you’re loading resource files, and I’ll add some best practices and common wisdom too.
What’s using 90% of the memory?
Take a guess.
In almost all cases, it’s textures that consume most of the app’s memory. So textures is where you look to optimize first and foremost if you’re having memory warning troubles.
Avoid loading PNG/JPG Textures one after another
The problem with texture loading in cocos2d is that it happens in two steps: first, a UIImage is created from the image file. Then a CCTexture2D object is created from that UIImage. This means while a texture is being loaded, it will consume twice as much memory for a short time period.
The problem used to be so bad that if you loaded 4 textures one after another in the same method, at the end of the method each texture would still consume twice as much memory as it ought to, probably because of the way autorelease works.
I’m not sure if this is still the case, or whether this only applies to manual reference counting but not ARC. I made it a habit to load textures in sequence, waiting at least one frame before trying to load another. This will allow any texture loading overhead to be released from memory. Besides, as you’ll see later, if you want to load textures and other assets in the background this asset-load-sequencing is something you’ll do anyway.
Since I’ve started to offer KoboldTouch developers have been wondering what will happen to Kobold2D? I’ll answer these questions here.
Kobold2D Updates
When cocos2d 2.1 (stable) is released, I’ll update Kobold2D to include this latest cocos2d version. Same with any other cocos2d version that will be released in 2013. I won’t update to beta versions - sometimes they’re riddled with bugs, other times the next beta comes only a week or two later.
I’ll continue to support and update Kobold2D for as long as there’s interest in it but I’ll definitely focus my efforts on KoboldTouch now.
KoboldTouch “Lite”
Sometime in 2013 (probably not before Q2) I’ll release KoboldTouch “Lite” for free, with limited features and support. This Lite version will then take over as the successor of Kobold2D, while Kobold2D will remain available for some time.
KoboldTouch “Lite” will have the MVC framework but not much else. It will not include any additional features such as OS integration, better tilemap rendering, Box2D Objective-C wrappers and what not.
This ought to help developers get accustomed with the MVC framework.
Relaunch of www.kobold2d.com
Sooner or later I’ll relaunch the www.kobold2d.com website as www.koboldtouch.com. I’ll go for a simple look & feel (KISS), it will include the Kobold2D articles and I’m going to write all KoboldTouch documentation publicly.
For one this will make it easier for me to write and publish documentation. It should also help KoboldTouch’s popularity to reveal its documentation to both developers and search engines.
KoboldTouch compatibility with Kobold2D
KoboldTouch is not 100% compatible with Kobold2D, since I’ve already trimmed the less popular libraries from KoboldTouch: Chipmunk, Chipmunk Spacemanager, Cocos3D, ObjectAL, SneakyInput, iSimulate, AdMob. The remaining libraries are: cocos2d-iphone, cocos2d-iphone-extensions, CocosDenshion, Kobold2D, Box2, Lua and a few smaller additions (BitArray, LOG_EXPR, etc).
You should be able to port code that does not use one of these libraries with ease. Though without adapting to the MVC framework you lose a lot of the benefits of using KoboldTouch.
Custom Folders and Source Control
Issues regarding custom folders and source control usage come up frequently. I will alleviate those with KoboldTouch.
The project starter tool will be improved to support creating new projects in a custom folder, with or without copying the offline documentation to the new folder. The project upgrader tool will also work with custom folder locations.
The documentation accounts for most of the disk space usage of a Kobold2D/KoboldTouch project and should therefore not be included when you intend to manage this project with source control. Specifically if it’s an online repository with limited disk space. With the additional libraries stripped and documentation not included, a new KoboldTouch project weighs in at around 15 MB of disk space.
What will remain is that the installer will install to a fixed folder, since you will then be able to create new projects in any custom folder so there’s no real need for a custom folder location during installation.
There are plenty of issues with PackageMaker to overcome to support custom folder locations and I’d rather spend that time on other things. As was always the case, you can of course move the Kobold2D folder anywhere else after the installation completed - it’s just one click & drag operation in Finder.
Your question not answered here?
Let me know by writing a comment.
For the past two weeks I’ve been running a Cocos2D Developer Survey. As of today, 236 developers started the survey and 189 finished it completely. That’s 80% despite the many questions they had to answer.
Here are the results with my observations. I started the survey also to see if I was on track with KoboldTouch, and whether certain assumptions hold true. Specifically I had a hunch that cross-platform development is only perceived to have great value or appeal. Let’s see if I was right.
Click on each image for full resolution.
Who are you?
I was very curious how many cocos2d developers consider themselves to be hobbyists and indies compared to professionals, who either work for a mobile developer or are taking on freelance jobs as one.
Almost half of those who answered the survey are hobbyists. Nearly 30% consider themselves indies who make a living making mobile games. This is great! Continue reading »
I posted a KoboldTouch vs cocos2d-iphone architecture comparison chart to the KoboldTouch product page.
It’s only a start to better explain how KoboldTouch compares with cocos2d-iphone.
KoboldTouch Mini-Game
I’m now working on a KoboldTouch mini-game to showcase the KoboldTouch workflow and features. It’ll be the basis for the KoboldTouch Introduction Tutorial.
I’ll post a video presentation of the project and key points once it’s done. If you’re interested you can follow KoboldTouch development via PivotalTracker.
The mini-game project is also very important to “eat my own dogfood”. Even just a simple game made several things that didn’t feel right obvious, and presents opportunities for improvement.
I’m happy that the KoboldTouch users requested this simple game tutorial.
Excellent Growth
Speaking of members: leaving aside the initial 2-day launch rush, on average two new members sign up every day.
If KoboldTouch continues to grow at this rate, it will have 100 members before Xmas! That would be a major milestone I did not expect to achieve before February/March!
You can help KoboldTouch by taking 5 minutes of your time to complete the Cocos2D Developer Survey. I’ll post the results in a week and what they mean for KoboldTouch.
