Acorn Heroes

I’ve recently been trying out Testflight as a method for getting beta builds out to testers.  Testflight handles a number of things for you – over the air distribution of builds, notification e-mails, download stats and more.  It’s a great system, but my first thought when I started experimenting with it was: “Can I incorporate it into my build system?” Fortunately the answer is yes, in fact it’s dead easy.  Let’s see how it’s done…

Setting up…

I won’t go into all the details of setting up a Testflight account, it’s fairly well covered on the site.  What you will need to do is set up one or more ‘teams’ for beta testing.  Once you’ve done this, it’s time to investigate Testflight’s upload API.

Automated uploading

Most pages on the Testflight site have a set of links at the bottom, one of which is ‘Upload API’.  This page gives details of how you can upload a build programmatically.  You’ll need to find a few details – an api token and a team token.  Both of these can be found by following links off the Upload API page.  Once you’ve got these, we can use curl to handle the communication with Testflight .com:

curl http://testflightapp.com/api/builds.json 
  -F file=@yourapp.ipa 
  -F api_token='your_api_token' 
  -F team_token='your_team_token' 
  -F notes='This build was uploaded via the upload API' 
  -F notify=True 
  -F distribution_lists='Your Team Name'

And that’s all there is to it!  I’d recommend trying this from the command line until you’re happy that builds are uploading correctly, then simply drop this command line into your build system as a final build step.

I’ve been using this for a while and it works well.  The first time you create a build, your testers receive an email – if they read the email on their device, they’ll get instructions for setting up Testflight on their iDevice.  Having done this once it becomes a one click process for testers to get new builds.  Not only that, but you as the team leader will know who has downloaded the build, and on what device!

Just a few of issues…

Overall I’m really happy with Testflight as a system.  There are some things to be aware of though:

• Testflight only works on newer devices / OS versions (4.0 and later, I believe).
• I’m not clever enough to interpret the results of curl to determine if an upload fails, so currently I get a ‘build succeeded’ even if the upload fails.  If anyone can offer some advice on how to do this, I’d appreciate it.

I hope you find this useful – I know I do – one click to go from Source Control to having a new build in tester’s hands?  Magic.

In which George puts together the beginnings of a rendering system, trying to leave his bad Open GL habits behind him.

Bad Habits

It’s true.  I have been known to write bad Open GL code.  By bad I mean simple, immediate mode code.  I learnt GL programming on SGI machines that cost a fortune and weighed more than me.  In this world, writing rendering code was fairly simple – call glBegin(), pass a bunch of vertices one at a time and call glEnd() when you’re done.  Need things to run a bit faster?  Wrap it in a call list.  It was easy and fast enough for most situations.

What this style of programming tends to lead to is having drawing calls and GL state changes littered throughout the code base.  It is simple, but it can also be confusing, particularly when it comes to changing GL’s state – blending modes, enabled vertex arrays and so on.  GL has a lot of different state variables, and if you forget to return one to its expected value life can get interesting in unexpected ways.

With the move to Open GL ES v2.0 (GL v2 from here on), it seemed like a good time to kick a few bad habits.  Along the way, the plan was to create a more flexible, efficient and reliable rendering system.

Something to aim for…

After some thought, I came up with a some goals that described what I wanted to achieve:

• I’m sick of managing GL’s state ‘by hand’.  I want to be able to say ‘this effect needs these states set’ and rely on the underlying system to handle this efficiently and automatically.
• Drawing calls should be combined into batches automatically.  Especially in a 2d sprite based renderer, made up of lots of small elements, this is extremely important and can have a huge impact on rendering speeds.
• Draw calls should be sorted to render correctly (back to front in general) and also to minimise state changes.
• Component-based techniques should be used to lay out data for best memory usage (minimising cache misses).
• Shaders should be highly configurable (and also the meshes that they render).
• High level game objects should have full control over specific details  - do they use physics or not, do they consist of one sprite or many, what shader do they use and so on.

10,000 foot view

After a few days holiday last week, things are starting to come together.   GL v2 is a streamlined beast.  There is no fixed function pipeline at all – no matrix stack, no lights – we have to provide it all in the form of shaders.  This freedom is wonderful and extremely powerful.  It also requires a lot of bits to fit in place before you get that first triangle on screen.  I’ll try to give a general overview of how things fit together.  The system is built on three main ideas – effect files, aggregating components and delayed render calls.

Effect Files

The idea behind an effect file is simple.  It should contain all the information we need to render a mesh.  In GL 2 terms, we need a vertex and fragment shader at a minimum.  I’ve also added state information such as textures used, blending mode, cull mode and so on.  These are all stored in a single file and retrieved / parsed using Philip Rideout’s glsw code.

Components

There’s a lot of great, detailed articles out there about component based engines.  This isn’t one of them.  But the basic idea is this.  Let’s say our Elephant game object needs to move with gravity (he’s sky diving) and respond to collisions (he may forget to open his parachute) He’ll also be rendered with four sprites (body, head, tail and hat) and a particle system (he farts a lot).

We could store his position, velocity, sprite data and so on all in one structure, but this can lead to inefficient memory use.  Instead, we build a game object out of components of different types (physics, sprites etc).  The elephant game object contains references to a physics component, sprite components and a particle system component.  All our physics components are stored in a single contiguous chunk of memory, sprites are stored in a similar large array as are the particle systems.

Why is this a good idea?  Just ask Mike Acton.

Delayed Render Calls

Rendering efficiently on modern graphics hardware requires that we reduce the number of state changes and drawing calls to a minimum.  One way to do this is to batch up similar individual elements into a single mesh.  To do this, each graphical element has a ‘key’ value that gets added into a big list, which is then sorted using qsort().  The key is created based on the element’s depth in the scene, the effect used to render it and so on.  Christer Ericson describes this idea brilliantly.

What does this do?  It allows us to iterate over all our rendered elements once, adding them to the list.  After sorting, the elements are not only ordered for correct rendering, they are also clumped into groups of similar elements, allowing us to avoid unnecessary state changes.

The Main Loop

Glenn Fiedler has a great article on setting up your main game loop to best handle physics calculations.  The guts of his discussion is that you should always ‘step’ forward your physics calculations using a fixed time step, even if this doesn’t match the amount of time that’s passing in between frames.  This means that for a given frame, we may step forward our physics simulation once, twice or more.

Let’s take an example.  Suppose that since the last frame 25 ms has passed.  If our physics time step is 10 ms, we advance the physics simulation twice (20 ms) but what do we do with the extra 5 ms?  If we stop at two physics steps, or go for three, we’ll get stilted, jerky animation.  Glenn’s answer is to take the third step, but then interpolate between the second and third step.  Glenn explains it much better than I can at 10 minutes to midnight so go read his article.

