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.
Xcode is freely available from Apple at: https://developer.apple.com/xcode/downloads/
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.
If you want a copy of the Cocos2D version (based on v2.2) that I use, visit: https://pkclsoft@bitbucket.org/pkclsoft/accessiblecocos2d.git
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.
To build an app starting from SpriteBuilder, for both iOS and Android, you will need the Apportable Xcode plugin, available from: https://store.spritebuilder.com/products/spritebuilder-android-plugin-starter
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.
This script comprises:
#/bin/sh
FILES=`find . -name \*.aiff`
for F in $FILES;
do
DF=`basename -s .aiff ${F}`
echo "Converting ${F} to ${DF}.caf"
afconvert -d aac -f 'caff' -b 65536 "${F}" "${DF}.caf"
done;
Video Creation
I’ve previously written here about how I create my App Preview videos. Here is a link: http://www.pkclsoft.com/wp/creating-an-app-preview-my-way/
>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.
So, to create an animated sprite, all you need is:<
CCAnimatedSprite *animSprite1 = [CCAnimatedSprite nodeWithSheetName:@"anim" andFrameCount:15];
What this does is create a CCSprite object that contains all the information it needs to animate 15 frames from a spritesheet called “anim_sheet.png”.
So, for this animated sprite there are two files it expects to find:
- “anim_sheet.plist” which is a standard cocos2d spritesheet description file.
- “anim_sheet.png” which is the spritesheet itself.
As you may have guessed, the names of the files are constructed using the sheet name passed into the constructor.
In additon to this, each frame within the animation is expected to have a name that takes the form:
<sheet name>_%02d.png
So this effectively means the animation will support up to 99 frames, where each frame name begins with the sheet name. Using the example above, a 5 frame animation would contain frames called:
anim_01.png
anim_02.png
anim_03.png
anim_04.png
anim_05.png
To use the animation, it can be as simple as:
CCAnimatedSprite *animSprite1 = [CCAnimatedSprite nodeWithSheetName:@"anim"
andFrameCount:15];
[animSprite1 setPosition:CGPointMake(300.0, 257.0)];
[self addChild:animSprite1 z:10];
[animSprite1 animate];
where the call to [animSprite1 animate] essentially tells the animation to run forever.
If you need to embed the animation within a suite of actions that have the sprite moving on the screen in some fashion, you can use the “animationAction” method to get a CCAnimate action object:
CCAnimatedSprite *animSprite2 = [CCAnimatedSprite nodeWithSheetName:@"anim"
andFrameCount:15];
[animSprite2 setPosition:CGPointMake(20.0, 157.0)];
[animSprite2 setScale:3.0];
[self addChild:animSprite2 z:10];
[animSprite2 runAction:[CCRepeatForever actionWithAction:
[CCSpawn actions:
[CCRepeat actionWithAction:[animSprite2 animationAction] times:6],
[CCSequence actions:
[CCMoveTo actionWithDuration:2.5 position:CGPointMake(880.0, 157.0)],
[CCMoveTo actionWithDuration:2.5 position:CGPointMake(20.0, 157.0)],
nil],
nil]]];
You can get the code and a very simple sample project from: http://www.pkclsoft.com/downloads/AnimatedSprite.zip
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.
So, to create an animated sprite, all you need is:<
CCAnimatedSprite *animSprite1 = [CCAnimatedSprite nodeWithSheetName:@"anim" andFrameCount:15];
What this does is create a CCSprite object that contains all the information it needs to animate 15 frames from a spritesheet called “anim_sheet.png”.
So, for this animated sprite there are two files it expects to find:
- “anim_sheet.plist” which is a standard cocos2d spritesheet description file.
- “anim_sheet.png” which is the spritesheet itself.
As you may have guessed, the names of the files are constructed using the sheet name passed into the constructor.
In additon to this, each frame within the animation is expected to have a name that takes the form:
_%02d.png
So this effectively means the animation will support up to 99 frames, where each frame name begins with the sheet name. Using the example above, a 5 frame animation would contain frames called:
anim_01.png
anim_02.png
anim_03.png
anim_04.png
anim_05.png
To use the animation, it can be as simple as:
CCAnimatedSprite *animSprite1 = [CCAnimatedSprite nodeWithSheetName:@"anim"
andFrameCount:15];
[animSprite1 setPosition:CGPointMake(300.0, 257.0)];
[self addChild:animSprite1 z:10];
[animSprite1 animate];
where the call to [animSprite1 animate] essentially tells the animation to run forever.
If you need to embed the animation within a suite of actions that have the sprite moving on the screen in some fashion, you can use the “animationAction” method to get a CCAnimate action object:
CCAnimatedSprite *animSprite2 = [CCAnimatedSprite nodeWithSheetName:@"anim"
andFrameCount:15];
[animSprite2 setPosition:CGPointMake(20.0, 157.0)];
[animSprite2 setScale:3.0];
[self addChild:animSprite2 z:10];
[animSprite2 runAction:[CCRepeatForever actionWithAction:
[CCSpawn actions:
[CCRepeat actionWithAction:[animSprite2 animationAction] times:6],
[CCSequence actions:
[CCMoveTo actionWithDuration:2.5 position:CGPointMake(880.0, 157.0)],
[CCMoveTo actionWithDuration:2.5 position:CGPointMake(20.0, 157.0)],
nil],
nil]]];
You can get the code and a very simple sample project from: http://www.pkclsoft.com/downloads/AnimatedSprite.zip
>A short time ago I was working on a scene within a new game I’m writing. This scene required the display of a variable length list of items that could be tapped.
I soon found that the CCMenu class didn’t really support the concept of scrolling, and after much hunting around I decided that I’d have to do it myself.
The end result is a small, reusable class that accepts 4 parameters:
- The name of a background image.
- The name of a foreground image.
- A CGRect that defines the area within which the menu will appear.
- An array of NSString objects that form the menu item labels.
The code to create and display a menu is as simple as:
- (void) showScrollingMenu:(CCMenuItemLabel*)item {
ScrollingMenuScene *ns =
[ScrollingMenuScene nodeWithForeground:@"foreground.png"
andBackground:@"background.png"
andRect:CGRectMake(50.0, 40.0, 200.0, 260.0)
andItems:[NSArray arrayWithObjects:
@"First", @"Second", @"Third", @"Fourth",
@"Fifth", @"Sixth", @"Seventh", @"Eighth",
@"Ninth", @"Tenth", @"Eleventh", @"Twelfth",
@"Thirteenth", @"Fourteenth", @"Fifteenth", @"Sixteenth",
@"Seventeenth", @"Eighteenth", @"Nineteenth", @"Twentieth",
nil]];
[[CCDirector sharedDirector] replaceScene:ns];
}
To achieve the appearance of a scrolling menu, the class places the background at the bottom, a layer above this containing the menu, and the foreground image on top.
It is assumed that the foreground image has a transparent “window” that matches the rectangular area defined by the CGRect parameter.
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.
A short time ago I was working on a scene within a new game I’m writing. This scene required the display of a variable length list of items that could be tapped.
I soon found that the CCMenu class didn’t really support the concept of scrolling, and after much hunting around I decided that I’d have to do it myself.
The end result is a small, reusable class that accepts 4 parameters:
- The name of a background image.
- The name of a foreground image.
- A CGRect that defines the area within which the menu will appear.
- An array of NSString objects that form the menu item labels.
The code to create and display a menu is as simple as:
- (void) showScrollingMenu:(CCMenuItemLabel*)item {
ScrollingMenuScene *ns =
[ScrollingMenuScene nodeWithForeground:@"foreground.png"
andBackground:@"background.png"
andRect:CGRectMake(50.0, 40.0, 200.0, 260.0)
andItems:[NSArray arrayWithObjects:
@"First", @"Second", @"Third", @"Fourth",
@"Fifth", @"Sixth", @"Seventh", @"Eighth",
@"Ninth", @"Tenth", @"Eleventh", @"Twelfth",
@"Thirteenth", @"Fourteenth", @"Fifteenth", @"Sixteenth",
@"Seventeenth", @"Eighteenth", @"Nineteenth", @"Twentieth",
nil]];
[[CCDirector sharedDirector] replaceScene:ns];
}
To achieve the appearance of a scrolling menu, the class places the background at the bottom, a layer above this containing the menu, and the foreground image on top.
It is assumed that the foreground image has a transparent “window” that matches the rectangular area defined by the CGRect parameter.
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.