Category: cocos2d-iphone

I’m about to embark on a collaboration with another developer. We want to create something new and fun. One of the first things to crop up is the tools that we use. In the interests of documenting what I use, I thought I’d write it as a blog post for all.

One of the amazing things about software development is that we developers can be very passionate about what we use, and how we use it. Some developers love getting their hands dirty by doing all the hard stuff themselves. Some like the ease of point-and-click programming (and there are some of that wouldn’t call that programming, but we’re probably being snobbish).

Me? I’ve been around long enough now to have got my hands dirty on a whole bunch of things over the years. I started out with AppleSoft Basic on an Apple IIe, and progressed through a whole suite of tools and languages until the Apple IIGS was discontinued in the mid-nineties. I could go on about those days and the years between then and the current “App” development wave, but that’s not what this post is about (if you want to hear more about the “good old days”, then let me know via comments; if there are enough then perhaps I’ll take a stroll down memory lane).

I won’t attempt to compare what I use against what others use here; this is simply a write-up of what I use, and briefly, why.

I would like to point out though that this post is probably best for other developers, or budding developers. I will use terms and jargon here and there that won’t mean much to non-developers.

Programming

Perhaps it’s something to do with my age and where I’ve come from, but I like coding by hand. Don’t get me wrong, I’m happy for an IDE (Integrated Desktop Environment) to do some simple stuff for me, but for a lot of it, I’m more than happy to type things out from scratch. The act of typing in code, even what might be template code to others, connects me with what I’m doing; it’s an opportunity to construct the tapestry as I work, to think as I type. Having a lot of it done for me means that typically, I’m allowing the tool to dictate limits and sometimes, it’s own design, on what I am creating. Coding by hand means that the limits are my own.

For iOS App development, my coding environment of choice is Apple’s Xcode. This is a terrific, free, IDE that comes with absolutely everything a developer needs to code an app and submit it to the App Store. Now I say everything, and it’s true, but in reality there are things like images, icons, sounds, documents, etc that also help to make up an app, and creation of those falls to other tools.

Apple has traditionally encouraged the use of Objective-C for all development. Most developers either love or hate Objective-C. I actually enjoy it as a language. When Apple introduced Swift in 2014, I was a bit surprised. I knew that lots of people don’t like Objective-C, but I didn’t think people would be so happy to see a replacement. Swift has so far managed to fail to capture my attention. I have no desire thus far to change; Objective-C works, and works well.

App User Interface

Apple, for the iOS environment pushes it’s own UIKit and I’ve used this in several of my apps. It works well, and it’s very powerful. I don’t however like to use UIKit for the educational apps, and games that I create. For these I have used Cocos2D. I’ve been using Cocos2D since it was version 0.99. It’s now up to version 3.3. Most of my educational apps use version 2.2 of Cocos2D, though future apps will most likely use version 3.3 or later.

This GIT repository contains an entire Cocos2D project that I put together to demonstrate the use of Apple’s Accessibility API in conjunction with Cocos2D.

Going forward, Cocos2D is now integrated into a new IDE called SpriteBuilder, which is freely available at: http://www.spritebuilder.com, SpriteBuilder provides a very powerful environment that allows you to design the UI of your app in a way that can be built for both iOS and Android. I have yet to test/try the Android side of things, but feedback from other developers who have used Apportable which has been integrated into SpriteBuilder, has been very encouraging.

SpriteBuilder creates, from your design, and entire Xcode project that you can then add code to, and build for submission to Apple. They integrate well, and the powerful thing is that once you open up the Xcode project, you can forget about SpriteBuilder if you choose and hand code the rest of the app. I really is, for me, a good blend of the two.

If I’m building a UIKit app, then I do everything in Xcode.

Code Management

When I first started working with Xcode, I used “cvs” to manage and control the various versions of my code. It worked well, but in the years since then, the development world has moved on. These days, the trendy choice is “git”, and for me, it’s a good choice. It works well in a local environment, and I’m able to set up remote environments so that I can easily backup my code to a file server, or the cloud.

