Well, that’s that. Enjoy your holidays! 
I’ve also released OpenGW Preview 1 to KoboldTouch customers. Then visit the members area to download it. Visit the OpenGW website and wiki to learn more.
In case you feel like checking it out just sign up to any of the KoboldTouch subscription plans. The KoboldTouch subscription price will not change for you if you stay signed up. Once we release OpenGW (it will replace KoboldTouch) the price will go up for new customers.
The OpenGW framework itself is fully functional and well tested. It comes with a basic code-based example and a complex Platformer example game built with the help of Tiled and Lua.
What isn’t so good yet is the way projects are set up (expected to change before release) and to start a new project you’ll have to copy an existing project and start modifying that. OpenGW is not currently meant to be added to a custom project - unless you can fight your way through some project setup steps. These rough edges will be polished next year.
With the release of iOS 7 (ETA: Tuesday, Sept. 10th):
Kobold Kit will be available as open source under the MIT License!
We spent a lot of thoughts on how we like to run an open source project. And also why. I’ll start with an executive summary with more (perhaps too many) details in the text.
The Idea: make the project as open and inviting as possible. Let contributors gain control over and take on responsibility for the project based on their contributions. Provide them with ways to promote their work on their own accord.
The Goal: build the Sprite Kit game engine with the help of many developers.
Kobold Kit is supposed to become the “patron project” under whose roof the most valuable Sprite Kit extensions are combined. Website, forum, wiki, blog and store are extended playgrounds shaped by community members. If you’re part of the project, we want you to proudly present and benefit from it.
In essence: we want to get out of the way as much as possible and enable anyone to find their place in the project. Guidance, not dictating, is our guideline.
I wrote iCanSleep after I couldn’t find a tool that matched my requirements.
Both Caffeeine and InsomniaX rubbed me the wrong way - the former does not allow the display to sleep (WTF? Who would want that?) and the latter prevents sleeping altogether (WTF? I can set Energy Saver settings to “Never” myself, thank you).
To be fair: both tools have some merit, just not for me. Specifically InsomniaX has features for MacBook Pro users.
What I wanted was a tool with customizable “no sleep” duration, and not the 5-30 minutes, 1, 2 and 5 hour option of Caffeine, or none as with InsomniaX.
One that
Continue reading »
I just released a compatibility update for Kobold2D since there were numerous compiler warnings and errors introduced in Xcode 4.4.
Almost all of the issues were simply the compiler being more adamant about using the correct type specifiers in format strings. For example using %i for an unsigned integer or %u for an unsigned long type would bring up warnings. The solution is to use either the correct format specifier or casting the value. The latter is preferable if the underlying type changes depending on the platform. For example NSUInteger is unsigned int for iOS but on Mac 64-Bit it’s actually unsigned long.
You can get the updated Kobold2D v1.1.2 and v2.0.3 versions from the Kobold2D Downloads page. Continue reading »
Whaaaaaat?
You heard right: if you want to forget about using retain, release and autorelease in your code, then the newly introduced automatic reference counting (ARC) mechanism (aka “automatic memory management”) is the way to go. And guess what?
Kobold2D Preview 6 fully supports ARC out of the box!
You may have heard that Cocos2D is incompatible with ARC at this time, and you’re right. However, the Cocos2D version in Kobold2D Preview 6 released just now has been improved to work with ARC. This post explains the most important changes to make Cocos2D compatible with ARC. All 15 Kobold2D example projects compile with and without ARC, just like the other libraries Kobold2D makes use of!
My Line-Drawing Game Starterkit is now up to date with the latest versions of cocos2d (v1.0.1), iOS (compatible with iOS 3.1 and higher, including iOS 5.0), Xcode (compatible with Xcode 3.2 and above, including Xcode 4.0 on Snow Leopard and Xcode 4.2 on Mac OS X Lion).
Existing customers will receive an email with instructions on how to download the updated version of the Line-Drawing Game Starterkit.
Ferries HD was made with the Line-Drawing Starterkit
I’ve added another cool game made to the Line-Drawing Starterkit product page - Ferries HD by Thomas Busse:
Note: the game is not included in the Starterkit. It’s a game that was made with the Starterkit and serves as a great example of what you can achieve with the Line-Drawing Game Starterkit.
Price dropped to $99 (from $119)
I dropped the price of the Line-Drawing Game Starterkit to $99 in anticipation of upcoming commercial source code products that I’m working on. More on that in due time, first things first (Learn Cocos2D 2nd Edition and Kobold2D).
What about Kobold2D?
I know, I know. Kobold2D isn’t too far out. I anticipate the first preview (beta) release in August. Stay alert.
What’s left to do at a minimum is to write the Project Starter tool (to give you the convenience of Xcode 4 Project Templates but with more flexibility), setup the website with the “getting started” documentation plus API references and perform some general project cleanup.
And when is the Learn Cocos2D 2nd Edition coming out?
It looks like the new edition of the book will be out in October, roughly two months later than anticipated.
On the positive side I’m working with a new editor who brought in a fresh perspective from which the book greatly benefits. The delay also allowed me to make more substantial improvements than initially planned.
In particular Chapter 3 (Essentials) was completely overhauled to better explain the fundamental concepts of Cocos2D, and you’ll find the book to be more visually rich in general. For example this exploded view drawing is used to explain the relationship of Scenes, Layers and Nodes:
The book’s source code already uses the recently released Cocos2D v1.0.1 and I will continue to update the book’s source code for the v1.x line of Cocos2D. Several of the game projects discussed in the book will also be ported to become Kobold2D project templates.
I assume we’re all eagerly awaiting for cocos2 v1.0 and to be given a download link to click on. The year 2010 started so promising, with v0.9 going through beta during end of 2009 and beginning of 2010. This v0.9 never came out of beta but was re-labelled as v0.99 and released as final version in February 2010 (if I remember correctly, it was either due to the amount of changes or the closeness to v1.0 that it was labelled v0.99). At this point I was thinking that by the end of spring, at the very least, we’d have a final v1.0 of cocos2d.
But 8 months later we’ve just seen v0.99.5 beta 3 release but no v1.0 in sight yet. I’m growing impatient. I’m wondering what the holdup is? The version labels seem to grow longer and longer, as if the labels were trying to prove the point that you can still have an infinity between 0.99 and 1.0 - if you only add enough digits and other stuff after the decimal sign this could go on forever.
So, please, for the love of god, just label it v1.0 already and lets get on with regular 0.1 steps from then on!
Just out of curiosity, I made a quick spreadsheet and hacked the average time between updates in, and it told me that according to this year’s release schedule v0.99.7 will be released on December 24th, 2010 and v1.0 sometime May next year. If version number updates continued at this rate, don’t hold your breath for v1.1 before the second half of 2012.
It’s just a silly estimation based on average days between new versions and their respective version numbers, so don’t take this seriously, or the wrong way. I’m merely growing annoyed and concerned how cocos2d progress has not been reflected in the version numbers in all of 2010, and how version numbers have grown out of proportion and anything I can relate to. Not that it’s any of my concern, but I do believe that doesn’t do cocos2d a good service to continue to label new versions like “0.99.5 beta 3”, and it certainly doesn’t help to portray it in the right light if you compare it to the progress other engines have made over the same period of time - if only in version numbers.
It’s almost as if going “v1.0” meant that cocos2d would be losing its virginity, and that being a life-changing event it shouldn’t happen without about a year of dating, right?
Right?
Well, for what it’s worth, I would suggest taking on the pretty-much-standard versioning style: major version dot minor version dot bugfix/hotfix (non-breaking) releases dot build number. Then go back to the regular release cycle with about two months for each 0.1 step, regardless of what the major number is.
I mean, a major version number change should still introduce something awesome, or useful, or practical, or helpful - in that case just skip the remaining 0.5 or so ahead and bump the major version right away. Personally, if HD support is in and points instead of pixels (what a concept) then that would be it for me. That would be a good v1.0. Get it done and all the bugs fixed, and label it v1.0 so we can all start looking forward to more reasonably labelled releases. Really, it just doesn’t matter that much if you change the first frickin’ number from 0 to 1.
Personally, I would have preferred if cocos2d were now closing in on v2.0. That would be about the version we might be at if the rate from 0.5 through 0.8 had continued at the past update rate. And a v2.0 would be absolutely justified for cocos2d, and I suppose a lot of people would feel much better working with a v2.0 than the current unstable 0.99.5 beta 3.
I hope we won’t see this happening again when cocos2d tries to get pregnant, and labels itself something like “v1.98.7 beta 6 final alpha” around that time to reflect the process, or progress, or lack thereof, or hormone levels, or morning sickness intensity, or whatever.
It’s a frickin’ version number, that’s all that it is!
And it needs some serious increasing to catch up with its level of maturity. Think about what that means to how cocos2d is first perceived by an outsider.
Heck, Unity is now at v3.0, SIO2 is racing towards v2.0, Shiva is close to v1.9 and even the slow-to-release-updates iTorque has gotten to v1.4 by now. Cocos2d is still afraid to go even v1.0 and it’s a shame, because it hurts its reputation, it doesn’t do itself justice, it’s likely to be perceived as being behind the pack and it doesn’t look good in terms of actual progress being made, regardless of the actual work that’s been done this year.
