Excerpt: A Systematic View Of Game Design

By Lewis Pulsipher [09.18.12]

[In this excerpt from Game Design: How to Create Video and Tabletop Games, Start to Finish, game designer Lewis Pulsipher offers a detailed breakdown of the processes involved in traditional game design. Our previous excerpt from Pulsipher's book can be found here.]

Creating a game is a project, and follows the same kind of planning cycle as any project. This is the Plan-Execute-Monitor-Control-Replan cycle, as illustrated in Figure 2:

Figure 2: Project Management and Game Development Cycles

If you don't plan at all, you'll be constantly fixing things, often taking action to fix something that would not have needed fixing if you'd done things right. If you plan but don't check to see if reality (Execution) matches the plan (Monitor), then sooner or later reality won't match the plan. Further, even if you know the plan and reality doesn't match, if you do nothing to fix the situation (Control), then you deviate into failure. Assuming you Control the deviations, you then need to redo the plan. In other words:

- If you don't know what's supposed to happen, how do you know what to do?

- If you don't know what is actually happening, how can you make the right thing happen?

- If you can't make the right thing happen, how can you get where you need to go?

- If your plan doesn't adjust to reality, how do you know where to go, now?

Further, looking at the second part of Figure 2, we see that the major process in creating a good game is similar to the management process. When you've reached the point of a playable prototype, you play the game, analyze the results, modify the prototype, and play again, around and around until you're "finished", or you give up, or you're forced to stop.

Figure 3: Process of Game Design expresses the process a different way, in Data Flow Diagram terms borrowing from Systems Analysis.

A "system" is an assemblage or combination of things or parts forming a complex or unitary whole. Typically, in systems analysis someone figures out how a system works, or ought to work, with the possibility that some of it might be automated. Here we're interested in how it ought to work so that we can use that knowledge in design.

A data flow diagram shows the processes that occur in a system as well as places where data is stored, flows of data/information or objects from one place to another, and external entities that interact with the system:

- circles are the processes, where things happen

- the oddly shaped rounded rectangles are the data stores,

- the arrows are the flows of data/information or objects,

- and the rectangles are the external entities, outside the designer himself

The purpose here is not to show time sequences but to show all the things that might occur. Hence during the operation of the system at any given time several of the processes might be occurring. It's not unusual during the design process to be generating ideas, playing the game in your mind's eye, and even conceiving the game structure and framework all at the same time. Often you could be creating and refining the prototype writing notes, rules, or software, and playtesting all at the same time.

The system we're diagraming is game design. The publisher and playtesters are outside the system, as they are not actually designing the game (we hope).

"Complete" is in quotes because publishers usually require changes to a game, sometimes for good, sometimes for ill, sometimes accidentally, sometimes deliberately. Researching and solving mass production issues is outside the system, insofar as the manufacturer does this.

The diagram is meant to show the process for any game, non-video or video. It is a diagram that assumes a single designer, which is not the case for AAA video games, which are effectively designed by groups of people. A AAA video game creation diagram, which we'll see in Chapter 8, Section A (not included in this excerpt), is dominated by communication and cooperation because so many people are involved. Designers of big video games must cope with both sets of demands represented in two diagrams.

Design collaborators are shown outside the system, as well, but in some cases two collaborators will work so closely that they will collectively be within the process just as a single designer is within the process.

The Processes

Each of the seven processes shown on the main diagram can be divided into another diagram (not considered in this book) with sub-processes, until there is no point in drilling down further. For learners, the top level is sufficient.

Remember that the seven processes (activities) may be going on at the same time, not in a particular order. These are:

Conceive and refine ideas. The game begins in the mind. I've discussed above how important it is to have lots of ideas and how you can generate ideas.

This is also where you'll research whatever situation you are trying to model -- if any. For example, if you're designing a game about farming, you need to know how farming works, which is likely to require some research. If you're designing a game about the Battle of Kursk in World War II, you'll need to research the battle and the capabilities and intentions of the Soviets and Germans. If your game is intended to be a simulation, closely reflecting some reality, then this research will be very important to the accuracy of the simulation. Nonetheless, do just enough research to get you going, and then work on the game; some people get stuck indefinitely in "research."

ArmA II is just one of many simulation games that rely heavily on research.

Play game in "mind's eye" thought experiments. Gradually you'll have some notions about how the game will work. You should play the game or parts of the game in your mind and ask yourself "what is the player going to do and how is this going to be shown in the game." You can play in your mind=s eye any time. You can be riding in a car, you can be waiting in a queue, you can be reading your notes made so far. Experienced designers do this a lot and sort a lot of the game out in their heads before they ever have a prototype to play. Video game designers must rely very heavily on this process because it's relatively difficult and time-consuming to produce a playable prototype of a video game.

Conceive game, structure, framework. At some point you'll have enough information that you'll lay out on paper how the game is actually going to work. Once you do this then you'll want to make a prototype so you can try to play.

Create and refine prototype. Creating the prototype is relatively quick for tabletop games but takes far longer for video games. Some video game designers, if it's practical, will make a paper prototype first to test the concepts that are the essence of the game.

Write notes-rules-software. At some point for video games someone will have to write the software. For tabletop games you can get away with relying on what's in the designer's mind for early playing, but sooner or later rules have to be written. So it's notes at early stages, rules at later stages.

Solo playtest. The designer plays the game himself so that he can work out the worst problems before he inflicts it on anyone else. If a team produces the (video) game, they likely all play the solo version to discover problems.

Playtest with others. Most of the play testing ought to be done by people other than the designer(s) and production team. This will include testing for tabletop games where the designer is present and probably teaches the players how to play, and blind testing where the designer is not present or at least has no part in what happens and the players learn the game as though they had just bought it.

In Figure 3 these two testing processes are adjacent to each other but separate in order to emphasize how important it is for the designer to play the game himself before other people play. (Technically speaking, there probably ought to be one process, Playtesting.)

It's also important for the designer to play the game himself before other people play. (Technically speaking, there probably ought to be one process, Playtesting.) The designer can find a fix for many problems simply by playing himself. Then the outside playtesters, assuming they're not being paid to playtest, will be happier with the playtesting and more likely to continue to play the game. If the game has big faults when they first play, they're much less likely to play again. You need to work out the really big faults before anyone else plays. (Yes, there are likely to be really big faults.)

In tabletop gaming, the process of refining the prototype is often called "development," and someone other than the game designer may be in charge. Two heads are better than one, and the developer acts something like a book editor, suggesting or making changes to improve the game. In video games (and many tabletop designs) the designer(s) are also the developers in this sense.


There is no single proper or right way to diagram this system, given the variety of ways that designers work, and in fact the original diagram was rather different several years ago although it still contains the same seven processes.

This is not a diagram of creativity; it's a diagram of what happens. "Creativity," when it happens, is within the processes. Most of game design is not what we normally think of as creativity.

Quality is not part of the system analysis diagram in and of itself. Ideally, every step in the process will be well done, but there is no assurance of it. If a designer leaves out some of these steps, he's less likely to create a good game. If a designer follows these steps, he may still end up with a lousy game, though it should not be an unplayable game (if it were, the blind testing would never work).

Further reading: Cooperation and engagement: what board games can tell us

Alternative ways to look at the process (MDI/MDA):

Adams and Rollings in Fundamentals of Game Design list the stages of game design as:

- Conception,

- Elaboration,

- Tuning (which is iterative and incremental)

This describes three successive stages of design, and does not contradict the data flow diagram, but is a simpler way to look at it. In their view, the conception is a plan for a game. Once you begin to elaborate a game you should not make major changes in the plan, or should recognize that you've switched to a different game. That's OK if you have time and if you don't already have a contract to deliver a game with certain parameters (you often will with video games).

MDI stands for Mechanics, Dynamics, Impressions. It is a way of thinking about the game as you create and modify it, something to help you think of questions and modifications.

The three parts need to be discussed in reverse order. What we want to engender in the minds and hearts of the players, what we want them to feel and think, is one of the first things for a designer to think about for a game. What do we want the end result to be in terms of the effect on the players? That is, what impression do we want to make on the players? Some designers like to write, early in the conception process, a description in general terms of what they want the players to feel and experience.

Mechanics is the rules or the mechanisms enforced by the programming, the parts of the game that in effect tell players what they can do and what they can=t do.

Dynamics involves how the programming or rules interact with the players to produce events and challenges in the game. What a designer intends, what he sees in his mind's eye as he plays the game in his head, is often not what happens when the prototype is played. Often two qualities, emergence and serendipity, become important.

Emergence, the appearance of new properties, often occurs when two or more mechanics interact to produce something unanticipated, something that is more than the sum of the parts. These new properties may be a surprise even to the designer(s). Rocket-jumping* is apparently something that emerged from the mechanics (rules) of video games, not intended by designers. Many rules/mechanics-dominant games (as opposed to story-dominant) exhibit qualities of emergence.

*Rocket-jumping first emerged in the Quake series, and has since become a popular game mechanic in titles like Team Fortress 2.

Serendipity is an unsought, unintended, and/or unexpected discovery and/or learning experience that happens by accident and sagacity. The word is often used in connection with scientific discoveries that someone Astumbles upon (e.g. penicillin). In this context, some designers may be particularly adept at creating rules, which lead to quite different kinds of gameplay than anticipated.

The designer, then, creates game mechanics to provide challenges for the players, things for the player to do, and has in mind certain thoughts and emotions he wants to engender in the players, but the dynamics of those rules will often lead to quite different situations.

The original version of this idea is MDA (Mechanics, Dynamics, Aesthetics), devised by Marc LeBlanc (also originator of "8 kinds of fun"). The word "Aesthetics" doesn't convey adequately to most people, so I've substituted my own preference.

However you look at it, the important thing is to recognize the iterative and incremental nature of creating a successful game.

Stages of game design -- average time spent on each

"Making an 80% game is very easy. A lot of games that are out there are just 80% finished. With more testing the game could be more elegant and the last 20% takes a lot of time. That's the difficult part." Reiner Knizia

Knizia, who makes more than a million dollars a year as a freelance designer of board, card, and (recently) video games, is referring to the last 20% of changes in the game, which takes a lot more than 20% of the time.

Time taken for each stage:

This is, of course, my estimate, and can vary greatly from one game to another.

[Editor's note: Some images in this article were added to the original text]

Return to the web version of this article
Copyright © UBM TechWeb