It’s recently become apparent that as I am doing a lot of game design, and seem to have loads of opinions on the subject, that I should acknowledge the fact, at least to myself – that my interests in games go further than programming.
I’m also very wary of ‘design practices’ as it’s been my casual observation that, at least in the fields of creative or programming work, they seem to be invented with the object of selling books and brainwashing management to ultimately sell even more books, rather than really helping in any tangible manner.
HOWEVER, I can get over this stick in the mud attitude and describe two design practises that we’ve been using lately:
User centred design
This one I was taught at a design workshop by Ylva Fernaeus, Sara Ljungblad and Mattias Jacobsson from SICS, but I recognise it from elsewhere, and it was good to have it explained in full.
One part of ‘UCD’ (as I’m sure it’s abbreviated to to confuse the initiates) is called user stories. You make up a fictitious person who might play your game, and describe who they are, why they are playing and what their motivations are etc – you can get quite carried away with this, and within sensible margins, it seems to help.
Then you describe the experience of the game from their point of view. This means you can leave out all the details and focus on what you want them to feel – from the inside.
You do this for a handful of people with different backgrounds. It obviously helps if you have a little bit of experience with the sort of people you are imagining the reactions of. We’ve been using our family members as inspiration, which makes it a bit easier.
The result of doing this is thinking about the players rather than the game, and while it sounds simple, forcing you to think like this can reveal some surprises.
This one sounds terribly technical, and I picked it up at Sony. It comes a little later, once you have a clear-ish design and you start to write the code. The idea is that you implement only enough to have a single full experience of your game. For instance, if you can choose between a variety of characters – in the vertical slice you only implement one, and implement it fully. When it’s finished, the vertical slice should show you one possible path through the game, but no more.
This is generally used to persuade publishers that their money is safe, and that the game is a winner with the minimum of development expense required.
However, I think it can also fit with the user stories, if you take one of your fictitious players (perhaps the one who represents the strongest demographic you are interested in) and implement the vertical slice as if you were making it for them, you are forced to face some of the most important decisions first.
Then, and this is really the key thing – you can deal with these decisions while the game is still malleable, both in terms of code, and in terms of your understanding of it in your head, and you are in a much better position to come up with the solutions needed.