Thursday, 24 February 2011

Spring Cleaning: Lessons Learned in Indie Development

Dustpan brush with Spring flowers in bristles

Although I've been keeping everyone up to date, through Twitter and Facebook, as to which iOS games have been eating into my productivity, I haven't blogged for a few months. This was by design, as part of my master plan to duck my head below the parapet, plant my face firmly on the grindstone, and get a significant chunk of Huscarlas coded.

It has been a mixture of successes, intermingled with what I would term as "lessons learned". The most useful revelations to come out of my Winter coding exile have been about two things: project scoping, and time planning. Before your eyes wander away to click on something shiny, and not at all like a wanky management term, let me explain why these epiphanies could be interesting to you.

Before sauntering up to the indie-developer table, and presenting my jib for inspection, I'd spent many years consuming developer-written articles on websites such as Gamasutra, Edge and develop. A good number of these focussed on the very two concepts that I present today: scope and time management. Even those articles ostensibly about something else would somehow manage to slip a paragraph or two in about these subjects, just for good measure. How, then, after so much on these topics having already been written, could I possibly have anything new to say? Surely you can just read the same articles and be done with it?

The point is that I'd read these articles, found them fairly dull, and went away thinking that I'd understood what the authors wanted me to learn. I hadn't, and I don't think you can unless you've walked on your own precipitous path of an unscoped, unplanned project.

In reading them, I'd always thought that the principles discussed were only applicable to game projects with large teams with intimidating weekly overheads. The examples given were almost always framed by such projects, which is unsurprising given the dominance of big-budget studios over the last twenty years. As a one-man micro studio, I found it difficult to bring their lessons to bear on my own day-to-day operations.

Here then, I distil my own practical advice from these well-worn topics, filtered through the unusual perspective of a lone wolf.

  • Lesson: Do not invest any time into achieving something unless you know exactly what the finish line looks like.

    Learned: I knew that I needed an artificial intelligence for Huscarlas that could move optimally through procedurally generated levels. After reading some enticing articles that vehemently insisted that "navigation meshes" were the future of space representation, I thought I'd try to implement this type of structure. This technique had no published practical examples, and so I started from just the basic theory, with no notion of what the final logic should be. Inevitably, I wasted a couple of months theorising and working on it, before finding out that the examples the articles had cited were couched with provisos, making the technique impractical for my game.

    I will never work from hearsay again. Before diving into implementation of an unfamiliar concept, I now need to have read and understood a source that gives a complete explanation.

  • Lesson: If there is an existing, complete solution to what you're trying to achieve, then use it. Don't try and reinvent the wheel, no matter how interesting a diversion it might be.

    Learned: After the punishing distraction of trying to implement navigation meshes, I realised that plenty of games must have, and must still, use a different approach. Nav meshes are a new concept, so something must have pre-dated them. After a small amount of digging, I found well documented, top-to-bottom solutions for using a regular grid of waypoints over a level. This technique is theoretically not as flexible, nor as efficient as using a nav mesh, but it's tried, tested and completely suited for my purposes. I managed to build a working implementation in a couple of weeks.

    As a small operation you've got to pick your battles. If you offered me the time I'd wasted indulging in unnecessary R&D in return for having never heard of a navigation mesh, I'd take your arm off at the elbow.

Time Management
  • Lesson: Wake up each day knowing what needs to be done, and precisely where you're going to start.

    Learned: Procrastination will unnecessarily elongate your project, increasing your costs and eating away at your fragile ego. As both project manager and implementer, you should know exactly what you should be doing at all times though, right? Nice in theory, but I've found that without an up-to-date, relevant, and manageable "TO DO" list, the sheer scope of what I'm trying to achieve can fix me in its headlights.

    As well as a whiteboard list of tasks to reference, every morning I conduct a project-wide code search to turn up "TO DO" comments that I've left for myself. This search will always contain a unique line that begins, "TO DO: Start Here...".

    If I'm ever in doubt, I just do what the man says.

  • Lesson: If you are unmotivated or stuck on a part of your project, understand what can be done in parallel and waste no time in shifting your sights to a more appealing target.

    Learned: There should be no quiet days at the office when you ARE the office. Inexplicably, sometimes it's impossible to get revved up about parsing XML files, or optimising rendering algorithms. Unfortunately these sorts of mundane tasks will befall anyone attempting to create a game by themselves. Instead of pouting, or trying to wade through your disinterest like treacle, it's best not to take such a bloody-minded approach, and just do something different. I openly prefer design to programming, and when I feel a malaise coming on from the lack of reusable code that's available to me, I've learned to switch tasks.

    It's both daunting and empowering to have to perform all the roles required to create a game. On the downside you'll have to do the boring stuff at some point. On the upside, you don't have to do it right now.

Looking over these lessons, I realise they can be applied by anyone who multi-tasks, and I'm sure they've been incubated throughout my career.

I battle daily to take my own advice, but if I've lost momentum, or lack motivation, then these simple rules have proven to rejuvenate me.


  1. Thanks Tom. I think it's good to have dogmata written down for reference during moments of weakness.

  2. Hey Jeff,

    Really great advice, I shall pin it to my home office wall when I go indie in 2 weeks!

    See you at the IGDA drink next week.


  3. Thanks Rob, it's exciting to hear you're going indie. I'm looking forward to hearing your plans at the IGDA meet.

    Make sure to keep an eye on the #LondonIndies Twitter tag, so you can keep up to date with gatherings of the local community. The rule of thumb is the first Monday of every month at The Crown in Islington.