If I had the chance, what would I tell my younger self?  What has worked out well for me and what would I do differently?  Here’s a few of the things I came up with.  What would you add?

Failure is not the thing to be afraid of

Some of the world’s most successful people have had massive, public failures – but it hasn’t stopped them.  Yes failure is painful and embarrassing.  But it’s also a great teacher, making us wiser and stronger.  Perhaps more importantly though, if we never fail, then we’re not taking any risks.  Tackling challenges that may be too much for you are where we get a chance to excel and surprise ourself and others.

Always have a backup plan

I have spent many years working in live television, covering sports events.  It was not uncommon to be adding new features to the software on site the night before the event.  I’ve arrived in foreign countries with broken computers.  I’ve turned up at events and lost a day because no one knew we were coming and so we had no space to work, no power to work with.  I’ve had machines die at 2am the day before we’re live.  This teaches you a few of things:

1. Some deadlines simply can not move, so you must be adaptable.
2. Always have a backup option.  You may not get as much done as you hoped.
3. Worry early so that you don’t have to panic late.

Plan your work to try and deliver in an iterative fashion.  Planning to deliver everything at once, on deadline is just plain stupid.  Working without source control is just plain stupid.

There is no better time than now

It’s taken me far too many years to realise that my dream is to work for myself, on the projects I want to work on.  I’ve learnt a lot working for other people and I enjoy being part of a team.  But after a while the urge to show the world what you can do, to craft something that’s all yours becomes very strong.

My point is this.  It’s hard to do that once you have a mortgage and a family (and a dog, cat, rabbit, guinea pigs, chickens and goldfish).  When you’re young you have a great opportunity to move quickly and try things out.  Also, we live in an age where it’s never been easier to get your product in front of customers – make the most of it.

You will be wrong, often

There’s no shame in being wrong.  It happens.  Accept that it happens and move on.  Keep your ego in check and always keep in mind that the people you work with probably aren’t stupid either.   Often arguments are caused because two people are so caught up in their own opinion that they forget they’re on the same team, trying to achieve the same goal.

Mistakes will happen and you don’t always make the best choices.  Learn to prototype ideas quickly.  Learn to leave a buffer in a project plan to handle the unexpected.  Tackle the biggest challenges first to avoid surprises.

Always learn more

Learn new languages, frameworks and techniques.  Read iDevBlogADay and altDevBlogADay!  Challenge yourself not to stagnate.  If you find yourself criticising another platform, maybe it’s time to dive in and learn more about it.  One thing I can promise you is that the work environment and tools you use today won’t be the ones you use in 10 or 20 years.  Don’t end up a dinosaur.

There are difficult or petty people in this world – deal with it

Working with others is hard.  It’s at least as hard as the technical challenges you deal with, so put some effort into being good at it.  Working so-operatively is a skill you can develop.  Some people are harder to work with than others.  You might be That Guy.  Learn how to communicate clearly and without letting your emotions get in the way.  Work on solutions, not problems.  Be polite and always treat people with respect – especially the difficult ones.  You never know whio you’ll be working with or depending on in a couple of years.  Life is funny that way.

There’s no silver bullet here, it’s hard work but the effort will pay off, I promise you.

You are so much more than a coder

This is the big one.  Don’t believe that you’re just the tech guy.  Get out of your ivory tower and learn about what your colleagues do.  Know enough about Photoshop to take images from artists and get them into a usable form.  Understand how artists build models so that you can teach them (in their own terms) what can and can’t be done inside a game engine.  Talk to designers about flow and layout, and why moving that text two pixels to the left is so important.

Understand enough about business to know the effort that goes into giving you a pay cheque each fortnight.  Practice estimating tasks and tracking time spent to better understand what you can or can’t achieve in a given time frame.  Write documentation or reports to share knowledge with clients or customers.  Write a blog!  Speak in public.

Not only will this make you a better person, but others will enjoy working with you and helping you out when needed.  And when you make that transition to management, or all-in-one Indie developer, you’ll be much better prepared.

And one more thing…

Enjoy yourself.  Work hard and treat difficult problems as a fun challenge to crack.  Only boring people get bored.

It’s simple.  All proceeds for the next week from the following apps (iOS and Mac) will go directly to the Red Cross relief effort.  For more details, go to http://www.appappeal.co.nz/.  There are some great apps here, and you’ll be directly helping the thousands of people affected by this disaster.

Apps involved in the appeal include:

Chopper 2 – Majic Jungle Software – Universal App + Mac OS

Top Dog: Farmyard Adventures - Flightless – iOS

Scarlet and the Spark of Life: Scarlett Adventures Episode 1 - Launching Pad Games  – iOS

Sheepish –Pixelthis –  iOS

