Game design as Process

Posted by Jere on April 10, 2006 at 03:36 PM

Perhaps the most critical event in playing a game is identifying the goals of the game. If done improperly, even elegant mechanics or fully realized characters may not serve the group’s or the player’s real needs. Without accurate goals the mechanics chosen or designed run the risk of offering solutions for which needs do not really exist. There are many ways to identify these goals; I’m just going to discuss the method I use.

The model I use has, at its heart, the intent to guide the design, development and revision of the games I run (and as stated elsewhere I’m a big fan of being prepared for revision). Careful analysis work is absolutely critical prior to the start of a game, this analytical work at the front-end of the gaming experience and for most people is usually little more than a choice of premise, mechanics and a simple, usually verbal, social contract.

Identify Goals of the Game

The first thing to do is clarify the goals of a game. Usually we start with a fuzzy goal that has some abstract statement about the intended theme and genre of the game. To get beyond this I find it helpful to write the gal down (yeah Livejournal!) and then indicate the type of play that would demonstrate that that goal was working. Try not to be too critical at first; just write everything down that occurs to you. Next, sort through the statements for those that best represent what is desired in the game. Now incorporate each of these indicators (there may be one or quite a few) into a statement that tells what the game will do. As a last step, examine the goal statement and ask yourself this: If the game achieves or demonstrates each of these would you agree that the game achieved its goal? If the answer is yes, then you have clarified the goal. This type of goal analysis allows us to move to meaningful agreement on what we’re all getting together to do when we game and build consensus.

Recruiting

Recruiting is a sub-process that such complexity that it deserves posts of its own. I find that the better job I do at identifying the goals the easier it is to recruit. I’m a firm believer that every game should be recruited for and I have magic formulas for new people versus people I’ve gamed with before. It’s sort of like getting the proper mix for a dinner party. The crucial thing is that without identifying who the gamers are its impossible to go any further (which is what makes this process different than system design). Without being clear on who the game circle is you can’t move beyond vague statements or allusions to a mythical group of gamers. Fine for outlining the goals, but not anything to build on. So we have goals and we have players. I chose to represent the next step as two different processes because it’s how I think of them, but honestly they go on at the same time, usually in the same forum.

What do you want the game to do

The purpose here is to identify the appropriate set of subordinate aspects of the game to make the goals happen. A big chunk of this discussion always seems to revolve around the question “What should happen in play to exhibit this goal?” And you do that on each and every goal and sub-goal. By working through this you come up with a very nice analysis that allows you to build key documents later: social contract and mechanics. What do the players expect to get out of the game? Players come with all sorts of expectations. You’ve helped set some of them when you recruited them. So it’s important to identify all of these upfront and understand how they impact the game. One of the crucial things I find useful is to find their entry behaviors, this gives you the building blocks of where everyone is at, what you need to take advantage of, ad also any skills you’ll need to build in order to make the game happen. At this point there are going to be different levels of expectations and knowledge of the individuals in the group, especially if there are new faces involved. The game must be designed with the individuals involved so now is the time to get all that on the table. The question of how is a thorny one and deserving of its own posts. In an ideal world you want to learn the following:

• Entry behaviors
• Prior experience in this type of gaming
• Attitudes towards content
• Attitudes towards potential delivery system, i.e. potential mechanics.
• Ability levels
• General gaming preferences
• Group characteristics

Write the Campaign Design Document

Statements of what the game is designed to do is valuable, not just for designing mechanics around, but for everyone involved so that everyone has clear-cut guidelines of what the game is intended to accomplish. This document is also very useful because its what you’ll gauge your performance against. The basic steps here are:

1. Edit goals to reflect eventual performance
2. Write objectives to reflect intended context of the gaming environment

Objectives are an integral part of the game design cycle and the means by which goals are translated into play. Objectives serve as the input documentation for the design of mechanics, characters and the actual play space.

Develop Social Contract

A lot has been written about social contract. Suffice it to say that I don’t believe you can functionally game without one and that its not a document that can stand on its own. It requires inputs and it gives outputs.

Develop Play Strategy

It is crucial to identify the ways play will engage the players. To identify the tools that will be used in the game to make sure everyone is involved and to meet the objectives and goals already laid out. Play strategy encompasses a wide variety of gaming activities from the micro to the macro. I don’t believe its necessary to outline every microstrategy that is going to be used, but I do believe that if the macrostrategy isn’t laid out and clearly understood than you are opening the game up for a lot of heartache.

Develop and Select Mechanics

Once you figure all this out choosing mechanics is usually a fairly easy choice. You have a list of objectives and you just resolve what system will meet the most need.

Play

Okay play is an entire different process in itself. The key thing I want to bring out here is that the evaluation of play feeds back and adapts all the other steps in a crucial feedback loop. Without it games just don’t function very well over any length of time. Lot of stuff here, and a lot of sub-processes that deserve a lot more detail. But in a nutshell that’s my best practice for developing a game.