First published Develop 27 (April 2003) as 'My Karma Ran Over Your Dogma'

Wise blind elephants

"Five wise, blind elephants were discussing what humans were like. Failing to agree, they decided to determine what humans were like by direct experience.

"The first wise, blind elephant felt the human, and declared, 'Humans are flat.'"

"The other wise, blind elephants, after similarly feeling the human, agreed."

What is Game Design?

It would be tempting to think that it is readily apparent what the process of game design involves, but anyone who has looked into it will have learned that if you ask one hundred people to define game design, you will get one hundred different answers.

Rather than attempt to force a consensus (an endless and fruitless task), for the purposes of Zen Game Design, we shall invent a definition:

Game Design is the process of co-ordinating the evolution of the design of a game

Sometimes, the game design work is complete long before the end of the development process. Mostly, however, it is an ongoing process which only ends when the game is on the shelves.

Game design components can come from a number of different participants, including the producers, the programmers and the artists, as well as the game designer themselves. The game designer's task is sometimes to create missing components, sometimes to integrate conflicting components and sometimes to ensure that all the components will combine to create the desired gameplay experience.

What is Zen Game Design?

Zen Buddhism is a branch of the Eastern religion in which the underlying message is implied, rather than stated. Indeed, one of the key concepts in Zen Buddhism is that enlightenment cannot be expressed in words, as one must make a leap beyond the literal - it must be experienced, not learned.

It also includes the idea that there is no objectively correct and definitive perspective on anything - all experience is relative.

It is this idea which forms the basis for Zen Game Design.

The Principles of Zen Game Design

Zen Game Design is built on two basic tenets, which can be summarised as:

These are the short forms of the principles. There is also an implied 'zeroth' tenet:

This caveat may seem trivial, but there are some people with no appreciation for the work of the game designer, or who believe that the distinction between a game designer and a programmer is irrelevant. It may be true than some programmers can carry out game design, but it is also true that some programmers can draw. That does not equate to there being no distinction between programmers and artists.

The First Tenet: There is No Single Method to Design

Depending on your perspective, this principle will either seem abundantly obvious, or blatantly incorrect. It is important to remember that although someone may hit upon a good method for game design, that does not mean that the method is applicable to all cases, that it will always be relevant or that it is equally useful with all types of games.

The long form of this principle is as follows:

The more methods you explore, the more options you have

This is the nub of the concept. If you use one game design method, you have only one way of looking at a problem. If you have explored a dozen different game design methods, you have 4,096 (that is, 2^12) different ways of looking at a problem! (This statement is supposed to be evocative, not to be taken literally).

The more different game design methods and philosophies you study, the closer to an infinite set of game design choices you will get.

Seven Varieties of Design Methods

There are more ways to approach game design that could be summarised, but the following represent seven common methods. For each, a grossly simplified expression of the method is given.

• First Principles

  A game that is developed from first principles takes a long view of the design process. The steps could be described as:

  Goals -> Game World Abstraction -> Design -> Game

  Using this method, you start by determining what you want to do, then you determine the nature of your game world abstraction. Only when you know how your game world will be abstracted do you proceed to design, and then implementation. Any game designed by Shigeru Miyamoto (Zelda, Mario) is likely to show evidence of this 'first principles' approach.