MiniMonos Flight –Minimonos – iOS

Acorn Money –Acorn Heroes – iOS

Bird Strike –PikPok – iOS

Ancient Frog HD –Ancient Workshop  - iPad

Twenty Chinups –SoftwareX – iOS

Sleepmaker Waves, Sleepmaker Rain, Sleepmaker Storms, Sleepmaker Streams, Sleepmaker All in One and Sleepmaker Wildlife -SoftwareX – iOS

Dejal Simon, Dejal Time Out, Dejal Caboodle, Dejal BlogAssist – Dejal – Mac OS

Please help us spread the word by telling people about http://www.appappeal.co.nz/.

I’d also like to offer a vote of thanks to Jos from PikPok games and all the others who have been involved in putting this together so quickly.  And to everyone affected in Christchurch, we’d like to say Kia Kaha, we are all with you in this horrible time.

There have been a lot of people talking up Distributed Version Control Systems (DVCS). Until recently, I’d assumed that it was the same people who have been talking up Linux for the last 15+ years. Don’t get me started on them. It seemed the principal argument used by many people was ‘everyone has their own repository’. To me, that sounded like a recipe for disaster – I’m far happier with the concept of a central, authoritative repository.

So I was surprised when Joel Spolsky came out in favour of Mercurial (or Hg), a DVCS. Joel’s a fairly level headed, mainstream kind of person – what was he doing fraternizing with the Linux-loving hippies and beatniks? After reading his Hg introduction, I realized I was in danger of becoming a convert too. When you’re done here, you may want to go over to hginit.com – you won’t find a better introduction to Hg or distributed version control in general.

What’s so good about it?

So, it turns out that DVCS is a viable alternative to regular, vanilla flavored version control. And by that I mean Subversion or CVS, the systems I’m most familiar with. There’s a few main points that convinced me to give Hg a try:

• It’s not too dissimilar to ‘normal’ source control, meaning it’s fairly simple to make the transition (add files, update, commit, revert etc work basically the same way)
• Rather than worrying about ‘everyone’ having a repository, the key thing is that you have your own local repository that’s just for you. So you get the safety net of frequent check-ins without having to worry about ‘breaking the build’.
• Branching is something a lot of people strenuously avoid with Subversion, because the tools just aren’t set up to handle it easily. Because of the way Hg tracks changes, merging branches is a simpler and more reliable process.
• Mercurial still supports the idea of a central repository, and in fact handles multiple staging servers (development, stable, release etc) fairly well.

I’ve been using Hg on a couple of projects for a while now, and I like it. The big wins for me are how simple it is to set up a new repository and how convenient it is to have a local repository for frequent check-ins.

Getting started

So what’s needed to get started? Well the good news is that all the tools you need are freely available and well made. First off, you really should read Joel’s introduction. After that, the command line tools are available from here. Using the command line is a great way to learn a version control system and really understand what’s going on – and it’s surprisingly simple.

Sooner or later though, you’ll want to look at some sort of GUI though to speed the process up. @bunnyhero put me onto MacHg which I’ve been using for a week or so now it’s been excellent. There’s a good screencast that covers the basic features of MacHg and will get you up and running straight away.

You may think that not having your version control inside XCode is a pain, but in fact I think it’s a huge bonus to separate IDE and version control. I’ve never seen source control handled properly inside an IDE (I’m thinking Visual Studio, Eclipse and XCode here). Version control is about files and folders, and I don’t want the IDE thinking it know better than me how to apply version control to a project by making ‘assumptions’ to try and streamline the process.

And finally, one of the strengths of version control is that it forces you to maintain backups of your code base. And the best backup is an off site one. Setting this up is a pain, right? Actually no, as once again Joel comes to the party and makes this easy. His company Fogcreek offer remotely hosted project management, bug tracking and version control tools, including support for Hg (they call their Hg toolset Kiln).

Obviously this is service you pay for, right?  Yes.  Unless you are a student or small company (or in fact anyone who doesn’t need more than two active users), in which case it’s FREE. Setup is trivial, and before you know it you can have a professional grade offsite Hg server of your very own.

While you’re at it, you also get their Fogbugz tools as well, so simple bug tracking, scheduling, wiki, code review and customer support all come as part of the free package. Nice. I should point out I get nothing for recommending Fogcreek, I’m just a bit of a fanboy.

Give it a go

So there you are, if you’re looking for an easy way to get into source control, or you’re sick of merging branches in Subversion, you might give Hg a go. All the tools you need are freely available for a small scale team and the learning curve is not that steep.

One last detail – I did have a little trouble getting MacHg to talk to Kiln . The problem is that MacHg needs the URL to include your username and the repository URL, and separates them with an ‘@’ symbol. Kiln’s user names are typically your email address , so MacHg get’s a little confused when it sees something like:

