The Ultimate Cocos2D Project: Libraries

On March 4, 2011, in cocos2d, Kobold2D, by Steffen Itterheim

The Ultimate Cocos2D Project is: Kobold2D!

Put simply: Kobold2D is designed to make Cocos2D developers more productive.

Original Post

Last week I wrote that I’m Building The Ultimate Cocos2D Xcode Project. In today’s weekly update I wanted to give you some more details on the use of libraries in that project.

Cocos3D included

So there happens to be a Cocos3D now. Rather than being part of the Cocos2D distribution, it’s an extension project. Guess what that means? Right, installing Cocos3D means fumbling with the dreaded install-templates.sh script (see this Cocos3D tutorial). Of course the first user reactions were: how do I install it? Installation failed, what am I doing wrong? And so on …

The Ultimate Cocos2D Project wouldn’t be ultimate if it didn’t include Cocos3D out of the box. And unmodified of course, as with all included libraries I want to make it as simple as possible to replace one library version with another. Once you get to half a dozen of included libraries, maintaining them all can become a hassle, so the very least I can do is to make it easy for everyone to upgrade specific libraries.

Obviously: Cocos2D included

Of course Cocos2D is also included as a static library as opposed to cluttering your project with all of its source files. Xcode project references make it very convenient to add external code and keeping it seperate. I’ve described the process in detail in my Cocos2D Xcode Project tutorial but since then I’ve learned a couple more things about how to make this even better.

For example, I no longer include cocos2d-iphone directly, instead there’s a seperate Xcode project in between so that I have full control over build settings (using XCConfig files) and make it possible to build both iOS and Mac OS targets in the same Xcode project. I will also include the current version of Cocos2D in the download because my goal is to make everything work out of the box.

No fumbling with install scripts, no additional downloads necessary, no need to modify any Xcode build settings - including developer certificates and header search paths. Build configurations for Ad Hoc and App Store release builds are also included, which will create .IPA and .ZIP files for you ready for Ad Hoc distribution respectively upload on iTunes Connect.

Popular libraries included

Now let’s get to the juicy part. Early on I realized that Cocos2D users often needed (or wanted) to include other libraries. Some of them have become so popular among the Cocos2D crowd that they could as well be part of the official distribution. Alas, they’re not. That’s a service I want to provide.

Often those libraries require special and non-obvious steps to successfully add them to an existing project. All too often those steps are either undocumented, untested, hard to follow, refer to outdated versions of Xcode, iOS SDK, etc. and generally require technical expertise of project configuration and compiler settings.

This is all taken care of for you. Here’s the list of libraries that are already included in the Ultimate Cocos2D Xcode Project:

That is quite a list. All you need to do to use these libraries is to either enable them in code or merely include the header file and start using them. If you worry that all these libraries will bloat your App, rest assured that Xcode is very clever: if you don’t actually make use of a static library (eg don’t include any of its header files), it will not be linked with your App and not waste any space or performance. I verified that.

Update policy

These are a lot of libraries to keep up to date. I plan to make about 4-8 point releases each year, usually triggered by a major (speak: non-beta) release of Cocos2D. If updating other libraries justifies an update depends on the library’s importance and the significance of the update.

Your libraries

Adding your own libraries to the project will be easy and the process will be documented. This will encourage code-sharing because your library will just work with other user’s project, it only needs to follow a few simple guidelines to become plugin-capable. This opens the door for better and tighter integration of 3rd party code into your projects. Even if you don’t intend to share your code, you’ll still benefit because your code will be easier to re-use and maintain.

Also, if you like you can make a request for a specific library or additional source code that should be included in the project, please leave a comment. I’ll see what I can do. :)


This article was brought to you by ...

I very much enjoy the learning process, the pushing of boundaries (mine and yours and that of technology), having the freedom to pursue whatever is on my mind, to boldly program what no one has programmed before, and to write about what I've learned. Help me help you by browsing the products in the Learn Cocos2D Store.


Tagged with: • • • • • • • • • • • • • • •  

16 Responses to “The Ultimate Cocos2D Project: Libraries”

  1. Justin says:
    March 4, 2011 at 20:12

    Super cool. For each project, I was thinking that it might be better to bundle its static lib (.a) and its headers (.h) into a single, versioned, “static” framework. (see http://goodliffe.blogspot.com/2009/09/code-creating-framework-for-iphone.html )

    Any thoughts?

    • Steffen Itterheim says:
      March 5, 2011 at 10:52

      Frameworks will be useful if you have a commercial library and you want to share the framework for free and sell the source code.

      For the existing open source libraries that would create two problems: you no longer have source code you can step into because the framework is only a static library. And I would be solely responsible for updating each library, since creating a framework from a library is out of the question for most developers. I’d rather give them the ability to simply replace the folder with a new version of the library and unless there were substantial changes it should just work, or require little extra work (eg add new files to the project).

      • Justin says:
        March 10, 2011 at 23:16

        I guess I’m not understanding the implementation details. From your description I think you are saying that the “ultimate” project will have many library folders, and inside each library folder will be the entire source code for the given library. Furthermore, the project will have a whole bunch of static library targets, and the main project target will just include them as dependencies (but the default linker magic only includes them in the product if they are used). Correct?

        • Steffen Itterheim says:
          March 12, 2011 at 22:27

          Essentially that’s it. Each library is built to a static library and referenced in the main project. Additional code glues it together. The build settings are controlled via XCConfig files, so changes in build settings can be applied quickly and globally.

  2. Paris paraskeva says:
    March 5, 2011 at 07:32

    Wow! Nice work you have pulled off here again, I guess it’s yourmprevious template but now on steroids!

    If all these libraries are included by default will it make our binaries hevier? Or Xcode works out what is used and only includes used libraries?

    Thanks

    • Steffen Itterheim says:
      March 5, 2011 at 10:56

      On steroids it is. :)

      As I said, Xcode knows when a library is in use and when it is not. I have been adding all these libraries to the project, but the App size only changes when I actually make use of one of these libraries (including a header file in some cases is enough, in others you have to actually make calls to a function of the library). Furthermore I read that Xcode (respectively the GCC linker) even strips out the parts of a used library that aren’t needed for the app, but I haven’t verified that.

  3. Kyle says:
    March 5, 2011 at 20:54

    Totally awesome, you are a champion! Keep up the great work. This is escalating cocos to a new level!

  4. dm says:
    March 6, 2011 at 23:28

    And you do that with Xcode 4 of course? Sooner or later this will be the only Xcode we may use to submit apps to Apple.

  5. David Deacon says:
    March 7, 2011 at 17:29

    Sounds amazing!

    Could i suggest AdWhirl/AdMob library to go along with the iAd support.

    David

  6. Tim says:
    March 8, 2011 at 14:59

    Sounds great - when will it be available and how do i get it?

  7. Joe Glenn says:
    March 9, 2011 at 22:24

    Hey Steffen,

    How’s progress coming along? And when should we expect to see this final release?

  8. Andrey says:
    March 10, 2011 at 09:54

    Sounds cool!
    Box2D is missed I guess :-)

    • Steffen Itterheim says:
      March 12, 2011 at 22:24

      Well, Box2D and Chipmunk are both part of Cocos2D. But on closer inspection I realized they aren’t complete. For example, the Objective-Chipmunk demo is completely missing from the Cocos2D distribution. So I’m toying with the idea of simply creating separate libraries for those physic engines using the official distributions.