Here’s an example of what my main game loop ends up looking like:

void GameUtils::Update(Game &game, float deltaTime)
{
    if (game.state.isInProgress && !game.state.isPaused)
    {
        if (deltaTime > 0.25)
        {
            deltaTime = 0.25;	  // Keep deltaTime from spiking
        }

        game.loop.accumulator += deltaTime;

        // Update physics
        while (game.loop.accumulator > game.loop.dt)
        {
            game.state.gameTime += game.loop.dt;
            PhysicsUtils::Step(game.physics, game.loop.dt);
            game.loop.t += game.loop.dt;
            game.loop.accumulator -= game.loop.dt;
        }

        // Interpolate physics state...
        PhysicsUtils::Interpolate(game.physics, GameLoopUtils::GetAlpha(game.loop));

        // Update all game objects here, including updating sprite positions based on
        // physics data.

        DrawOrderList drawList;

        // Add all sprites to draw list
        const Sprite *spritesArray = game.sprites.list.Data();
        for (int i = 0; i < game.sprites.list.count; ++i)
        {
            const Sprite &s = spritesArray[i];
            unsigned int key = DrawOrderUtils::CreateKey(s.layerId, game.sprites.componentId, s.effectId);

            DrawOrderUtils::Add(drawList, DrawOrderElement(key, &s));
        }

        // Likewise add particle systems and text...

        // Finally, sort and render in batches...
        DrawOrderUtils::Sort(drawList);
        RenderComponentUtils::Render(drawList);
    }
}

But wait, there’s more!

Actually there isn’t, at least not this time.  There’s a lot of detail I’ve missed, far too much to pack into a single post.  Hopefully I’ve given an overview of how the system works.  Next time I’ll concentrate on one part of the system and describe it in more detail.  If there’s one aspect in particular you want to know more about, or that needs better explanation, please let me know in the comments below!

In which George tries something new, is impressed, but still insists on doing things the old fashioned way…

OpenGL 2.0 – An apology

OK, let’s get this out of the way.  I haven’t got very far with the shader / GL v2.0 side of things.  However I have been busy.  My current day job is teaching a summer school course at the local University.  I’m lucky enough to get to teach Game Design.  For one of the lectures I wanted to do a case study of a commercial engine.  Unity seemed like a good choice, mainly because it’s cheap, reasonably powerful and cross platform – good options for budding game makers.  So rather than working on game code for Faerie I’ve gone back to prototyping ideas with Unity.  And it’s been great fun…

Getting Started with Unity

If you haven’t seen or heard of Unity before, here’s a quick run down.  It’s a cross platform engine that runs on PC, Mac, Web, iOS and most consoles.  It consists of an editor that is reminiscent of a 3d modelling package crossed with a programmer’s IDE.  Game Objects are dragged into the scene and arranged, terrains and vegetation can be added.  Game Objects in Unity work using a component model.  In other words, a ‘car’ as such is just a collection of components that each do their own thing – mesh, mesh renderer, physics collider, particle systems, transforms and so on.  These objects can also be built into hierarchies – a car and its wheels for example.

So far so good, but how do we write our game logic?  One type of component is a script component.  You can work in Javascript, C# or a version of Python.  Each script has a number of predefined hooks that let you interact with the game world.  The two main ones are Start() and Update(), which let you control initialisation and per-frame logic.  Other hooks include responding to collisions, handling mouse events and so on.  There’s a lot of power in this very simple system, as code typically sits alongside the object it acts on.  Variables declared as public become visible in the IDE, making tweaking game play trivial.

Getting started though is something that, for a coder like me, felt very strange.  The Unity site comes with a great collection of detailed tutorials that show off a lot of the engine’s power.  And this was part of my problem getting started.  The tutorials tend to mainly be of the “Here’s a mostly completed game, now let’s add some more stuff” variety.  Going through these you don’t really get a solid understanding of how things fit together, simply because there’s so much there.

Eventually though, I did find one tutorial on scripting that started from an empty scene.  From there, I was able to get to grips with adding one thing at a time.  After this, things started to fall into place and I found it much easier to make some progress.  There’s a lot of reference material on the Unity site – take your time to sift through it and find the tutorials that work for you.

Prototyping Faerie

Once I had a basic grasp of what was going on, it was time to build a prototype of Faerie.  One thing that Unity is very good at is prototyping – adding objects into a scene and attaching simple scripts to them is very straight forward.  User input, selecting objects and collision detection is all handled for you, leaving only the actual game logic to be written.

Faerie’s made up of a surprisingly small set of objects.  We have a collection of differently coloured leaves falling down the screen, which can be joined into a chain by tapping on them.  Complete a chain before it touches the ground and you score points and also fill up a ‘magic’ meter.  Miss enough leaves, or have a chain hit the bottom of the screen and your magic meter drops down.  If it hits 0, then it’s game over.  Fill it up and the combo / power up magic starts to happen.

Fumbling my way through the Unity API it took me about half a day to get the basic game play up and running.  Here’s a couple of screenshots, taken as I went.

Obviously it’s very primitive, but the basic game mechanic is in there and it feels fun.

After a little tweaking of variables to get the basic balance of the game reasonable, I packaged up a build and sent it to Sam for his thoughts.  Then followed a fairly lively Skype conversation regarding what needed to be fixed.  One thing that becomes very obvious when you do this sort of prototyping is that feedback for the user is not a luxury, it’s essential – even at as early a stage as this.  When the game world is made up of red and green rectangles the player needs every possible help to know that their actions are having an effect.

Tomorrow’s job is now to take Sam’s ideas and mine and work them back into the prototype.  This should be pretty fun as it involves trying different types of power ups.  There will be a few standard ones (slow down time, score extra points etc), but I’m keen to try out a few fun ones, like auto-chaining or perhaps something to do with Unicorns.  Definitely something to do with Unicorns.

Production Code with Unity?

So it’s probably fair to say I’m pretty happy with Unity.  It’s a well put together system and well worth a look.  I’ll definitely do a lot of prototyping with it.  But for production code I’ll still go with C++ and OpenGL for now.  Maybe I’m a masochist, but I like to know the specifics of what my code is doing, and to have the ability to tweak at the low level.

In which George shows off some really ugly screens, ponders OpenGL and answers an important question…

Screens!

I mentioned in a previous post that one of the first things I like to do when starting a new project is get the basic flow from screen to screen sorted out.  First off, I looked around at games I enjoyed to see what they do well.  In particular I’d like to let the player jump straight into the game with the minimum of fuss.  Ninjump, one of my current favourites, is a good example to copy here.  The main menu has three buttons that let you jump straight into a game (there are three different game modes).  Also, I like their pause screen, which only has two options: resume or main menu.  So without further blather, here’s the first draft…

