I’ve learned a lot about iPhone game programming, cocos2d for iPhone and Xcode, Objective-C and the Mac OS in the past year. I want to share my knowledge pertaining to cocos2d in specific and iPhone game development in general. I’ve created a completely new website dedicated to cocos2d over the last 2 weeks:
I made a 90+ (!) pages Tutorial about how to setup an Xcode project for professional work, including cross-referencing the cocos2d project, optimizing the build settings and adding targets for all platforms and purposes (eg debugging crashes). You can view the tutorial on my website or download it as PDF!
Since after 10 years in the game industry i’ve specialized in iPhone Game Development using cocos2d for iPhone i will always have something to say or add to this website. Let me know what you think and if you like it, please tweet it and recommend it to your peers, thank you!
I spent the last week creating a Xcode project template that uses the cocos2d for iPhone as cross-referenced project as it is obtained from git. I want to be able to branch off of a common base project using the source control software of my choice – Perforce – and also be able to update the cocos2d for iPhone game engine at any time for all of my future projects.
I think the feature list of that Xcode Project Template speaks for itself:
- cocos2d-iphone referenced by Project, allowing you to keep cocos2d-iphone up to date with the least amount of work
- 4 Build Configurations (Debug, Release, Ad Hoc Distribution and App Store Distribution)
- IPA Files automatically created for Ad Hoc Distribution builds
- ZIP Files automatically created for App Store Distribution builds
- Build Targets to build regular iPhone/iPod and iPad Apps in both Full and Lite Versions
- additional Build Targets to debug memory crashes effectively and running the Static Analyzer
- Preprocessor Macros to differentiate the different build targets in code
- Aggregate Target to build all your regular Targets at once
- properly configured precompiled Prefix Headers, reducing compile times
- supports both Physics engines: Chipmunk and box2d
- all build settings optimized for maximum performance and building quality code, taking into account Xcode’s Layered Build Settings
It gets better! I’ve actually made tutorial explaining each and every step in detail and explained some of the reasons and intricate details of Xcode Build Settings. I’m confident it’ll blow your socks off! This Tutorial combines everything useful that has ever been written about Xcode & cocos2d Project setup into one large Tutorial. And i can guarantee that it’ll work because it describes exactly how i created the Project Template i’m now using for my professional work.
Of course i will also share that Xcode Project Template. This is all content for my new Website which focuses on making games with the cocos2d for iPhone game engine. I hope to be able to reveal the website soon, until then you’ll have to be a little more patient. Please stay tuned and follow me!
For now i’d like to offer you a Teaser for this Tutorial: Git Setup for cocos2d for iPhone. Please do me a favor and do not link to this HTML file directly, instead link to this post, as i will remove the HTML as soon as the new website goes live. Also the HTML isn’t formatted properly, for a better result download the PDF version of the cocos2d Git Setup Tutorial. It contains the first 11 pages of the 93 (!) pages Tutorial!
There’s only one issue left that i just can’t explain: running the static analyzer only reveals results in Release builds but not in Debug builds. In Debug builds the analyzer analyses all files but doesn’t complain about anything. Not even after i temporarily replaced it with the latest version of the Static Analyzer as described in this tutorial. My post on Stackoverflow at least lead me to discover that it doesn’t have anything to do with GCC vs LLVM GCC but only with the Debug builds. I then compared the Build Settings of Debug and Release builds and other than the preprocessor macro DEBUG and RELEASE and of course optimization level they were identical. I still tried to make all Build settings identical to the Release build but no change. This is so weird. The command line scan-build analyzer works just fine but not with the Xcode built-in Build & Analyze. If you have any idea what could be causing this behavior please let me know! Otherwise i’ll probably have to live with analyzing only release builds respectively going back to the command line scan-build.
So, finally i needed to upgrade my Mac mini to the latest Snow Leopard OS to be able to develop apps for the iPad. Now i’ve heard before that the system update is really easy and quick. However, i’ve worked with computers and people for a long time, and they’re all Liars! People especially, as we all know from Dr. House.
But even before that i knew that people don’t really give good estimations about time or distance, unless they have really measured it themselves. Which, normally they don’t. They put the upgrade disc in, press upgrade, watch a TV show or play with the cat and when they come back – oh wow – it’s already finished, so it must have been quick. To give you a real-life example that i’m sure a lot of you will relate to, is when you ask people how much time it takes from here to get to there. Like, how far is it to the next Autobahn (german highway)? “Oh, that’s just 5 Minutes.” … but when i was driving that route every day and decided to watch the clock the best time i could achieve under the best of circumstances was 12 minutes. For some people, that’s still just 5 minutes of course. Especially if they just drive the route once a month, that little bit of underestimation doesn’t have a dramatic effect. It’s a different story if you’re “missing” those 7 minutes twice a day because it’s your way to work. Even worse if they say you can get from here to there in 30 minutes, when that time is only the time it takes you from here’s Autobahn access point to there’s Autobahn access point.
Now, luckily we don’t upgrade our systems every day but that also makes us prone to misjudgements, like the aforementioned “it’s really quick and painless” words about the Snow Leopard system upgrade. So i decided to clock how long it took me to upgrade my 2 GHz Mac mini with 2 GB – so certainly one of the slower in the Intel line of Macs but nevertheless surprisingly efficient to work with:
- 25 Min. – full system backup because you never (!) know
- 90 Min. – install Mac OS X Snow Leopard 10.6.0 from DVD
- 5 Min. – fix “where is System Events?” issue
- 5 Min. – Mail converting database
- 15 Min. – fix display issue (2nd Monitor not recognized, needed several reboots)
- 30 Min. – install iPhone SDK 3.1.3 for Snow Leopard
- 5 Min. – install iPhone SDK 3.2 beta for Snow Leopard – FAIL: requires OS Update
- 30 Min. – download & install Mac OS X 10.6.2 update
- 30 Min. – install iPhone SDK 3.2 beta for Snow Leopard
- 5 Min. – download & install another Mac OS system update
- 30 Min. – fixing broken Keyboard Layout of my german Microsoft Natural Keyboard
Now i’m good to go. The system update itself took 90 minutes which by itself isn’t really what i call fast for a system update, i was expecting more like 20-30 minutes at most to still consider it “fast”. But what many people often forget, as in live, in driving to the Autobahn, in installing systems and system updates and of course in Software Development are the “little details”. The things that we still need to do besides the big chunk to get where we want to. For example, the 12 minutes to the Autobahn makes 24 minutes a day but still many people only seem to count the 30 minutes you spend on the Autobahn itself – often than can be as little as 50% of your time spent driving! The same happens to software developers as well, forgetting about how much time it costs not to build the application but to test and polish it and fixing bugs before it can be released. That could also easily amount to 50% of your development time as well.
In case of this system upgrade, i count a total of exactly 4 hours 30 minutes until my Mac was in a state that i could continue working with it – assuming that i was always there on spot to issue the next step. I wasn’t, so those are rough times. Overall i started the process at 13:00 and was finished at 18:00 – an hour more and maybe i should count that as well. After all, what good are the optimum times if i’m not likely to achieve those? So 4 or 5 hours, that’s at least half a day’s work. In other words, depending on what hourly rate one takes, it created costs of somewhere between €200,- and €350,- (about $270 to $470). That’s neither fast nor cheap. I expected my system to be upgrading and installing for 2 hours – i totally underestimated. In part because i probably heard too many people say “it’s fast and painless”.
Next time, do all of us a favor, and take measurements!
Regardless of whether you make statements about how long the Snow Leopard system upgrade took, how long it takes to get to the Autobahn, or from A to B, and how much time you spent developing this piece of software. Of course, if you could provide us with a frame of reference, that would be great! Your system specs for example, or the kind of car you drive, which route you take and what your driving style is. Or, how experienced your team is in developing that kind of software, how long they’ve been working together and what processes are being used.
But, those are just details, right?
Hi And Welcome!
Recent Comments