Acorn Heroes

Now that the initial excitement of getting an App on the store is starting to fade, it seems like a good time to look back over Goo!’s development history and figure out what worked and what didn’t.

The Good

Sales:

It may seem odd to put this under the ‘good’ category, as our sales figures are still in double digits (although we’re hoping for a roll over into three digits before long).  However the purpose of Goo! was to be a test case, dipping our toes in the AppStore’s waters.  As such, it’s a success.  There’s a wonderful buzz from selling your own software that I had never experienced before.  Despite developing software for over ten years now, it’s always been for someone else.  The thought that other people, around the world have seen my software and wanted to buy it is thrilling.  And the feeling you get when one of your friends greets you by waving their iPhone in your face with your App on it is pretty special - thanks Chris, you’re an awesome friend.

Cocos 2d:

After faffing about with raw OpenGL for a while, we eventually switched to using Cocos2d as a platform.  Although both Sam and I are familiar with writing OpenGL engines, it just soaked up our time - something we have little enough of.  Cocos2d worked a treat and the change over took only an afternoon’s effort.

Twitter:

Twitter has proved to be a real find for me.  The iPhone developers I follow are a friendly, helpful bunch.  I’ve learnt plenty from these guys, found lots of great articles on the Internet and when we released Goo!, lots of people re-tweeted the announcement or promptly bought it on the spot.  Thanks guys, it means a lot!

Working together:

Sam and I have been working together on and off for over ten years now.  Ideas pass back and forward freely, and there’s enough mutual respect that we can quickly throw away bad ideas, or modify them to become good ideas with no ego or resentment getting in the way.

Submission process:

We hit a lucky patch with the App Store - just before Christmas people started reporting quick turn around with App submission.  Sure enough, Goo! went through the approval process smoothly in three days - a very pleasant surprise.  In fact, after hearing horror stories from developers over the last year, it is nice to see that Apple is improving things (or were we just lucky?).

The Bad

Too long:

Yeah, this is the biggie.  Nine months is a ridiculous length of time.  No excuses here.  Too often real life got in the way.  It’s just a fact of the lives we live with full time jobs and families.  Also…

Lack of a core concept:

In it’s day, Goo! has been a time tracker, the beginnings of a series of articles, a set of particle system toys and finally an implementation of the Game of Life.  Perhaps now you understand why it took so long.  Sam and I wanted a simple project to get started and we exercised some poor judgement along the way.  A lack of a clear vision for Goo! hampered us a lot.

Lack of a forward delete key:

Seriously, this is the single biggest pain I have working on a laptop.  And yes, I know about fn-delete, but it’s just not the same.

So, in summary it’s been an enjoyable process.  Goo!, while simple, is an App that we’re happy to have on the store.  The idea of selling our work on the App Store now feels much more achievable and we’e both brimming with new ideas, at least one of which is showing a lot of promise - and as far as I know is a completely new idea.  Of course the challenge is in turning a good idea into a successful project - watch this space.

After a delightfully short period of three days, our maiden iPhone app is available through iTunes (App Store link).  Goo! is a fun version of the Game of Life, by John Conway.  You create patterns of cells, and then watch as generations pass.  If a cell is too lonely, or is overcrowded, it will die out.  If conditions are just right, new cells are born.

Although it’s a simple app, there’s plenty of depth in the Game of Life.  Some patterns will oscillate forever, or become stable.  Others will travel across the screen in a stately procession.  Yet other patterns will ‘fire’ out new patterns.

So, give it a try today, and help us take one more step towards living our dream!  To Infinity, and Beyond!

Back in March of last year, Sam and I began working on developing apps for the iPhone.  Now, nine months later, our first app has been submitted for review.  It’s a reasonably simple app, a pleasing on the eye version of the Game of Life, by John Conway.  It was originally our ‘proof of concept’, or ‘one day app‘, a chance to dip our toes in the waters of the App Store.  So what happened?  Below are a few thoughts (not excuses)…

• We’re both very busy people.  Having full time work and multiple children just takes up time.
• Tied in to the first point, at times when our lives have got busier than normal, one of us drops off the grid for a bit.  This can stall the other team member and when you come back to the code again there’s the problem of getting back up to speed again.
• We lost our way a few times.  The final app we’ve submitted is very different for the original plan.  Several times we’ve reduced the scope of the app to keep it more focused and manageable.  But each of these changes has meant re-examining and amending the existing code base.
• We started working at the OpenGL level.  Both of us are completely at home writing OpenGL code, and so we made the initial decision to write our own ‘engine’.  Eventually we switched to Cocos 2d and life became significantly easier.

Sam and I would like to wish you all a Happy Christmas and a happier New Year.  If you’re in the Northern hemisphere, we hope you get a white Christmas.  If you’re in the South like us, we hope you enjoy plenty of sunshine, sea and barbecues!

It’s been quiet here for a while, but I can assure you we’re busy.  This year has been a bit manic at times, but the good news is that we’re preparing to submit our first app to Apple early in January.  Next year we have big plans and even bigger dreams.

From us both, have a happy and safe holiday.

Beg.  Borrow.  Steal.

Got an existing game, and you feel comfortable with the code?  Take a copy, rip out the guts of it, and start prototyping.  Need to perform a Fourier transform?  Do a Google search and mash the code you find into your prototype.  Know that a friend has solved a given problem before?  Ask them if they can send you the relevant code.