The first screen is the loading screen, using a placeholder image.  It gives you an idea of an effect I want to use in game – the background scene is initially grey and lifeless.  As the player starts stringing together chains and combos, splashes of life come into the background, adding colour and excitement as the player does well.  The main menu has three large buttons, one for each game play mode:

• Survival mode – keep going for as long as you can, score as many points as you can.
• Time Limit mode – much like the Sprint mode in Linkoidz , the aim here is to score as many points as possible in a set time frame – great for people who love scoring mega-combos.
• Challenge mode – this one is a little less defined, but will probably require the player to get specific combos in a given time.  If they can get the required chain(s), they get a time bonus to keep going.  There’s still plenty of room to re-think this idea later.

Now I know that previously I’ve talked about a minimum viable product.  So why include three game modes?  The simple answer is that if I’m to have a free version of the game, then the full version has to add something extra.  Hence three game modes instead of one.  However, while the modes are reasonably distinct from a gameplay point of view, there’s not a lot of difference in them from a coding point of view.  So I’m hopeful that for a small amount of work I can significantly increase the game’s value from a player’s point of view.

Otherwise the main menu is fairly standard.  The new ticker will incorporate ideas from a great post by Markus.   All of the extra screens (options, help etc) will be single page screens with a back button to return to the main menu.  In each screen, the brightly coloured background is an OpenGL view.  The current plan is to use this to render subtly animated backgrounds for all the screens.

All of these screens are implemented using standard UIKit views and controllers.  I have an overall controller that maintains a stack of screens, and new screens can be pushed on to the stack, the current screen can be popped or a new screen can replace the existing stack.  It’s a nice simple mechanism, but it means I can, for example, have a settings screen that can be reached from the main menu or the pause screen, and when the settings screen is closed it can just ‘pop’ itself leaving the original screen behind.  While none of the screens are in any way pretty, they’re functional so I can hook in more detail as we go.  Next up though it’s time to get some basic rendering code up and running…

OpenGL v1.1 or v2.0?

So last week I said I would need to decide between the two possible versions of OpenGL.  Supporting both is a headache I don’t need, so it’s one or the other.  In the end, I’ve chosen to go with 2.0, for the following reasons:

• I’m planning to support only iOS 4.0 and up, simply to keep things under control.  I’ve read recently that the number of devices running older versions of iOS is surprisingly small – maybe 10%.  By supporting only iOS 4, there is potential to use lots of useful frameworks – Accelerate, gesture recognizers, Game Center and so on.  It also means that most of the target devices will support OpenGL ES v2.0
• I have a lot of experience with ‘old school’ OpenGL, but far less with shaders.  This is something I want to learn more about.
• I’m a programmer, not an artist.  By using a shader based engine, I have the opportunity to use my technical skills to give me an edge over purely sprite based games.  It’s a chance to produce a look and a style that can’t easily be matched with simpler sprite based engines.
• There’s a number of cool effects I have in mind that will be difficult to implement with a fixed function pipeline.  I plan to revel in the freedom 2.0 gives me like a pig in muck.

Ok, so maybe there are more rational arguments that could be made in favour of using 1.1, but in this case my personal motivation will be much higher using a shader based renderer.

I’m hopeful that by next week I can share some of my initial progress with the new OpenGL.  There’s a lot more to do before I can get pixels on screen and I’m learning as I go, but a basic plan of attack is starting to form in my mind.

And finally, what does success mean to me?

Noel asked me an interesting question after my first post:

I tried to answer in 140 characters or less, and failed miserably, so here’s a more detailed answer, split into two parts.

Financial success

Sam and I set up Acorn Heroes as a part time business outside of our day jobs.  This has obvious disadvantages in terms of time available, but it removes the absolute necessity of covering our mortgages through App sales alone.  Which is good, looking at our current sales to date  So financial success for us isn’t just a matter of surviving as Indies, it’s more of a sliding scale:

• Level One – Not failing.  The first level of success is just to reach the finish line and publish Faerie.  Of all the levels of success, this is the most important!
• Level Two – Pocket Money for gadgets! The second level is about making enough money to cover our costs (web hosting, developer’s license) with enough left over to, say, by an new iDevice each, or perhaps new MacBooks.  So we’re talking about a few thousand dollars in app sales.  With a bit of a nudge we should hit this mark this year.
• Level Three – Successful enough to up our game. We are a 2 person team, and unfortunately we’re both programmers.  We’re fortunate enough to know some great artists and designers, but not yet successful enough to afford to pay them.  Having enough money attached to a project to cover outsourcing art, design and music tasks would be a huge boon.
• Level Four – Financial freedom! Every Indie’s dream, the chance to work on your own project’s without worrying where the next meal is coming from.  Making enough in sales to cover a year or more in terms of salary.  Anything beyond this is gravy.

But money’s not everything, which brings me to…

Personal success

One of the main reasons I started working on my own iDev projects is that writing software for other people can get a little tiresome.  I was well into my thirties and the idea of making the software I want to make and selling it to and interacting with the end user directly has a huge appeal.  So in terms of personal success…

• Level One – Not failing.  See above.  That first copy sold to a person I don’t know yet is a wonderful ego boost to a man with my insecurities.
• Level Two – Positive feedback. An extension on the first level is when I get a chance to have positive interactions with customers, either through twitter, reviews or email.
• Level Three – Critical Acclaim. Receiving a positive review in the press, particularly from the likes of Touch Arcade, Kotaku or TUAW would be a defining “We’ve made it” or “We can do it!” moment.
• Level Four – The “You did this? effect. I think for me the ultimate success would be knowing that tens of thousands (or more) people had bought my game and were playing it often.  The  best part would be the moment someone I’ve just met shows me their favourite game, and it’s the game I wrote.  For me, professionally, I think that would be a highlight.

So I hope that answers your question Noel!  I guess my sense of success comes from having the freedom to make games at all.  From there on it just gets better.  Faerie is built around a theme and game mechanic that should have reasonably wide appeal.  Really now it’s just up to me to implement it well and get the word out there.  As one of my friends like to say, “It’s all over bar the typing”…

In which George lays out his initial project structure with the best of intentions, knowing full well that it’ll get all messy one way or another…

Every journey begins with a single step…

Yes I have been working on Faerie on and off for a while now, but this week marks the writing of the first actual lines of production code.  It’s an exciting time.  You have a blank canvas on which you can paint wonderful, clean, elegant and powerful code.  At least that’s how it starts.  Over time entropy, corner cases and flaws in your initial design have a tendency to muddy the code base.  But for now there’s wonder, cleanliness, elegance and the potential for power.

