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
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.

Constraints
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.

Elegance
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.

Results
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.

Game Development is not Software Development

Many developers believe that games do not need a central creator figure and that customer focus and willingness to adapt are what matters. I basically disagree with this idea on the basis that games are not software applications which can be definitively made better according to an objective standard. They are entertainment, which relies largely on subjective perspectives of what works, regardless of whether they are so-called interactive or passive entertainment.

Quite a few of the myths of game development derive from ignorance. Game development is a very narrow, insular field in many ways, and is not a culture remarkable for its ability to embrace and learn from outside itself. As a result, many of its myths are legacy ideas that have developed happenstance over a number of years and clogged up its arteries with all sorts of guff. The software-analogy is perhaps the largest of them all.


What this myth concerns is the idea that the techniques of software development can translate over into game development. At the level of the lone gunman, like my friend Cliff Harris, a developer can work in whatever way he or she chooses. When working on a larger scale, such as on 'The Movies', however, things become very different.

Most games are primarily made of content, not software. In any given game
development team there are far more man hours devoted to what goes into the game and how it works as a piece of entertainment rather than the engineering of it. As a result, iteration-led development always has to keep an eye on the fact that while changes in a regular software development environment usually don't cause too much trouble if managed correctly, significant changes in a game development environment can (and do) throw an awful lot of content work away.

A simple example is a change made by code in the middle of a project which streamlines the way that a scripting system works. In software development this may have some knock-on effects in terms of user interface and documentation, but that's not too heavy as the content to code ratio of software is low. In a game development environment, such a change can throw out months of work.

Content-code issues aside, the more significant difference between the two, philosophically, is that most software development is focused on making an objectively better product through better features, better implementation of features, or both. Game development is focused on making better gameplay, which usually results from less features, a deliberate impediment to those features, or both. Software applications are built to drive productivity. Games are built to challenge and surprise.

Software applications become objectively better.
Games become subjectively better.

As a result, adopting the mindset of software development into game development is pretty much the same as adopting the techniques of telecommunications engineering as a means to becoming a better sculptor. Software and games make look similar when you're staring at the code, but they are actually worlds apart. To make a better application you need an engineer's mindset driving the process. To make a better game, you need the mind of an artist.



Creation vs Innovation
What's at the root of the software analogy myth is an inherent distrust of the creative. This largely reactionary viewpoint stems from a rejection of outsiders coming into game development. The culture has a long history of its own, and many developers instinctively feel that those people who foisted FMV and long boring talks about interactive storytelling and whatever else just don't get it. Writers, painters, musicians, what the hell do they know about games, right?

Maybe not much. But what they do know a lot about is creativity, and creativity is something that isn't just on a low par in games, it's downright absent. Instead, we plumb for talking about "innovation".

Innovation is a funny concept to apply to entertainment. Innovation is the stuff of building better products, better software, that which is more efficient and effective. You innovate features for an MP3 player, a way of building a house or kind of cola. But do we innovate in entertainment?

Well entertainment certainly goes through stages. Camera techniques in television shows, for example, change all the time. They are often highly fashion-led, however. This week's shaky cam is last week's news. Techniques are always on the move, but they are only the side show of the implementation. What matters in television shows is whether the content is surprising or not. The innovative takes a back seat to the creative.

The same is usually true of games. Most games, even many of the most successful games, are not innovative. Starcraft is the same game as Warcraft 2. GTA3 is a straight-up-and-down drive and shoot game. Bioware's rpgs have been doing the same thing since, like, forever. Max Payne does not do anything not done before. While it is true that some games have exploded onto the scene in a hail of innovation, the reality is that most of them have not, and most of the most fondly remembered games are so remembered for their creative elements. The stuff that made us laugh, swear, jump out of our seats in fright and so on is the creative parts in games.

As we go forward, the innovation angle is becoming less and less relevant because innovation is limited. Yes, the Wii is going to shake up how things are controlled for a little while, but you and I both know that in 18 months from its release the platform will play host to a variety of "look what I can do with a wavey controller" cloneware, but the really interesting games will be the creative ones.

Innovation is a way to solve a problem or explore a feature, and developers love that. Creation, however, is what makes games memorable and gives them depth. That's what them writers and artists and all the rest of them can bring to the table. We've seen it before in roleplaying games and the old graphical adventures, and we can see it again. But only if we can learn to change and accept the creative.

Otherwise it's orcs and elves, this time with 3D positional controllers, until we all get utterly bored to death.