Macguffin Games

Hats, Schizophrenia, and Indie Dev – Lessons Learned From Trying to Enter the IGF 2009

So, the last couple days slammed home several things that I’d already been considering.  Graham and I post mortemed the May-to-now timeframe, and the biggest problem we saw was that we seriously lacked project management.

But wait!  Scott, aren’t you a seasoned project manager?  Haven’t you produced games before?

Yep.  And it didn’t help.  Here’s why.As an associate producer and then producer on larger projects, I found it relatively easy to keep my mind focused on what mattered – are we on time?  How far off are we?  What are our unknowns and risks?  What are our plans for mitigating them?  But in those cases, I was wearing one hat, that of the producer.

Now, I’m wearing… I don’t know, five hats?  CEO, Marketer, Designer, Programmer, and Project Manager.  CEO and Marketer aren’t a problem in this scenario – I’ve been mostly focusing on the other three roles.  So on any given day, I’ve been working to some extent on design tasks, programming tasks, and here and there some project management.

Recent studies are saying that multitasking makes getting anything at all done more difficult.  I knew that was the case for me already, so I would try to focus on one thing at a time each day.  Since the largest pile of short term work I had was programming the game, I tended to spend a lot of my time on that – much less on the design and the project management side.

That was problem number one – not enough time spent being the producer.

I also realized something very interesting about wearing all those hats – it makes you a little crazy.

My friend Matt Burns and I ended up discussing this yesterday.  When your job role changes, your perspective changes.  He and I both started off in QA at our respective organizations, and then moved into production.  Once in production we found that we didn’t have that same crystal-clear focus on quality – we were more interested in shipping a game on time, on budget, and at an acceptable level of quality.  That includes making sure the right bugs are fixed – but never all of them.

Now we’re both indies, and find ourselves designing.  We’ve both now had to make decisions with our designer hats on that would have made us scream bloody murder as Producers… But again, we care about different things than producers do.  As a designer, I care about shipping – but first and foremost I want that game to be awesome.  Note that “acceptible level of quality” to the producer is often at odds with “this game is awesome” to the designer.

Ok, so I have to deal with these different roles, all bound up in me.  Fine.  Those amounted to:

• Producer: Will we meet our deadlines?  Is this a sustainable pace? What are the project’s risks and how will we mitigate them?
• Designer: Is this heading in the direction design-wise I want it to go? I don’t want to nail down things until I can play with them in a coded form.  I know I’m a noob designer, and that things are always different than what is in your head when they hit the computer.
• Programmer: What’s the next task? How does this new system fit in with everything else? I need to make sure my code is relatively clean and bug-free before I move on.

I concentrated mostly on coding the next task, not only because I had a ton to do, but because it was easiest!  Then I didn’t have to worry about design questions that I maybe didn’t know how to answer, and I certainly didn’t need to worry about the tough job of project managing a completely noob programmer (i.e., this guy).  When forced to answer project management questions (mostly by Graham, who was getting a bit concerned about our never being where we wanted on the date we thought we’d would), it was hard to do it as a project manager… there was also this programmer arguing that if we just keep coding, everything will work out, as well as this designer saying that we need to get further before we can make firm decisions about design stuff down the road.  All in all, this development cacophony meant that my answers were to sort of wave my hands in the air and keep coding.

That was problem number two – when I was actually trying to project manage, all the voices were talking at once.

So, we’re doing a couple things to mitigate these issues.  The first is that we’re moving to something like a schedule.  We now have a google doc that we’re listing out our tasks, our initial estimates, our time spent on that task to date, and our current expectation of how long much more work until that is done.  For any indies out there, I highly recommend this light-weight approach to scheduling, because if you do it it will help you become better at estimating your own tasks.  I could write another post on how to use a tool like this, but I don’t want to clutter up this post.

Second, I’m taking a full day every week to concentrate on non-programming, non-design stuff.  This means the biz dev aspects, the marketing and PR, and especially the project management.  Every Friday I’ll put on that ol’ producer hat and take a hard look at where things are at.  We’ll update our estimates and see where things stand.  If we aren’t going to hit our goals for December 1st, I want to know immediately and be able to correct course.

Probably this approach is a bit to “The Man” for some indies.  That’s fair – we’re building a really ambitious game here, far more ambitious than I ever advise any first-time devs to make on their own.  So I’m treating myself to stronger medicine than would maybe be needed for a smaller project.  I don’t think the updates will be onerous to us – the main downside is that Graham and I will annoy the hell out of each other with reminders to update our task lists.  That should settle down once we get in the habit.

So, yeah.  Listen to the voices.  But tell them to get in line and be civil.

Tags: Dev Blog, Game Development, heritage, indie, project management