There are many Cocos2D + Storyboard tutorials, it’s about time to do another one that’s done right. Also, this one’s backwards: we’ll start with a Cocos2D template and then add Storyboards to it. The tutorial will work for existing Cocos2D projects to which you wish to add Storyboards, too!
I’ll show you how to add Storyboards to a Cocos2D v2.1 project, with ARC enabled of course. This approach will take a little more work, but the solution will be complete and you gain a fair understanding of how things work together. Plus two custom but reusable View and Navigation controller classes, and I’ll show you what changes you need to make to the AppDelegate.
The resulting project will work with iOS 5 and iOS 6 and autorotation. The navigation and cocos view controllers are separated, and you will be able to subclass them for code customizations as is customary in Cocoa. Cool? Cool, cool, cool!
As usual you can grab the example project (Cocos2D + Box2D + Storyboards with ARC enabled) from github. I’ll also be adding a Storyboards template project to KoboldTouch in the next update, and document what’s special about the KoboldTouch solution.
Oh, only one thing … this tutorial is part of Essential Cocos2D. Head on over and enjoy!
Here’s a crazy thought: with commercial game kits (game source code products) being popular and financially rewarding – why not crowd-fund an iOS game by selling it’s source code, resources and development insights while you’re creating it?
Marcus and I will give this idea a spin. Marcus is a game designer I worked with at Electronic Arts Phenomic for 6 years. I’m sure you know me. Together we’re going to create a tilemap-based physics game using cocos2d and KoboldScript (Lua scripting for cocos2d). And we are going to sell everything we’ll create practically from day one.
If that sounds even slightly intruiging to you, we’d love to get your feedback!
Visit the launch page and take our survey which has already helped us tremendously to focus on what’s important for you. For example I’ve converted the entire KoboldScript library to use ARC seeing how important ARC is to you.
But do keep on reading for more details … Continue reading »
Continue reading »
So you have this website going or some source code on github, and like to earn a few bucks. Donations, right? Hold on, there are a couple things you should consider before you add that Donate button!
UPDATE: If you prefer a concise, to the point summary of this post, you should read the follow-up post The 10 Golden Rules for a Donate Button.
In case you haven’t noticed, you won’t find a Donate button here or on my other websites. It may seem strange that the guy who never had a donation button of all people should write a guide to the donation button.
I consciously decided against having a donation button. You’ll find a number of reasons in this post, and maybe at the end of it you come to agree with me that Donate buttons are over-used, and the more developers offer them the fewer donations reach those developers who actually need and/or deserve donations the most.
I also wrote this as guidance particularly for individual indie or open source developers who are accepting donations or considering to do so, because donating to an individual is fundamentally different than donating to a (charitable) organisation or a software project (team) as a whole. You will also get some ideas on how you can improve your donation acceptance rate and which alternatives for voluntary compensation and appreciation exist.
Rule Number 1: Be a charity or a business. Never both!
I sell commercial products, both my own and third party products for which I receive a commission fee for each sale. I am self-employed, I make my living from those products and a few select contract jobs for people I know personally. It is fair to say that I’m running a business.
For me the question of whether I should ask for donations boils down to this: should a business be asking for and accepting donations? Continue reading »
Continue reading »
Most developers have heard of the phrase “Eat your own dog food”. It refers to the habit of actually using what you’re creating.
A typical example would be a company building Yet-Another-Issue-Tracking-Tool™ while using said issue tracker to manage their Yet-Another-Issue-Tracking-Tool™ project. And you’ll surely have heard of a game engine that was initially only developed as a necessity to build a game, then polished and released to the public to great success, while the developer continued to create games with his own engine.
Dogfooding is considered a good practice, actually a best practice. You know that the tool you’re building works, and that it satisfies your needs.
But “your needs” is also the achilles heel of dogfooding, and it’s just a small step away from forever “perfecting” your product (known as “gold plating”). So sooner or later, you’ll have to do some catfooding, too. Meaning: to feed the user’s needs. Continue reading »
Continue reading »
A couple months ago I wrote a tutorial explaining how to upgrade Cocos2D in an existing project.
I was able to cut the description down to only five concrete steps, but there’s still a lot of text to follow and caveats to consider. I designed Kobold2D exactly to make it easy to solve the issue of upgrading projects to newer versions of the game engine.
Kobold2D is well and alive. Actually so much so that I thought: “Hey, it’s crazy, but maybe not … I’ll give it a shot and see how far I get.”
The thought was to try and add the cocos2d-x engine (cocos2d in C++) together with the Hello World example project to the Kobold2D workspace. The result: it took about 90 minutes, most of that figuring out the correct build settings and header search paths. And it just worked.
Right now this is just the iOS version. A cocos2d-x Mac project will be added as soon as the Mac platform is officially supported by cocos2d-x (or does it already and I missed that?). Then developers would have the choice between using either Objective-C or C++ as the primary language for developing their iOS & Mac OS X games.
It also made me think: “Hey, there’s this other open source 2d game engine … hmmm….”
I just completed this project for the new book chapter about embedding UIKit views/Cocoa Touch in a Cocos2D application. In that case I embedded the Cocos2D view in the View-based Application template and added some controls to start/stop the cocos2d view and change scenes. Here’s the result:
It also correctly auto-rotates. But I noticed an odd bug with auto-rotation enabled for all orientations: the view is designed in portrait mode. If I start the App on my iPod Touch 4 while holding the device in landscape mode, then rotate back to portrait mode once the app has started and enable the cocos2d view, for some reason this causes my device to reboot! I see a transparent white color drawn over the entire screen before the screen goes black and the Apple logo appears.
If anyone has any idea what might be causing this behavior, please let me know. As far as I debugged it is not the initialization of the EAGLView class itself, a scene is already running or about to be run.
I’m guessing it might have to do with the EAGLView initialization, since I rely on Interface Builder to initialize the view. I simply dragged a View object onto IB and changed the class from UIView to EAGLView. Maybe the EAGLView default settings are not supposed to be used and I do need to create the EAGLView manually?