So you’ve found some useful code, but it doesn’t represent vectors the same way you do?  Don’t go through the borrowed code doing a search/replace - it’ll take too long and may introduce errors.  Instead, simply convert vector data on the way in and out with a simple piece of wrapper code.  Remember, CPU and memory are free.

Rapid prototyping is about getting results fast.  Sometimes the fastest way to get a result is to use working code from somewhere else.

Hi everyone,

I’ve recently managed to be invited to join Google Wave’s beta.  Probably the thing that hits most people when they first start is ‘what do I do now?’  The first thing you need is a useful contact list.

To that end, I’m trying to put together a wave with as many iPhone developers on it as possible.  So, if you’re interested, and have a Wave account (or can scrounge one up), send me a wave (george.sealy ‘at’ googlewave.com) and I’ll add you to the list…

Please pass this on to anyone you know who may be interested.  Thanks

Perhaps I expect too much?

I was playing the demo of Torchlight the other day.  It’s a beautiful game - art and game play honed to near perfection.  So why after a couple of hours of playing did I feel hollow inside?  What was I doing?  Why?  Was this even fun?  I love this sort of game - I lost vast quantities of time to Diablo, and enjoyed it.

So what’s the difference here?  Here I was, avidly collecting loot, leveling up and so on, flying through enemies with happy abandon.  I think that ultimately that’s all there was to it.  Fight / loot / fight / loot.  Where was my motivation and back story?  Where was the momentary pause to plan my attacks before diving through a door to tackle the nasty boss monster?  Half the time I didn’t even register that I was fighting a boss until I was picking over his corpse.  What level was I on?  What made this one stand out from all the others?

I’ve felt this way before, playing Bunni Bunni, designed by Danc, who’s blog is an inspiration and well worth reading.  I found myself playing it to completion, but was left with nothing of value to take away from the experience.  It’s a carefully constructed task / reward structure, tuned to the point where conscious thought dissappears.  It’s akin to grind in MMO’s.  Don’t even get me started there.

When designing games, we talk about addiction as if it’s a good thing - the ultimate goal.  If that’s the best we can do, I need to find another hobby.  Fortunately, there’s still plenty of scope for story telling (Dragon Age), exploration (Small Worlds) and deep strategy (Galactic Civilisations II) and simple beauty (Braid, Aquaria).

I guess what I’m saying is that with a family and work, my spare moments playing games are precious to me.  Playing a game ‘just to fill in time’ is pointless.  I want to have an experience, one that I’ll reflect on later as worthwhile.  I really wanted to like Torchlight, but I just can’t.

Or is it just me?  Let me know what you think…

A question popped up recently on the TouchArcade forums, about how many testers is the ‘best’ number to have.  At first it seems like more is better, but in fact that’s not always the case.

In terms of numbers, you’ll get diminishing returns on adding more testers. Say each tester finds on average 10 bugs / issues. With one tester, you’ve found 10 bugs. With two testers it may be, say, 15 bugs due to overlaps in what they find (i.e. they both report some of the same bugs). Three testers may find a total of 18 bugs and so on.

Very quickly you reach a point where your chances of getting something new from an additional tester become slim.  But it gets worse than that - you’re actually polluting your pool of fresh testers who have never played your game before.  These people are valuable, as they give you an insight into those vital, impression forming, first few moments a customer has with your product.

So small groups can be surprisingly effective. Start with a small group of, say, 5 testers. Get their feedback, make adjustments and then release an updated test version to a new set of five testers, plus the original group of testers.  The ‘fresh meat’ will help you avoid tunnel vision, giving you the 50,000 ft view, while the repeat testers can give detailed feedback on particular features.

Repeat until you’re happy, or at least until you’re satisfied your product has reached the level of quality you’re aiming for.

Have a plan.  Refer to it frequently.  Update it as needed.

I don’t know how I managed to get to Rule #8 without mentioning this one before.  If you’re going to spend, say, 1-5 days putting together a prototype, do yourself a favour and sit down with pen and paper and plan out what you want to do.

Writing tasks down and then ticking them off as you go is a powerful motivator.  Keep it simple, a list of 5-10 tasks is fine.  Try to make the tasks well defined and achievable in less than a couple of hours.  Crossing items off a list is good for the soul, so make sure you can do it frequently!

Making a plan is great.  Sticking to it is even better.  But the real key to success is to revisit and refine a plan on a regular basis.  Keep in mind your goal and add, delete or re-prioritise your list of tasks once or twice a day.  And always, ask yourself “What’s the minimal set of things I can do to get the prototype working?”.

Mysterious goo!

What is it?  It’s a public outing of our first application - code name: CocosTest for now (One day I’ll rename the project file ).  Sam and I are getting close to alpha / feature complete stage, and despite being a relatively simple application its taking up what little spare time we have.

Initially we were working with our own code base, but for one reason or another we weren’t happy with it - over a couple of evenings we were able to port the code to run on top of Cocos2d, which is a lovely framework to use - expect an article or two about it in the future.

As for what CocosTest actually is, we’ll leave that up in the air for now.  It’s not a game, but it’s called a game, just to be confusing.

So now it’s a time to polish the rough edges. Take care of all the details and then dip our toes in the ocean that is the App Store.  Exciting times!