So where do we start?  For me it begins with the layout and structure of the project.  If you’re not a coder, you may want to skip all this technical stuff – I won’t be offended!  If you are a code nerd like me, perhaps this will be interesting to you, or maybe you can see flaws in the way things are laid out, or would like to share how you set up a project.  I’d love to hear what you think!

Stay on target!

The Faerie codebase contains four targets (at least for now).  The first target is the actual Faerie project.  It builds the Faerie app.  This target contains all the resources we use – textures, sounds and music, string resources, nibs and the like.  However this target contains virtually no code, just main.mm.  Why is this?

The answer is unit testing.  All the game code goes into a static library with the exciting name of GameLib.  By putting the code into a static library, it’s possible to unit test all the game code.  And it’s unit testing that comprises the other two targets in my project.  One is a static library containing the the UnitTest++ framework, and the last is an executable target that links the UnitTest++ framework, GameLib and all out test code.  I’ve described this set up previously if you’re interested in the details.  The advantage of setting up the code this way is that our actual app doesn’t need to include any testing code, yet we are able to test the exact library that is used in the game itself.  So the target structure looks like the image below.  Note the final step in the Faerie target, which runs the GameLibTests executable with every build – very handy!

There is one issue we need to address however.  Our nib files need to be in the Faerie target to ensure they’re included in the app itself.  And for testing purposes, all the view controller code is in the GameLib library.  This causes a problem because the linker doesn’t know that it should get the view controller code from GameLib, and so we get errors when the nibs are constructed at run time.  To fix this, it’s necessary to add the following to our “Other Linker Flags” setting for the Faerie target:

-force_load "$(BUILT_PRODUCTS_DIR)/libGameLib.a"

What about the code?

I find it very hard to create a new project from scratch, so I start with the OpenGL template and rip out the stuff I don’t want and reorganise the rest into a layout that suits me  Here’s the basic layout:

These groups in XCode are matched with an identical file layout on disk.  XCode doesn’t require this, but I find it too confusing if they differ.  As you can see, the Faerie folder contains basically no code.  It’s GameLib that has all the good stuff.  Acorn is all the standard code I carry from project to project – code to handle maths, loading textures, playing sounds and more – all that low level stuff.  GameLogic gets all the game specific code, and Views contains all the view controllers for my nib files.  Why the split between GameLogic and Views?  The main reason is that my view controller code is (by necessity) largely Objective-C, while the rest of my code is (as much as possible) pure C++, so it seems reasonable to keep them apart.

The Resources folder contains all the game assets, sorted by type and/or purpose.  By the time the game is done, there’ll be a lot of folders and a lot of files in here, so it’s good to keep them organised.

A simple trick to add a little polish

Here’s something truly simple that you can do in any app for a little extra style.  On startup, our app shows Default.png (or equivalent), and then once the main view is loaded it ‘cuts’ straight to the main view.  Wouldn’t it be nicer if we could smooth out that transition?  It turns out it’s easy to do.  Simply add a UIImageView to your main window, sitting above everything else.  The UIImageView should fill the screen and contain Default.png.  So what happens is that the main app loads and seamlessly replaces the loading screen with an identical screen, but one that we have control over.

Then, it’s a simple case of fading our Default.png image out, revealing the main view underneath, using a bit of code like this in your update loop:

float deltaTime = (float)gameClock->GetFrameDuration();
if (!loadingDefaultView.hidden)
{
    defaultViewFadeOut -= deltaTime / fadeDuration;

    if (defaultViewFadeOut < 0.0f)
    {
        defaultViewFadeOut = 0.0f;
        loadingDefaultView.hidden = YES;
    }
    else
    {
        loadingDefaultView.alpha = defaultViewFadeOut;
    }
}

*UPDATE*

Miguel, the mighty @mysterycoconut pointed out that this could also be done using standard animation calls in UIKit, so here’s an alternate version that gets executed in the viewDidAppear method…

- (void)hideLoadingDefaultViewDidStop
{
    loadingDefaultView.hidden = YES;
}

- (void)viewDidAppear:(BOOL)animated
{
    if (!loadingDefaultView.hidden)
    {
        [UIView beginAnimations:@"Hide loading screen" context:nil];
        [UIView setAnimationDuration:fadeDuration];
        [UIView setAnimationDelegate:self];
        [UIView setAnimationDidStopSelector:@selector(hideLoadingDefaultViewDidStop)];
        loadingDefaultView.alpha = 0.0f;
        [UIView commitAnimations];
    }
}

So what’s next?

I think after all this generic setup, it’s about time to add some actual game code, right?  Well the first thing I like to get going in a project like this is the flow from screen to screen, so that’s the next job on my list, adding the nibs and view controllers for the main menu, game, pause screen, credits and so on.  It won’t be pretty, but the aim is to get all the required buttons and such in place and working so that I can navigate around the app.  I find this to be a nice psychological stage to reach because, once done, I have a ‘complete’ app, and all I have to do is fill in the gaps!

After that, I need to make a key decision – OpenGL ES v1.1 or 2.0?  I think that 2.0 will win out, but I’ll delay that decision for another post!

A beginning is a very delicate time.

Know then that it is the year 2011.  The mobile space is ruled by the App Store.  In this time, the most precious substance in the Appverse is a successfully implemented game idea.  A successful App extends the Indie lifestyle.  A successful App expands possibilities and opens doors.

Ok, I think that’ll do, enough butchering of a great movie.

I have previously talked about my game-in-waiting Faerie.  Currently, Faerie is a simple game mechanic that has been prototyped and ‘just’ needs to be turned into a finished game.  Starting things has never been a problem for me.  But seeing them through to the end is a lot more difficult.  And so I have a plan.  A plan so cunning you could put a tail on it and call it a weasel.

The Plan

1. As of this post, Faerie officially enters production.  I can’t promise it will be a rapid process, but it is my plan to make demonstrable progress every week.
2. To add incentive for me to keep it up, I’ll write about the process as I go.  Posts will vary in nature, some technical, some design based, some will be about art style and some will be about marketing.  It is my intention to be as open and up front about the whole thing as possible.
3. If I fail to live up to my promises in 1) and 2) above, I fully expect to be harassed by you, my friends and readers, and to be called a lazy git.

As Sam Beckett would say, “Oh boy!”.  Here’s hoping this works.  If not, people seem to enjoy watching a train wreck so I hope it provides an interesting read either way

MVP