For code version control using “git” I used SourceTree, by Atlasssian. SourceTree is available for free from: sourcetreeapp.com It’s a great tool, very powerful and integrates beautifully with a cloud based service called BitBucket, also by Atlasssian. I use BitBucket because I can create unlimited private repositories for free, and it’s very handy for sharing code with other team members. I use SourceTree on my Mac to manage daily commits of code, and then push those commits to the cloud or a file server periodically so that I have backups.

Artwork

For a lot of my apps, I’ve created most of my own artwork. Until late last year I did all of this using a free app called “GIMP“. It’s a great tool, and for people, like myself, who work on a very low budget, it works well. It’s cross platform and there’s even a version on iOS called ArtStudio (though they don’t call it GIMP, when you look at it’s feature set, and menu structure, I’m convinced that’s it’s built from a GIMP codebase).

With the new version of Money Up, I moved to the Adobe Creative Cloud suite, and Photoshop. Whilst I enjoyed GIMP and became proficient using it, I now really enjoy the power provided by Photoshop and the higher quality outputs achieved by using Vector based shapes for the drawings. GIMP is a raster based editor, and as such, is unable to export cleanly scaled images in the same way.

Sound and Music

Before I mention the tools I use on my Mac to edit sounds and music I want to mention two websites I use to source most of my sounds and music:

incompetech.com – This is a wonderful site by Kevin MacLeod who shares a vast library of his original royalty-free music. I’ve used a number of pieces from this site; the ability to browse using a terrific filter makes life much simpler.

freesound.org – This site is a powerhouse, full of sound recordings. Be careful to observe the licenses attached to individual recordings.

For most of my sound editing, I use Audacity, a free and yet, very powerful sound editor. When I needed to clean a large number of sound recordings for Money Up however, I used Audition CC, part of the Adobe Creative Cloud suite. For me, it’s not as intuitive as Audacity however it’s very capable, and some things are easier to do.

I always export my sounds as “AIFF” files, but I don’t use those within the apps that are submitted to Apple. Most apps don’t need high quality sounds, especially for simple sound effects. What I do, is run a short script over all of my “AIFF” files, to convert them to “CAF” files which take up less space, but still sound just fine on an iOS device.

>As part of the ongoing development of my current game project (using cocos2d-iphone), I recently found myself facing yet another clone of the code required to animate an object within a scene.

Whilst it’s so easy to just grab code, plonk it in and modify it to suit your purposes, it’s a good idea to stop yourself every now and then and assess the damage.

I was finding that the code was becoming untidy, and it was time to do some refactoring. So, having recognised that all of my animated sprites were essentially being created the same way, I set about creating my CCAnimatedSprite class which is a subclass of CCSprite.

What it does is provide an easy to use constructor (to borrow a Java term) that, given the “name” of the spritesheet that contains the images that make up the animation, sets up the sprite object , all ready to go. From there its very simple to request an action object that can be used on it’s own, or as a part of a more complicated suite of actions.

As part of the ongoing development of my current game project (using cocos2d-iphone), I recently found myself facing yet another clone of the code required to animate an object within a scene.

Whilst it’s so easy to just grab code, plonk it in and modify it to suit your purposes, it’s a good idea to stop yourself every now and then and assess the damage.

I was finding that the code was becoming untidy, and it was time to do some refactoring. So, having recognised that all of my animated sprites were essentially being created the same way, I set about creating my CCAnimatedSprite class which is a subclass of CCSprite.

What it does is provide an easy to use constructor (to borrow a Java term) that, given the “name” of the spritesheet that contains the images that make up the animation, sets up the sprite object , all ready to go. From there its very simple to request an action object that can be used on it’s own, or as a part of a more complicated suite of actions.

As it turned out, I didn’t end up using the class in my project, but it’s handy to have it around. At the moment it only uses textual menu items, but there’s no reason why it couldn’t be adapted to use other menu item classes.

As it turned out, I didn’t end up using the class in my project, but it’s handy to have it around. At the moment it only uses textual menu items, but there’s no reason why it couldn’t be adapted to use other menu item classes.