https://george.sealy@gmail.com@acornheroes.kilnhg.com/Repo/Repositories/Group/FaerieDev

Fortunately, the solution is fairly straight forward, you can ‘escape’ the ‘@’ symbol in your user name like so:

https://george.sealy%40gmail.com@acornheroes.kilnhg.com/Repo/Repositories/Group/FaerieDev

I’ve been tinkering around with the site layout, and given the WordPress interface, and my general lack of Web savvy, I’ve probably messed up something, so “I’m sorry”.  If you find any broken links or similar problems, please let me know and I’ll get them fixed up.

This site has been quiet for too long.  That’s why I’ve got involved with the #iDevBlogADay initiative.  There’s a bunch of great indie developers contributing as part of a regular roster.  If you want to follow all of us just subscribe to this feed.

Any good programmer is always looking for new tools and ideas to improve the code they write and to become more productive. For myself, fifteen years after I began coding professionally, this is truer than ever.

So when Noel Llopis started dropping odd comments on Twitter about ‘no classes’, ‘plain old data structures’ and ‘no singletons’ I was intrigued. How did this work? Where did this style come from? Did it lead to simple, effective code? Was it a style that would work for me? Is it a style that will work for you?

If you haven’t already read Noel’s article from yesterday describing his current coding style, then go ahead and read it now.

Take your time, I’ll wait.

It’s definitely an unusual style, and flies in the face of ‘traditional’ wisdom. So what’s life like in a world without objects?  Pretty cool, actually. I’ve been experimenting with it for the last couple of weeks, and here are a few observations that might encourage you to give this style a go.

The ‘Rules’

It’s hard to change style so dramatically, so a few rules of thumb are useful to help keep on track.  This style is sufficiently different that it takes time to get your head around it.  Prepare to spend some time writing (and re-writing) your first code this way.

• No classes.
• Use simple structs to store data / state information, making everything visible.
• Avoid dynamic memory allocation and pointers in general.
• Nothing is global – all data is passed as needed to functions that require it.
• Functions have a single purpose – for a given set of input data, generate an output, avoiding any side effects.
• Use TDD for everything.

TDD Becomes Much Easier

Test Driven Development (TDD) has always appealed to me, but to be honest my history with TDD is a bit like my attempts to build a model railway – plenty of well intentioned starts but no completed projects. Sooner or later I’d always give up on TDD because it just didn’t fit the way I’m used to coding.

But in a world of simple data and functions with a single purpose, TDD comes into it’s own. The tests you write drive the code to be as simple as possible with none of the cruft that typically accumulates in class definitions. And constructing tests is simple – create some simple test data, pass it into a function and check the resulting outputs. All tests follow this simple formula, with not a single pesky mock object in sight.

Lean Code And A Sense Of Progress

The resulting code feels resistant to bloat. Nothing is hidden, and every function has a clear purpose with no unexpected side effects. Time will tell if this pattern persists as the code matures.  I’m constantly surprised by the way the code evolves down unexpected avenues.

Every test, every function has a purpose that is clearly defined.  This simplicity has a huge appeal. A test and the code that goes with it can be written fairly quickly, and each additional test provides visible progress.

Struct Is The New Interface

I’m used to relying heavily on interfaces or abstract classes in my coding, and the lack of such an option concerned me somewhat. It still does – I miss the option to have a collection of ‘game objects’ and know that I can call Update() on all of them no matter what they are – Crates, Zombies or Flying Quesadillas.

What did surprise me was that rather than accumulating everything into a single class, the data naturally falls into a collection of several parts more in keeping with the idea of components in an OO system (composition over inheritance). For example, when I was writing a leaf particle system the resulting code combined the following bits of data – a mesh, an array of (generic) particles, an array of leaf specific particle data and a free-list for deleting and creating particles from a statically allocated array.

This fragmentation may seem unfortunate, but in fact it’s a strength. The functions that deal with a mesh are applicable to all meshes, not just rendering particles. The free-list struct and functions can be used anywhere that elements in an array need to be frequently created and destroyed.  Where in an OO design you carry around an entire object to each method or function call, with this approach you only pass around the ‘part’ of the object that is directly relevant.

Coding Is Fun Again

Ultimately this is the most important point for me. I’m enjoying coding this way. Progress is rapid, and through the use of unit testing, progress is very visible.  My free time for game programming is extremely limited, so the ability to write code in small, manageable chunks is a big win.  Refactoring can be undertaken with confidence, knowing that the unit tests and the basic structure of the code give some protection against unintended side effects.

This style won’t suit everyone, and it will absolutely terrify the Architecture Astronauts, but if you’re interested then give it a go and let me know how you get on!

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!

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.

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

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…

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.