So there’s this new-fangled idea going around about “Lean Startups”.  But one of the key ideas for a lean startup is the idea of identifying your Minimum Viable Product.  In other words, what is the minimum product you can produce that is of sufficient worth that your customers will be willing to pay for it.  For someone with tight time constraints like me, identifying the MVP for Faerie makes a huge amount of sense.  It’s too easy to fall into the trap of trying to incorporate every great idea from every other game out there.  That way leads to madness, and stagnation.

So, what does my MVP look like?  Here’s the current idea:

• Game mechanics – a never-ending series of different coloured objects fall from the top of the screen.  The player creates chains of these objects as they fall.  Chains must either be all of the same colour, or all different colours.  Chains score points based on the rarity of the colours used and also the length of the chains formed.  If an unfinished chain reaches the bottom of the screen, it’s game over.  The player tries to last as long as possible, amounting as high a score as possible.  Ninjump and geoSpark are good examples of these kinds of games.
• Variety – to avoid things getting boring there will also be a number of ‘power ups’ that fall down.  Tapping one of these will, say, slow down time, or activate a points multiplier, or create an auto-chainer, or… It should also be possible to activate combo-like scoring by creating chains in quick succession.
• Audience – I want kids to be able to play the game and have fun, but I also want more serious gamers to find plenty to challenge them.
• Aesthetic – for various reasons, I’ve always seen the falling objects as being leaves falling in a magical woodland – chaining them together is a game played by Faeries (hence the name), and the result of scoring well is to bring life to the woodland in the background.  I’d love to pull off a sort of line drawing and water colour feel to the game.  See the image below by Linda Ravenscroft for an example of the kind of style / colours I’d like to work with.  I’m no artist, so this would indeed be a challenge!  How can I convey a similar feeling / impression with meager skills?

This image is from a great tutorial over at http://www.artgraphica.net

In terms of features, this is what I believe would make a worthy game, with everything non-essential removed (the plan is to add more in as updates, once Faerie has been successfully launched):

• Single ‘endless’ game mode
• Seamless in-game tutorial
• Players can choose one of three levels of difficulty to start on Easy (Kids), Medium (Normal Player) or Hard (Hardcore Master Gamer)
• Scaling level of difficulty as the game goes on
• Gradual introduction of more types of game object over time (as in Tilt to Live, geoSpark, Linkoidz etc)
• Satisfying visual and aural feedback – the player needs to enjoy the process of putting together chains – the game should make them feel like a Minor God of Leaf Chaining.
• Online leader boards, or in some form the ability to brag to your friends.
• Dynamic music that gets more frantic as time goes on.
• All standard iOS behaviour works as expected – save and resume, multitasking, player’s music plays in preference to game music and so on.

I think that’s it.  It doesn’t sound like much, but even given my minimalist goals, I still want the game itself to feel stylish, fun and well polished.

Here’s the thing…

This is the part where I’m going to hit you up for a favour.  What I’m hoping for by conducting this process in the open is to get feedback from everyone.  Is the game good?  Does it suck?  Have you thought of a cool power up?  Would this game work better with Space Marines than Faeries?  Should I use a swipe gesture instead of a double tap? Whatever your thoughts are, I’d love to hear them as we go.  I can’t promise everyone’s ideas will make it into the game – that way lies madness.  But what I hope to achieve by throwing this project open to the world at large is to take this rough idea of a game and reduce it to an elegant, streamlined and fun game.  The more opinions I can get, and the earlier I can get them, the better this game will be.

So, my first question to you is: does the MVP sound viable?  Is it enough, or does it need something more before I can justify asking $0.99 or $1.99 for it?  Even at this stage, is there something that could be cut back on?  And a second question: what of the game’s theme / aesthetic (faeries, woodland scenes, water colour rendering) – does it sound promising / appealing?

I thought it was about time to wrap up this series of articles by showing a fully working example of a build.  I’ve been using Hudson both for my private work and in my day job for the last couple of months now.  In that time it has save me a lot of time and effort producing AdHoc builds (now a one click process), and also occasionally catches me when I fail to commit new files to SVN.  Setup is far simpler than any other CC tool I’ve used, so I’d encourage you to have a go!

The story so far…

For convenience, here’s an index for the whole series.

• Part One, Overview of what an automated build is, and why it’s so useful.
• Part Two, setting up a basic build.
• Part Three, automatically versioning and tagging your project.
• Part Four, this article.  An example of a complete, working build.

Running all the time

One thing you want to set up with your build is to have it running all the time in the background.  I found this very helpful article by Jérôme Renard that covers a useful technique.  Read the comments, they’re very handy too!  In an ideal world, Hudson would run happily under all user logins.  And in fact the comments in Jérôme’s article describe how this can be done.  Unfortunately, when it comes to iOS development, the code signing that is done on AdHoc and Distribution builds requires various certificates etc to be present in the user’s keychain.  Setting these up for all users is a pain that keeps on hurting, especially every time you need to update a profile – when you add a new device, for example.

My advice is to just set up Hudson to run under a single user account – either your own developer account, or a special ‘build machine’ account if you have a dedicated computer available.

Hudson-wide setup

Hudson has a number of settings that can be applied to most or all projects.  By following the links to Manage Hudson | Configure System, you can set things such as non-standard paths for source control, default email setup and so on.  In my case, it’s a place to set up email defaults and twitter settings:

You’ll note that I’ve had to set up a non-standard port for email, and that I’ve added my email address as the system admin – if anything funny happens, Hudson will let me know through this address.  While it’s possible to set these on a per project basis, doing it here once just makes sense.

One more thing.  When I was talking about setting up a build from scratch, I’d typically use the ‘Build a free-style software project’ option when setting up a new job.  Once you have a working build, the ‘Copy existing job’ option becomes very useful, and is a huge time saver.  Typically a new build can be up and running in the five minutes it takes to change a few path variables.

The build job itself

OK, so let’s look at the setup for the actual build.  First of all, version control:

There’s nothing particularly unusual here.  I nominate the folder to check out the code into (‘Acorn Money’).  This is not necessary, but feels a little tidier to me.  The main thing to note is that I don’t trust an update and build here – an automated build should always be completely clean.  While Hudson doesn’t offer this out of the box, it does have the ‘Revert’ option to ensure no modified files are included in the build.  If anyone knows of a way to force Hudson to wipe and fetch the project clean from version control each time, let me know, I’d love to know how to do it.

So, no build triggers here.  This is because I want to generate an AdHoc build on an ‘as required’ basis.  Hudson is running on my MacBook, so the last thing I want is scheduled builds kicking off while I’m working.  The ‘Poll SCM’ option is handy for Continuous Integration, while the ‘Build periodically’ option is useful for nightly builds when the machine is otherwise idle.

