Friday, October 27, 2006

A Method of Game Design, part one

I've decided to write up a method of creating games from the ground up for a few reasons. One is that while debate is all well and good, translating it into action is the step almost never taken. Over the last three or so years I've talked about all manner of ideas, from removing the document from the design process to naming issues, breaking down the story barrier, the language barrier, the importance of the creator figure and other areas. These are all, in their way, fine talk, but they do not constitute anything coherent.

My second reason is that there are a lot of people out there, working in the field of game design and level design, for whom the whole debate over games has grown so vague and abstract that it disconnects from an actual method. As a result, a whole host of ad hoc methods have been adopted across the industry (especially in the West) that have no business being anywhere near the creative and innovative processes and are actively destructive.

Lastly, because I fundamentally disagree with many of the official methods that have received the stamp and seal of approval. It annoys me greatly to see a tome of supposed game wisdom talk in-depth about a method which actually doesn't work, because the stamp of officialdom in print is such that those methods become accepted practise without any real evaluation. Many design books sit on many shelves, lending the air of wisdom and finality to many a designer or producer, but in practise they are usually very far off the beaten track.

Central to this method are four simple tenets:

  1. Fiction is important
  2. Constraints are important
  3. Elegance is important
  4. Results are what matter

Fiction is an important part of the game design process because without fiction, all you have is abstract elements. Abstract elements alone do not usually make for an interesting game because we have all played Tetris etc, the most abstract game of them all, and so all abstract games inevitably have the same overriding feel of Tetris etc. Once you have played a few purely abstract physical simulations, you have played them all. Aside from all the basic abstractions and their deceptively purist character, all games need a fiction.

Fiction breaks down into two constituent components: inner fiction and outer fiction. Inner fiction is basically the root defining idea of the game. Outer fiction is the mythology, characters, names, dates and background of the game. While almost all games need an inner fiction, an outer fiction is optional. I'll explain their relationship to the method more fully in a later post.

The most common problem that I have seen in game design over the years is a lack of appreciation of the need for constraints. Many well-intentioned designers have traveled down the road of writing lots of idea documentation and creating large levels in 3D tools, only to find that these ideas and levels actually don't work in-game. What these designers are failing to do is to fully consider the constraints of their project. There are five general kinds of constraint:
  1. Physical constraints
  2. Situational constraints
  3. Client constraints
  4. Fictional constraints
  5. Adopted constraints
Constraints are often perceived as limits to the designer's imagination. They are that, but the ability to work within limits is what distinguishes a designer from someone who just has a vibrant imagination. Constraints are hard limits on what can be done, but in so doing they are also enablers. The reason why so many great games come from the past of gaming is the same reason why so many great books come from cultures of poverty, and so much great music comes from the streets. Those environments naturally constrain those artists, and the same is true of constraints within the game workplace.

Another common problem that many designers (and others) regularly fumble is the problem of special-case thinking. Special-case thinking is the practice of thinking "Wouldn't it be cool if" without considering the ramifications. Bad design is usually full of special-case ideas that don't sit well together and don't produce either cohesion or progression. A special-case idea is easily identifiable as one which the game design then has to prevent from being abused by artificial means.

General-case thinking, on the other hand, is a sign of good game design. Most special-case ideas are in fact able to be replicated in a general context, provided the constraints and fiction permit them, and the ramifications do not produce any artificial restrictions. A game design should be based on enough general-case ideas to produce results that engender cohesion and progression. General-case ideas form the basis of game mechanics and rules, and general-case thinking is elegant.

Elegance is extremely important in any project. Players relate to elegance because it means that they do not have to spend a lot of time understanding how to play the game and instead can focus on how to play the game well. Elegance is also a key factor in determining how much effort is actually involved in the project as it makes the permutations of the project easy to comprehend. Lastly, elegance helps convey the core reason to play the game and highlights its strong selling points. Most videogames are not at all elegant, and they suffer greatly for it.

Lastly, you'll see me talking a lot about results-oriented design. The problem with theory is that it is all theoretical, meaning that everything sounds good in theory until you bring it into the real world. A game design document as a large repository of knowledge about the project sounds like a good idea in theory until you come up against the reality that most people do not read game design documents.

A designer must have results in mind at all times. They typically have intended results in mind but intention and actual result are two very different things. Having a results-oriented disposition means that you have the ability not only to see what an idea or constraint is intended to achieve but also how it specifically works in the game, what it will take to get it to work, and what the drawbacks of not getting it to work actually mean.

Intention, on the other hand, gets you nowhere because everyone reads intentions in different ways. A competent designer knows full well that the road to hell is paved with good intentions. Follow-through and the ability to think in terms of results, plan for them and execute them is what counts.

Next week: Understanding the paradigm.

Particleblog's comments have moved to The Play Room.