I attended Freeplay Independent Games Festival on the weekend and had a chance to try out Antichamber for a little over an hour (sorry to all the people in the queue behind me). We were there to show off Battle Group as we were a finalist in their indie game competition. Part of my discussion with Alex was about our when our respective games would be “finished”. Today I’m going to explore this a little further.

I’ve heard Alex speak a number of times in the past and a recurring theme is that he is always being asked when his game is finished, and when it will be released. Alex has some strong views on this that I completely agree with, relating to quality levels required before a game is ready for release. Our own game Battle Group has been pushed back from our (internally planned) release date a number of times in it’s 4 month development. It’s a recurring theme on every game I’ve worked on, both independently and at larger studios, they are always late. The question is, how can we objectively determine when the game is finished?

“You’re game is finished when someone who hasn’t played it before can play through it’s entirety without assistance” 

Lets dig a little into what this means. Firstly you (or a few key team members) need to sit and watch people play your game. If you’re not doing this, your game shouldn’t be released, period. Without sufficient playtesting there’s no objective way you can determine if your game is ready or not.

Someone can only play through your entire game once you have no show stopper bugs. I can play a game I’m working on for days on end and never come across an issue which a play tester finds within the first few minutes of playing. The game also needs to teach them enough to be able to play through it’s entirety without your help. This is a really difficult task when watching someone make seemingly simple mistakes in your game. I’ve spoken about this previously with “Virgin” playtesters and spending the weekend watching people play Battle Group only reinforced this for me. If you have to help someone through a certain part, something is wrong.

Related to bugs and assistance is the requirement that you are happy to show people the game in it’s current state. This seems like a no brainer, if you’re not happy to show someone, why would you release? Surprisingly, I’ve seen a number of people so desperate to “just get it out there” that they break this rule. They were all apologies and excuses when I tried to play the game but they felt they were still ready to release it to the world, as if people they don’t know would be more forgiving.

When deciding when a game is finished, there are two areas that people run into trouble:

1. Some people fall into the “it’s never finished” trap. They are usually small teams that aim for absolute perfection and are never happy with the game. These games often disappear and the team gets bored and moves on to something else.

2. At the other extreme are games that are shipped far too soon. These often come from larger studios with external time and money constraints imposed on them.

Either extreme is dangerous and obviously we want to aim for the middle ground between these. Knowing which end of the spectrum you are more likely to favour is important so you can set expectations at the start of the project. The further a game progresses in development the easier it is to diverge towards one of these extremes. When talking about setting the quality level before you begin production on a game I use the analogy of going out drinking. It’s important to set the number of drinks you plan to have in an evening before you start drinking as once you’ve started down that path, your judgement is impaired. The longer your on a project, the more impaired your judgement becomes. Either wanting to “get it out the door” because your sick of working on it, or not wanting to waste the months you’ve been working by releasing an imperfect game.

Only by setting your expectations at the beginning of a project can you have a reasonable chance of setting the quality bar at a safe level. Look at the team makeup, objectives of the game (retail success vs portfolio piece) and project budget/length when deciding what quality bar to aim for.