Knowing your game is fun

Finally got around to posting this. Xmas wrapping is all done and now I have a little spare time to get to it.

So, where did we leave off? Oh yeah – how does a team know what it’s got on it’s hands, if it’s a 90+ metacritic or not? How does it know what to polish, what to tweak and so on as they enter Alpha / Beta?

Well, the EA method, as mentioned in another post, is definitely a step in the right direction. However on the downside it’s expensive and you also run the risk of exposing a Not Ready For The World product to those reviewers who will be reviewing it in the real world and thereby setting the precedent in their minds of how they’ll score it when it comes out. One of the problems with bringing reviewers in at this point is that they’ll write their review for you, pointing out what they think are the problems, then when the full on product comes out they will punish you for not fixing the problems they called out. Instant Fail.

Plus, as was mentioned before if you get 20 reviews and everyone points out stuff that is different that should be fixed, well how do you determine what to fix and what not given limited time?

Well the first thing I’d say is that this is all closing the stable door after the horse has bolted. If you waiting till Alpha/Beta to determine if your game is fun or not then you have already epic failed.

Yet strangely enough this happens a lot. With certain genres there is this feeling that “the game will be fun because it’s this genre” and there’s little attempt to make the game fun in terms of an actual process during development – everyone just assumes it will be ‘because it’s an FPS” – this belief that ‘fun’ is inherent to the genre. I’ve seen this happen with FPS games – where the company scrabbles around frantically at the end of development to put the ‘fun’ in the levels by placing new objects or AI – and also with racing games where everyone frantically tries to make corners less tight.

All of this can be avoided by playing the game all the way through development.

This is one of the primary reasons why I won’t personally hire anyone on my teams that isn’t a game player. If you don’t even have an opinion because you aren’t playing the game regularly then you are of little use to me beyond just grunt work.

I’m not expecting everyone to be a game designer, but I am expecting everyone to be able to at least tweak their work so it’s not obviously and fundamentally broken from a game play point of view.

However, even if everyone is playing the game regularly, part of the problem is that often those people playing the game can’t tell if it’s fun any more because of proximity. Usually people can tell if it’s NOT fun – that seems to be a universal skill. But what *is* fun or not?

Well, the solution there is obvious – the question spells out the answer. If you can’t tell if your game is fun or not, then get someone else to play it regularly. There is a thing called Kleenex testing which is where you get people in who have never played your game before, get them infront of it then never use them again.

There are focus groups too – the difference between focus groups and just getting random people in to play is that focus groups try and answer a specific question (or set of questions). They have a quiz at the end of the play test session and often these questions can skew what the answers can be. By loading the question set you can often prove whatever you want.

Better by far is just plonking a bunch of people infront of the game, give them a controller, step back and let them play videoing the whole thing as they go. This will show you issues you will never have seen before or have been having internal arguments over in an unarguable way.

At the end of the session, let those who played speak for themselves without too much prompting. Questions like “How did the movement feel?” is ok. Questions like “How was the movement in a scale of 1 to 10, 10 being fastest” are leading and not good.

Let them tell you what it is that needs to be fixed or not – you’ll be surprised at what people pick up on. When more than 3 people agree on something that needs attention then it becomes a priority in the To Be Fixed database.

The important thing is that you start doing this during pre-production and do not stop while in production. Doing it every month or so will help guide your polish efforts, and is immensely morale lifting to a team deep in production to hear the good comments that come out of this kind of event.

Don’t wait till Alpha to stick the fun in. Be doing it all along. You know it makes sense.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>