Right, let’s look at the guts of it now, the shell scripts that do the actual building.  I use several scripts, separated into logical chunks.  They could all be run in a single script, but I prefer the separation here – each script has a singular purpose.  First up, we increment our build number and tag the code in SVN (see part three of this series):

cd AcornMoney
agvtool -usesvn bump -all
agvtool -usesvn tag -baseurlfortag http://acornsvn.no-ip.org:808/acornheroes/svn/AcornMoney/tags
cd ..

Next, the easy part is actually building the code, using an AdHoc configuration:

cd AcornMoney
xcodebuild -project AcornMoney.xcodeproj -target AcornMoney -configuration AdHoc
cd ..

For setting up a Distribution or AdHoc configuration, I generally refer to this cheat sheet, which is great for helping me ensure I don’t miss anything.  Finally, the fun part.  Once a build is successful, wouldn’t it be nice to make it available to all your testers automatically?  With the help of DropBox.com, it’s relatively easy.  Here’s the script:

cd AcornMoney
mkdir Payload
cp -rp build/AdHoc-iphoneos/AcornMoney.app Payload/
zip -r AcornMoney.ipa iTunesArtwork Payload
rm -rf Payload

rm -rf ~/Desktop/Dropbox/Acorn\ Money\ Builds/Latest/*
cp AcornMoney.ipa ~/Desktop/Dropbox/Acorn\ Money\ Builds/Latest/
cp ~/Library/MobileDevice/Provisioning\ Profiles/AcornHeroesAdHoc.mobileprovision ~/Desktop/Dropbox/Acorn\ Money\ Builds/Latest/

if [ $BUILD_NUMBER -lt 10 ]
then
 TMP_BUILD_NAME=AcornMoney00$BUILD_NUMBER
elif [ $BUILD_NUMBER -lt 100 ]
then
 TMP_BUILD_NAME=AcornMoney0$BUILD_NUMBER
else
 TMP_BUILD_NAME=AcornMoney$BUILD_NUMBER
fi

mkdir ~/Desktop/Dropbox/Acorn\ Money\ Builds/$TMP_BUILD_NAME

cp AcornMoney.ipa ~/Desktop/Dropbox/Acorn\ Money\ Builds/$TMP_BUILD_NAME/
cp ~/Library/MobileDevice/Provisioning\ Profiles/AcornHeroesAdHoc.mobileprovision ~/Desktop/Dropbox/Acorn\ Money\ Builds/$TMP_BUILD_NAME/

It may look like there’s a lot going on here, but most of it is just copying files around.  First of all we create an .ipa file (just a zip file with a different extension) which contains our build plus an ‘iTunesArtwork’ png image – otherwise the App icon doesn’t show up in iTunes for an AdHoc build.  Next up, we remove any existing ‘Latest’ build folder in our Dropbox folder.  Then we create a numbered folder for this build (e.g. AcornMoney08) and copy AcornMoney.ipa into this folder and the latest folder.  We also copy the provisioning profile from ‘~/Library/MobileDevice/Provisioning Profiles’, as it will be needed by our testers.

From here, Dropbox takes care of syncing this folder with anyone who is sharing it.  Our testers get a notification and a new build delivered to their own PC!  The post-build actions are fairly uninteresting, all I have set currently is email notification on a failed build.  Even this is slightly overkill, as for an AdHoc build I’m normally sitting at the machine watching the build anyway.

That’s it, a fully working build.  With Hudson, it’s possible to set one of these up with just an hour or so tinkering around.  Once you have a working build as an example, making a new build can be just a few minutes work.  Give it a go and let me know how you get on!

Acorn Money update

For those of you interested in Acorn Money, our money tracking App, we’re still in review.  Sam made some significant improvements to the graph rendering code and we felt the best thing to do was to pull the submitted build and re-submit.  Unfortunately this sends us back to the end of the queue.  Still, we’re hopeful Acorn Money will be available in the next couple of weeks.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

In my previous articles, we’ve looked at how we can set up an automatic build, with a focus on catching issues with bad check-ins immediately.  Another useful aspect of an automated build is that it can remove the chance of human error whenever we have a task that consists of a lot of manual steps.

One such example is generating a build for ad-hoc distribution to beta testers.  We could create a build by hand, but if we forget to increment the version number in our project, then our testers won’t be able to update from a previous build unless they delete the old build by hand off their devices and iTunes – definitely a pain for people you don’t want to inconvenience.

Also, imagine the scenario in a couple of weeks when a tester notifies you of a serious bug they’ve found.  Chances are the code you have now is quite different to the build they have.  Can you get back to that point in the code easily?

Fortunately Apple provide us with a handy tool called agvtool that can handle these situations for us.  It’s a command line tool, so it integrates nicely into Hudson.  But first let’s look at agvtool on its own, and see what we can do with it.

agvtool

In order for agvtool to do its magic, we have a few things to set up in our project first.  Most of the steps here are described in detail by Jamie Montgomerie on his blog.  Briefly though, we will use two different version numbers – a release version and a build number.  The release version is our “marketing” number – what our clients see (“Now updated to version 1.2!”).  Our build number is for internal use, and will connect a given instance of our App to a specific tagged version of our code in source control. To test this, I created a simple OpenGL project in Xcode and added it to SVN as a starting point.  The only modification I’ve made to it is to add a label on top of the GL view.  We will use this later to display our build number for testers.  Note that SVN is not necessary for using agvtool, but it will give us a few nice options down the track.

So, following Jamie’s instructions, we:

1. Open our project’s PROJECT_NAME-Info.plist file and set the Bundle version to 1.  This represents our build number.
2. Ctrl (or right) click on the plist and choose Add Row.  From the options presented, select Bundle versions string, short and set its initial value to (say) 0.1.  This is our release version.
3. Ctrl (or right) click on the project in the Groups & Files window, and select Get Info.  Make sure you’ve selected All Configurations and find the Versioning section, near the bottom.  Set the Current Project Version to match you build number – 1 in our case.  Set the Versioning system to apple-generic.

OK, not too painful and we’ll never need to touch these bits again!  Let’s test our a few things.  Open up a terminal window and cd to your project directory.  We can use agvtool to tell us both the current build and release version numbers (agvtool calls them version and marketing version respectively):

You should see the build number (agvtool what-version) and release version (agvtool what-marketing-version) that you entered into the project settings.  Now, using agvtool we can also update our build and release version numbers.  Note that doing this modifies your project, so ensure it’s either not open in XCode or everything has been saved – otherwise you may lose changes to your project such as settings or newly added files. So, to increment our build number we use:

agvtool bump -all

On the slightly rarer occasion that we want to adjust our release version, this can be done as follows:

agvtool new-marketing-version 0.21b

You can use the agvtool what- command to verify what’s going on here.  Note that our build number is automatically incremented by one using the bump command.  Our release version is in fact a string, and we can supply whatever we want there, in this case 0.21b.

Assuming you’re paranoid like me, now is a good time to check this into source control as we have all the basics covered.

Open the project in XCode and build it.  XCode will now automatically generate a .c file as part of the build.  In my case, these were found at:

build/AutoVersionTest.build/Debug-iphonesimulator/AutoVersionTest.build/DerivedSources/AutoVersionTest_vers.c

You don’t need to even open this file, or include them in your project (that happens automatically).  This file declares two variables, a version string and number that correspond to our build number.  We can put them to good use.  In my sample project, I’ve declared the build number as an external variable in my App delegate:

extern const double AutoVersionTestVersionNumber;

And then in my application: didFinishLaunchingWithOptions method I’ve used the build number on the label I added earlier:

versionLabel.text = [NSString stringWithFormat:@"Build: %1.0f",AutoVersionTestVersionNumber, nil];

Now when testers run my App they’ll see something like this:

Now, a tester can easily identify the build they’re running when giving me feedback.  By the way – if anyone know an easy way to get at our release version number in code, please let me know!  What we need now is a simple way to tie that back to a specific version of our code…

Tagging in SVN

Note, this also works with CVS as well, however while there are good arguments for not moving to a more modern system like Git or Mercurial, there’s no good argument for sticking with CVS.

agvtool has the ability to update our version information and then commit the changes, simply by adding the usesvn tag like so:

agvtool -usesvn bump -all

Nice.  But it gets better.  We can then tag these changes to make getting back to them simple:

agvtool -usesvn tag -baseurlfortag http://URL/to/svn/AutoVersionTest/tags

The -baseurlfortag option specifies where the tag should go.  After this operation, you’re SVN repository should look something like this:

Now, when you receive feedback from a tester it’s a simple matter to check out the tagged code and you can track down issues with the same code base your tester was using.  Note that the folder specified by the -baseurlfortag option must already exist – agvtool will not create it for you.

And Hudson?

Hopefully it’s not too much of a stretch from here to see how we can use this in Hudson (or any other automated build system).  First off, we should create a project in Hudson that will check out our code and build it.  If you already have an existing Hudson project that builds periodically or with each new check-in you can simply clone it (Hudson is good that way).  Configure the project to only build manually by unchecking all the build triggers:

And add in new build step(s), calling agvtool to bump our build number and (if using SVN) tag the resulting build.  Note that if this project were set up to trigger a new build when check-ins are detected we have a potential race condition, with agvtool checking in changes which would trigger a new build which would make agvtool check in changes….

So, with these changes in place we can now reliably build a version of our code for testers, tag it and know that we can come back to the code for that build at any time.  And it’s all done automatically.  Also our version numbers will always increase, insuring that our testers don’t have trouble updating to a newer build.

And Another Thing

OK, I haven’t played with this one extensively yet, but will add it here for your consideration.  Hudson allows us to add parameters to a build.  When we start a build, it will ask us to supply parameters that affect the build.  As an example we can add a BuildNumber parameter that will decide which tagged version of our code we want.  Configuring it in Hudson will look something like this:

So what’s the use of this?  Well the parameter becomes an environment variable when Hudson is building the project.  So we can slip the environment variable into our source control link.  This way, when we kick off a build we can specify the tag to use, making it easy to recreate our App as it was at any stage in its development.

Well that’s it for this week.  If you have any questions or feedback please leave a comment below.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

After last week’s introduction, it’s time to get on with making this thing.  After looking at both CruiseControl and Hudson, I went with Hudson – mainly because it’s very simple to set up and start using straight away.  So without further fuss, let’s download Hudson from here.  I created a build folder ~/AutomatedBuilds (there’s nothing special about this location, put it wherever suits you) and put the downloaded file hudson.war.zip in it.

Open a terminal window and cd to the build folder.  The online documentation says that you should unzip hudson and run it using the command:

java -jar hudson.war

This works fine on Windows, however under OS X, unzipping the file and trying to run it causes the following error:

If anyone can explain the issue, I’d appreciate the insight.  However it turns out we can just run Hudson as-is out of the zip file:

Ok, so what’s happened?  Hudson is now running as a Java application in the terminal.  As well as running the build, it also provides a web interface for us to work with.  Open a browser and point it at http://localhost:8080/ and you should see something like:

Before we set up our first job, we should grab a couple of handy plugins first.  Click on the Manage Hudson link on the left, then Manage Plugins and finally the Available tab.  You should see a long, slightly exciting (or intimidating, depending on your outlook on life) list of plugins.  Have a look through the list – there’s lots here to play with – but for now select the Twitter and Mercurial plugins (assuming I’ve convinced you to try Mercurial), and click on the Install button.

You should see the plugins being downloaded and installed, along with a message to restart Hudson.  When Hudson is running, there’s a Prepare for Shutdown option on the Manage Hudson page.  For now though, it’s enough to go to the Terminal window you’re running Hudson in and kill it with Ctrl+C (I’m a bit old fashioned that way).

Run Hudson again from the terminal window, and we’re ready to set up our first automated build.  For a start, let’s create a build that monitors our source control repository and kicks off a build when it sees any changes.

On the main Hudson dashboard, click New Job.  Give the job a name, choose the “free-style software project” option and click OK.

On the resulting page you can configure a bunch of options.  Feel free to go nuts here.  Each option has a ‘?’ icon that provides useful help.  Here’s the settings I used:

Under Source Code Management, I chose Mercurial and pointed it at my Fogbugz Repository.  The Fogbugz repository requires the user to be authenticated, so we do this by including the user name and password in the URL in the form:

https://USER_NAME:PASSWORD@PATH_TO_REPOSITORY

Note that, if your user name has a ‘@’ symbol in it, replace the ‘@’ with ‘%40′ to avoid the URL being incorrectly parsed by Hudson or Fogbugz (see the screen shot below).

Hudson also supports many other types of source control, pick the one that you use.  Another small note here – when setting up an automated build for the first time, it’s a good idea to use a small test project first, to allow faster testing of your set up.  My actual production code can take many minutes to build (not my fault! OpenFeint is slow to build), so instead, for this article, I’ve created AwesomeGame from one of the standard XCode templates.  Once I have a running build system, I’ll then go back and add in my production code.

Next up, we want to check if we need to trigger a build by polling SCM for changes.  We schedule Hudson to check SCM every minute using CRON-like syntax :

Then, we add the actual build step, executing a shell command to run XCode from the command line using xcodebuild.  Have a look at the xcodebuild man page for all the various options.  For now, we want to build our AwesomeGame target in both Debug and Release modes.  I’ve done this below using two build steps:

Finally, let’s tell Hudson how to notify us when the build is done.  I selected email and Twitter notifications.  If you’re on a team, notice the option to notify the individual who committed the changes that broke the build – without having to notify the entire team.  As well as the person responsible for the break it’s good practice to have a nominated ‘build monkey’ whose job it is to check all builds – so make sure they’re getting all the build results as well.   A quick note on Twitter here – don’t use your own Twitter account unless you want to spam all your followers!  Instead, create a bogus build account for Hudson to use, and follow it from your main account.

Assuming we’re all happy with the settings (we can always come back and tweak them), click Save.

Hudson now takes us to the page for our project.  On the left is a Build Now option – let’s try it out…  After a few seconds, you should see a progress bar in the bottom left, telling you that Hudson is building your project.  If nothing happens, check the top right of the page for an Enable auto-refresh option.

Once finished, we’ll see a blue ball that indicates a successful build (your code in source control does build, right?).  If instead you see a red icon, then the build has broken, and we need to fix something.  Either way, click on the most recent build link to see details of the build:

On this page, we can see the status of this particular build (remember blue ball means success), the changes in source control from the last build (none in this case, as we manually triggered the build) and the console output, where we can see the details of the code being checked out from source control and built using XCode.  If your build has failed, this is a good place to look for the problem.

Phew!  The system works!  Checking Twitter, sure enough there’s a success message there:

But hang on, where’s my email?  The problem here is that we need to configure Hudson with an smtp server so that it can deliver mail to us.  Go back to the Manage Hudson page, and click on Configure System.  Near the bottom you can configure the global settings for email and Twitter.  If you’re unsure what smtp server to use, check the settings for your email program – you’re looking for the name of your outgoing smtp server.

So enter in your smtp details, and the system admin email address (that’s you).  Click on the Test button and make sure that you get the test email message.

Going back to the main Hudson page, you should notice that our project is listed, and on the right hand side is a Build Now icon (so you don’t have to go into the project to kick off a build).  Click it to start another build, and then click on your project to follow the build’s progress…  Still no email.  Bugger.  Going to the project’s Configure screen, I look up the help for email, which sheds some light on the issue:

This is sensible – no point in spamming out emails when builds are all going well.

So by now we know that we can check out our code and build it automatically.  But where is the build?  Hudson creates a working folder in your root directory.  Have a look in ~/.hudson, and you’ll see all of Hudson’s internals.  In particular, the folder ~/.hudson/jobs/Awesome Game contains all of our build history and a workspace folder in which the code is checked out and built.  So if I want to get the built app, I can grab it from:

~/.hudson/jobs/Amazing%20Game/workspace/build/Release-iphoneos/

Later we’ll look at packaging up the build and putting it somewhere handy, but for now, let’s make sure that it’ll pick up on changes in source control.  Check out a working copy (if you don’t have one) of your project and put in a small change that will cause the build to break.  This ought to do it:

Commit the change (or commit and push if you’re using a remote Mercurial server like I am) and wait for a minute.  You may notice a message mentioning a ‘quiet period’ before the build kicks off properly.  This quiet period is Hudson waiting after it detects a change in source control to make sure all changes have been committed – this is particularly useful with CVS, where every file is committed separately.

Ah, BOOM!  Our build has failed nicely.  And I got an email this time, which is nice  A broken build is  something that shouldn’t be left broken, so let’s fix it and check the build comes back happily.  Fix the code, push, commit, wait… success!  Twitter and email confirm everything’s OK.

We’ve covered quite a bit so far so it’s probably a good time to take a break and see what we’ve achieved, and how that matches our goals from last week.

What works?

• Monitor source control (Mercurial and Subversion in my case), kicking off a build whenever changes are checked in.
• We’ll be able to manually kick off a build as needed.
• The build will grab all our source code from source control and build it in all relevant configurations – debug, release, simulator, device and so on.
• When the build is finished, it’ll notify people of the success / failure.
• There’ll be a handy location (web page most likely) where we can monitor / control the whole thing.

What do we still need to do?

• We’ll schedule a nightly build as well, just in case anything outside of source control has changed. This is fairly simple – an exercise for the reader!
• Copy a successfully built app to somewhere useful, preferably packaging it up with a provisioning profile in a zip archive, ready for emailing.
• Automatically update version numbers on our ‘stable’ build with each build.
• Bundle up the resulting builds with a provisioning profile and copy them to a shared folder.
• Start up automatically under when your build machine is booted.
• Paint a unicorn.

OK, plenty to work on, I’ll be back next week with some more detail, or if you’re keen have a crack yourself and let me know how you get on!

Disclaimer: I’ll let you in on a secret now, to avoid disappointment later on.  By the end of this article you won’t have a fully working automated build  The reason is that I was half way through writing up this article using CruiseControl when I started to look at Hudson, which seems like it might be promising.  So this week is an introduction to the idea of continuous integration and automated builds and how they can save you time and grief.  Next week I’ll aim to have a useful build system up and running along with instructions on how to set it up…

What?  Why?

An automated build is a system that can build your software from source to finished product without human intervention.  At it’s simplest, this can be an XCode project or a makefile – after all, you don’t compile each file and link them together by hand, do you?  The key idea is that we can remove human error from the process, making it more efficient.  The ideal is to have a system whereby you can build all versions of your software with a single click (and also score a couple of points on the Joel test).

Consider the following situation.  You want a fresh build of the code to show off to your boss, “Reckless” Jim, to keep him off your back.  When you wake up, you grab your iPhone 4 (lucky bastard), open Safari and click a link on a web page before you get in the shower (remember to put the iPhone down first).  While you’re halfway through your hot water supply (and the Sound of Music soundtrack), the following is happening:

Cool, huh?

Or how about this:

Neat, eh?

This second example is what’s known as continuous integration – every time you check in new code to source control, the whole build is exercised to make sure nothing’s broken.  Why?  Often a broken build is a simple 30 second fix at the time, but 2 weeks later it might require hours of sorting through commit logs to see where the problem is.

The solution

So, what does it take to set up a system like this?  Not as much as you might think.  There are some neat tools out there to get you up and running fairly quickly.  The problem is that I didn’t have time to try out both of the likely candidates for this week’s deadline.  I’ve used CruiseControl before, and Hudson looks promising.

So here’s the goal for next week.  I’ll show you how to set up a system that will:

In the mean time here’s a couple of sample chapters from Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications that covers the basics of setting up CruiseControl.

So, now to decide between Hudson and CruiseControl.  If you have any thoughts on either of these systems (or another I haven’t heard of), please let me know in the comments below…