The idea for this post really started with this poll:
I’ll present the results further down. Not wanting to spoil it before you made your choice.
This poll was just a quick test for a free web poll service. Well that and being curious how the major 3 Objective-C render engines compared against each other.
Since I added a “Other” choice and some users took it, I started to wonder what the “Other” choices might be.
I mean besides cocos2d-iphone, Sprite Kit, Sparrow and OpenGL ES, what choices could there really be? Have I perhaps not noticed the next big thing in Objective-C render engines?
Spoiler: I didn’t.
The Poll Results (as of Nov 28th 2013)
iOS 7 and thus Sprite Kit has been available for just over 2 months.
My expectation was that being so new and despite coming from Apple and developers usually slow to change their preferences, cocos2d-iphone would likely come out on top. At best it would have a head-to-head with Sprite Kit.
The actual result really surprised me: Continue reading »
A preview version of cocos2d-iphone v3 has been available for a couple days now. I thought I’ll take a closer look and summarize what’s been done, what’s working and what isn’t, what’s new and what’s old but revamped.
Installation
The installer script has been revamped. It has a different name (install.sh) and different parameters (-force instead of -f).
The first thing I noticed is that the installer is downloading Chipmunk2D. Made me wonder why, so I double-checked to confirm: Chipmunk isn’t included in the archive. This means no offline installation.
I’ll explain later why Chipmunk isn’t included.
Project & File Templates
In the preview there’s only one project template. It doesn’t demo any physics features, it’s your typical “Hello World” example with buttons.
There seems to be an issue with the template where any attempt to save it to a custom location caused Xcode to crash. In fact every time the “Save File” sheet came up and I didn’t click on “Create” right away, Xcode would crash. That’s just one of the reasons why it’s still a preview.
The CCNode File Template isn’t worth mentioning at this point, it creates an empty Objective-C class and is barely different from the regular Objective-C class template at this time.
Hello World v3
Continue reading »
With yesterday’s release of iOS 7 and hence Sprite Kit, many cocos2d developers will face this question sooner or later: switch to Sprite Kit or Kobold Kit or stick with cocos2d-iphone or perhaps move on to cocos2d-x?
I’ll give you some guidance and things to consider …
Sprite Kit / Kobold Kit
Sprite Kit made quite the splash. There are new tutorials coming out by the minute. Two books will be available within days after release. Several high profile tutorial & starterkit authors have jumped on the bandwagon. Tool developers are hard at work adding Sprite Kit support. Instructors are already offering new mobile game development courses based on Sprite Kit. Heck I even started a new game engine based on Sprite Kit: Kobold Kit.
With almost everyone jumping ship, it seems a safe bet to jump ship, too. You’re guaranteed to get excellent documentation from Apple, plus a stability of the framework until at least iOS 7.1 and even then Apple is known to carry on supporting deprecated methods for several versions. It’s easy to learn, and once learned you won’t be thrown off guard by new releases. And the developer community will soon surpass that of cocos2d-iphone. Continue reading »
KoboldTouch v6.2 marks the third major milestone for KoboldTouch. It also marks the longest development cycle between two updates: exactly 30 days.
That’s 30 days packed with new features, improvements and bugfixes, there’s a new development blog for the work-in-progress “Angry Trains” starterkit and slowly but surely the documentation is coming together.
So let’s check out the exciting new features in KoboldTouch v6.2:
Objective-C Box2D Physics wrapper
The Objective-C wrapper for Box2D (aka “Boxjective2D”) is now in a state that I feel very comfortable with. And proud. It’s the only Box2D Objective-C wrapper that’s both fairly complete and supported and will be continuously improved. It’s also stable, super-slick and easy to use, highly efficient without compromising integrity (ie no @private vars) and you can always access the underlying Box2D objects.
The following Box2D components are wrapped in Objective-C classes, which is about 80% of the public API of Box2D (and I won’t stop there): Continue reading »
Or so goes the argument. Still.
I wish Apple would just pull the plug and completely remove MRC support from LLVM. I’m getting tired, annoyed and sometimes angry when I browse stackoverflow.com and frequently find MRC code samples containing one or more blatant memory management issues.
Before I rant any further, this article is about testing the performance difference of ARC vs MRC code. I provide some examples, and the updated performance measurement project I’ve used before for cocos2d performance analysis, and the results of the full run at the bottom. I also split it into both synthetic low-level tests and closer to real-world algorithms to prove not one but two points:
ARC is generally faster, and ARC can indeed be slower - but that’s no reason to dismiss it altogether.
Measuring & Comparing Objective-C ARC vs MRC performance
Without further ado, here are the results of the low-level MRC vs ARC performance tests, obtained from an iPod touch 5th generation with compiler optimizations enabled (release build): Continue reading »
So, you’ve heard about Objective-C automatic reference counting (ARC). And you’ve read about it here and there and every where. But you’re not using it.
Guess what? You’re not alone. There are developers out there who refuse to use ARC, who delay using it, who believe they just can’t use it or expressly decided against using ARC for the time being. They all have their reasons.
Most of them are wrong.
Here’s a summary of reasons I’ve heard (repeatedly) in the past months from developers who aren’t using ARC, or have tried it but gave up using it. And I’ll tell you why these rationalizations are wrong, or at least over-inflated. Continue reading »
Have a look at the following code example:
|
1 2 3 |
NSString* str1 = NSString.alloc.init; NSString* str2 = str1.copy; NSLog(@"str1: %@, str2: %@", str1.capitalizedString, str2.description); |
Did you find it strange somehow? Odd perhaps? Then you may be surprised to learn that this is perfectly valid Objective-C code. Go ahead and try it in your project. As long as the project is set to use the Apple LLVM Compiler this will work.
In this episode of LearnCocosTV I demonstrate how to write and animate a Cocos2D scene with KoboldScript.
KoboldScript is more than just writing the same Cocos2D code but with a scripting language. Most other scripting language bindings for game engines simply translate the game engine’s C/C++/Objective-C API 1:1 (more or less) without introducing new concepts, adding more comfort by simplifying common tasks, or utilizing the powerful features of whatever the scripting language has to offer.
KoboldScript goes three steps further than that - one by tightly integrating the setup of scenes via defining the node properties in a tool-friendly tree structure (Lua table) that you can both write manually or create programmatically using Lua’s built-in features.
Two, by using Statemachines to drive game logic while also providing free Lua scripting via user-specified Lua callback functions. And three, by adding a (MVC-ish) component system with re-usable abilities and behaviors to all Cocos2D nodes.
Unfortunately I ran out of time at the end so I couldn’t even say goodbye. I hope you don’t mind. 
Episode #6 - One Small Script for Man …
• KoboldScript Demonstration
o How to create Scenes with Sprites, etc
o How Abilities & Behaviors work
• iDevBlogADay: Asynchronous Texture Loading
o Cocos2D Webcam Viewer speedup