• Clone & TweakThis is perhaps the most common design method in use. The steps could be described as:

  Existing Design -> Modified Design -> Game

  In essence, you pick an existing game (generally someone else's), adopt the pre-existing game world abstraction and then modify it to suit the needs of the 'new' game.

  It's quicker and easier than creating a whole new design concept, and for this reason is quite appropriate to many short time-budget games projects, and for sequels. Why start from scratch when you can learn from your previous abstractions and improve upon them?

  There is, however, little or no excuse for using this method on an original AAA product.

• Meta-rulesSome Game Designers are attempting to produce a set of meta-rules, sometimes believing they are uncovering "the rules of game design", sometimes merely trying to provoke debate. The implied method is generally:

  Meta-rules -> Design -> Game

  Two very different examples of a Meta-rule approach are Noah Falstein's 'The 400 Project', and Ernest Adams 'Dogma 2001'.

  'The 400 Project' is involved in identifying 'rules of game design' and ascribing to them a hierarchy of precedence such that some rules trump other rules. The approach can produce some interesting discussions which can help inform design decisions, and this is probably the greatest value of this method. (Whether the formal 'trumping' structure is useful or an ever-growing encumbrance is open to considerable debate).

  'Dogma 2001', by contrast, was not intended as an all-encompassing design method, but rather as a mental (and perhaps pragmatic) exercise for game designers to provoke original thought and return the game design focus to the design, and away from technical issues.

  Any collection of meta-rules can be a useful method to employ, provided it is recognised that these "rules" are not universal laws, but rather formalised observations.

  It is also doubtful that any design process can proceed using only this method.

• Expressing TechnologyIn developers without an in-house designer, design can often be more about finding roles for new software technology. Quake is an example of a game which demonstrates the use of this method. The method can be expressed simply as:

  Technology -> Game

  Often, this method is combined with a Clone & Tweak approach. It's not a very interesting method from a design point of view, but it can be useful - although your technology has to be top-notch if you are going to produce something worthwhile.
• The Frankenstein ApproachWhen you have to give up on your first design and start from scratch when you've already produced a sizeable chunk of software or art, the Frankenstein approach comes into its own. Conkers Twelve Tales becoming Conkers Bad Fur Day is a good example by all accounts, and Half Life too seems to have made use of it. The method works principally:

  Materials -> Design -> Game

  Like many methods, it generally works in concert with other methods. A game designer may be involved in producing an entirely new game world abstraction, or it may be a simple case of a well chosen Clone & Tweak.

  Obviously this method is primarily used to rescue a project in trouble, but it can also be used to produce a new game from existing materials by bringing in a new game designer to reorganise and abstract a new design from the existing materials.

• Story-driven DesignGames such as the classic text adventure The Hobbit, and more recent adventures like Broken Sword and Shenmue involve use of a method in which the story that will be told drives forward the design process. The method can be expressed as:

  Narrative -> Design -> Game

  Although this has been mostly used with adventures, any game with a plot can benefit from the use of this method.

  Note that the narrative can be generated by the employment of a variety of different methods. One of particular note is design-integrated narratives, a first principles approach which can be expressed as:

  Goals -> Game World Abstraction -> Design-integrated Narrative -> Game

  The idea here is that you identify both your game and narrative goals first, then you produce a game world abstraction that supports these goals, and from there develop the narrative and the game design in parallel.
• Iterative Design ("Design by Committee")Under the right circumstances, iterative design can be a very powerful method, expressed briefly as follows:

  ->

  Meetings Design -> Game

  <-

  The idea is that you develop your design through the process of developing a design-version, holding team meetings to revise the design and repeat until you get everything right, or run out of time.

  It can produce excellent games. It can also cause projects to overrun time and cost budgets and get cancelled. Historically, there are many more projects in the latter category than the former. In short, be very cautious about using iterative design as your core design method.

When we talk about 'the design', what we are really referring to is the design documentation. This is roughly equivalent of an abstract specification in industrial software development, and offers the same advantages.

Even though the design documentation is almost certainly maintained by a single individual (usually the game designer), design isn't the sole prerogative of the game designer by any stretch of the imagination. It's just the game designer's role to co-ordinate the design process.

The Second Tenet: Game Design Reflect Needs

Why should it be that there is no single, ultimate solution to the game design dilemma? It is because every game is experienced by more than one person.

Perhaps if you were creating a game that only you will play, you could develop a single, perfect design method. Provided of course your tastes don't change...

The long form of this principle is:

Game design must be egoless, balancing the desires and needs of all participants.

The idea that the game designer must be egoless may come as a shock to some, especially since many game designers hide a secret belief that they are the greatest game designer in the world. (However, unless your credit cards read 'S. Miyamoto' this is unlikely to be the case).

To understand this principle, we need to look at who are the participants in a game project.

Participants & Advocates

The notion of a 'participant' describes anyone with an interest in the project - it could be the development team, someone with a financial stake in the project (such as the publisher) or it could be the audience. All these people participate in some portion of the game's life - both before and after release.

However, it is self-evident that it would be impossible for every participant in a game to be involved in the design process. Because of this, certain participants function as advocates for groups of participants. For example, the External Producer generally acts as the advocate for the Publisher.

By looking at different participants in a game project, and different advocates, we can gain a different perspective on the design process.

Seven Varieties of Participants

Who participates in a game project?

• The AudienceThe audience's goal is to enjoy the game, and whatever else you do, you must satisfy this participant! Since we cannot truly know the audience's attitudes to a game before it is released, we need models to allow us make informed decisions.The most basic audience model in use is:

  "All games players think like me."

  It is entirely useless unless you are the only person who is going to play the game. More sophisticated models recognise demographic groups, and attempt to learn the tastes and needs of these groups, for example:
  

  Casual, Hardcore	(Basic demographic split)
  Hardcore, Testosterone, Casual, Parental	(ihobo demographics)
  New Hardcore, Lifers, M&M's, Generation Next, Social Gamers, Golden Gamers	(Bennallack demographics)

  Focus groups can help provide feedback from the audience as well - but it must be mediated intelligently. The goal of a focus group is to assess audience response - not to yield control of the design to a dozen strangers!
• Publisher (Advocate: External Producer) The publishers goal is to get the best return on their investment - and it is never too late for a publisher to pull the plug if they will not get a return on their investment. The usual advocate for the Publisher in the development process is the External Producer; their role is to represent the needs of the publisher in terms of reducing the cost of development and maximising the profit (since both these work towards a better return on the publishers investment).Some developers resent the publishers involvement (or interference) in the development process - but this is generally because the External Producer is trying to usurp control of the design process. When an External Producer acts wisely, as an advocate for the publisher's needs, there is not a problem.

  Just in case, developers are advised to follow the Steel Monkey's lead and have a clause in their contract allowing them to dismiss the External Producer if they are unsatisfied. Getting the right advocate for the Publishers needs makes the whole process go more smoothly.

• Developer (Advocate: Producer) The internal producer mirrors the role of the External Producer, acting as an advocate for the developer as a whole. The developer's goals vary. They want to get money for salaries, certainly, and they may (but not necessarily) want to turn a profit as well. But for the most part, the developer's goal is to professionally produce a game, so meeting milestones, and satisfying the publisher are inherited goals. From the Producer's point of view then, the developers interest in the design is that it should be achievable, and as project status changes, changes in the design may be required. It is then the game designer's role to adapt to these changes.
• Programmers The goal of the programming team is to implement the game, and as such they need the power to interact with the design and ensure that it is realistically implementable.In many cases, the programmers are also representatives of the audience, but like focus groups this does not mean that they should dominate the design process. Neither should their views be ignored.

  It is desirable for there to be an advocate for the programming team as a whole (the lead programmer, usually). Issues that the programming team need to report can then be advocated on their behalf, which is more efficient than each programmer trying to influence the design process individually, although this is less of an issue with smaller teams.

• Artists The artists parallel the programmers, and also benefit from an advocate (a lead artist) to bring forward their issues.The producer should be able to turn to the artists for advice on art and animation issues in the same way they can turn to the programming or design team for advice on their specialities.
• Marketing/PR Their goal is to sell the game to as many people as realistically possible. This may mean being an advocate for the audience, but more often it means ensuring that the game is a product that can be marketed.Like it or not, the marketing and PR teams are important participants in modern games development. With this in mind, it is desirable for them to have an advocate in the development process - rather than having them try to make changes to the game for marketing purposes when it is realistically too late to do so.

  Since few marketers are design-literate, the game designer or producer sometimes has to act as an advocate on behalf of them. The important point is that there be dialogue between marketing/PR and the development team at some level.

• License Holder These days, more and more games have an extra participant: the license holder. Their goals are to ensure that their brand gains something from the game, and also (like the publisher) to make money from it.The situation is parallel to marketing - the license holder should be represented in some form, and the producer or game designer should be advocate for them when necessary. Once again, keeping dialogue open throughout development is preferable to showing the finished game to the license holder and then being forced to make changes when they are most expensive. It is always cheaper to fix problems at the design level, and therefore always preferable to resolve issues earlier rather than later.

Saying that the game designer's role should be egoless is in effect saying that the game designer doesn't reflect their personal needs in the design process, they act as an advocate for all participants to the best of their ability. They do this at the design level, whilst the producer does this at the production level. In this way the role of producer and game designer are closely related, but they are not identical.

To be a good game designer is therefore to listen to and comprehend the needs of the many different participants in the development process.

This doesn't mean that there is no creative role for games designers - on the contrary, finding design solutions that satisfy all participants is a highly creative process, and individual game designers can and do express their creativity in how they choose these solutions.

Example of Participants

An example will serve to clarify the concept of participants and advocates.

Let us consider a hypothetical game and the design issue of save games. Assuming a basic demographic split model, we can see the following model with respect to save games:

• Casual audience: they want to be able to save anywhere, any time, because they are fitting game playing into their life and want to be able to pick it up and put it down.
• Hardcore audience: they are willing to play for long periods of time, and their interest in save games is that the save mechanism does not destroy the challenge of the game.
• Programmers: their chief concern is that the save mechanism be technically feasible. The relevant data to be saved depends on the game world abstraction, so it is worth considering how save games will work at a suitably early stage and acquiring the programming team's approval of the intended solution.
• Developer/Publisher: with respect to save games, which are usually not a major drain on development resources, the developer and publisher act as advocates for the perceived audience for the game. They can do this crudely, by imitating what other companies have done, or they can do it in a sophisticated manner by studying the market.
• Artists/Marketing/License Holder: with respect to this issue, these participants have no special role, and do not need to be advocated.

The game designer, having looked at the needs of the participants is thus better informed to make a decision on how the save game mechanism should be designed.

Return to the Wise, Blind Elephants

At the start, we told the parable of the five wise blind elephants who, wondering what humans were like, tried to learn by direct experience. The moral of this story is that an individual's perspective dramatically affects their opinions on all things.

You cannot learn objectively about anything - including design - you can only be aware of your limitations and be willing to talk to (and more importantly listen to) the other participants in the design process.

By learning many different methods, the game designer has a varied toolkit; by learning the needs of many different participants, the game designer has a balanced outlook. Somewhere in between the two lies Zen Game Design, and the goal of making better games for everyone.

International Hobo