Games, Design and Play: A detailed approach to iterative game design (2016)

Part II: Process

Chapter 7. Game Design Documentation

To keep the iterative design process from feeling like an ever-shifting state of chaos, we use three kinds of documentation: design documents, schematics, and tracking spreadsheets. Design documents record the specific design decisions made about the game, including a game’s design values. Schematics illustrate how the design is manifest onscreen to make the abstract ideas of a game partially tangible before being implemented in a prototype. And the tracking spreadsheet captures big-picture and moment-to-moment tasks necessary to design, prototype, and playtest a game.

If all that happened during the iterative game design process was literally conceptualizing, prototyping, playtesting, and evaluating, the process would more often than not lead to confusion and despair. Team members might end up with different understandings of the game, duplicate work might get done, or even worse, work might not get done at all. To help keep everyone on the same page, we use three interrelated documentation methods: design documents, schematics, and tracking spreadsheets. Each plays a different role in the iterative game design process. The design document functions as the overview for a game’s design and includes guiding elements such as design values (see Chapter 6, “Design Values”). Schematics are like blueprints, showing the basics of how a game looks to help explain what it will be like to play and what needs to be built. And the tracking spreadsheet is like the to-do list that guides the team through the tasks of producing prototypes and running playtests. The rest of this chapter digs into the details of each of these three important documentation methods and introduces how they are used.

The Game Design Document

The game design document is a useful tool to help game designers turn ideas, inspirations, and design values into more structured designs. Design documents capture decisions and turn them into concrete plans for a game’s design that serve as a reference for everyone on the team. Without a game design document, moving through the iterative design process can be confusing and hard to keep track of. The team, or even a gamemaker working alone, will be left to rely on memory and the not fully explored ideas that seemed so excellent in the spur of the moment.

Many people assume a game design document is a 500-page tome exploring every last detail of a game. If an enormous team is making a massive game, that might be the case, but for many indie games, the document likely won’t be much more than 10-20 pages. Finding the right level of detail for capturing the design of a game can take time to master. Particularly when working with a team, more detail is likely better at first, and as the team begins to understand the game and develops a group working style, the level of detail needed will become clear.

Game design documents share properties with film scripts (see Figure 7.1). For many filmmakers, the script is the “playbook” from which a film is produced. It includes descriptions of the scenes, dialog, and situation prompts, along with information on character emotions and motivations. Without the script, the film crew would be left to sort out what to shoot, and the actors would be left to guess at what they were supposed to do in a given scene. Game design documents serve a similar role for guiding a game’s design and the aspects of it that are created through prototypes. Without some form of documentation, teams would likely get details wrong and cause confusion, frustration, and lost time.

Figure 7.1 Sample film script page from Nina Chernik’s film My Moon.

Game design documents are also like software requirement specifications, something briefly alluded to in the introduction to the iterative process. Software requirement specifications (see Figure 7.2) outline how a piece of software will function, including the goal of its use. Unlike film scripts, which document a linear film, software specifications cannot, in most cases, outline exactly how the software will be used, as users will do different things with it. Software requirement documents therefore tend to have both a systems-oriented approach whereby the “moving parts” of the software are identified and their interactions explained and a set of use cases that illustrate how users might put the software into motion. Software specs also tend to be very technical in nature, with details on how the software will be constructed. They can be part of game design documents as well, but they often are handled in separate documents more closely oriented to production.

Figure 7.2 Sample software requirements page.

Think of the design document as a living document. Each time the team moves through the iterative cycle, it is important to return to the design document to keep it up to date and make sure it captures the current understanding of the game. This will likely lead to adding new sections and heavily revising or even throwing out other portions of the document. The most important thing, though, is keeping the design document up to date. This can seem like a time-consuming process, and sometimes it is, but it is still very important, particularly for more complex games or games with bigger teams.

There isn’t a “one size fits all” solution to game design documents, as games have different focuses and needs. Sometimes the game may need something more like a film script (particularly story-driven and dialog-heavy games), while in other cases something closer to the systems-driven approach of software requirement specifications is more helpful. In most cases, particularly early in the process, there are some basic elements the team will want to include in its game design document, such as the following:

Working title: Even if you aren’t sure of the title yet, you are probably calling it by a name. Later on, the team can brainstorm titles and choose one based on what will communicate the idea of the game most effectively. And, of course, if the intention is to release the game, it must be a name that is unique and findable via online search, and if it is a commercial title, it should be available to trademark.

Description of play experience: This is a paragraph that describes the basic elements and premise in language that would make sense to someone unfamiliar with the game. How is the game played, where, what is the game about, and how does the play experience feel? This is different from a use case, though that approach can be helpful earlier on before playtesting with people outside the team has begun.

Goal: This should be a brief description of the game’s goal(s). What are players trying to do through their play? This may be a zero-sum, winner-take-all outcome, it might be a collaborative outcome, or it may be a purely experiential outcome. Whatever it is, capturing it is an important part of steering a game’s design.

Basic elements: This is an overview of the important elements in the game. Think of it as a description of the system objects, or of the “moving parts” in the game. It may make sense to create a systems map to help visualize the relationship between the elements.

How many players are there?

What are the player goals in the game?

What are the main actions in the game—that is, what is the player doing to meet those goals?

What are the objects used?

What is the playspace?

What are the rules governing all of the above?

Annotated list of design values: The annotated list of design values is where all of your design values are captured and shared. (See Chapter 6 for the full explanation of each of these.)

Experience: What does the player get to do?

Theme: What is the game about? How does the game present concepts?

Point of view: What does the player see, hear, or feel? From what cultural reference point? How are the game and the information within it represented?

Challenge: How does the game challenge the player?

Decision-making: How do players make decisions?

Skill, strategy, chance, and uncertainty: How are these elements used and balanced?

Context: Who is playing, where, and when? On what platform?

Emotions: How does the game make the player feel?

Interface and controls: These are diagrams of what players see onscreen (if there is a screen), how information is organized and presented, and how the player interacts with the game. This will likely include schematics covered later in this chapter.

Game flow: This is a flowchart supported by a series of schematics that show how the players move through the play experience.

Level design: Should the game have levels, this information should be captured as well. For each, an overview description along with an annotated level map should be created.

Art direction: The “look, feel, and sound” of the game. At first, this may be a moodboard with annotated photo and sound references. Later, it will include concept art and sample audio. Eventually, it will reflect the final visual and audio approach to the game.

Technical overview: For some more ambitious games, a technical overview is a helpful tool to think through how the game will be produced. This likely won’t start to take shape until a little ways into the design process.

Example: Pong Design Document

Continuing with our speculative Pong example, here’s a fictional early stage game design document for the classic arcade game.

Title: Pong

Gameplay description: Pong is a two-player twitch-style local-multiplayer ballgame with a dose of strategic decision-making played in an arcade cabinet. The play experience transposes tennis and ping pong to a two-dimensional videogame. Players are positioned on opposite sides of a court from which they serve and volley.

Play begins with one side serving the ball to the receiving side. As in tennis, volleyball, racquetball, and so on, a volley continues as long as each side hits the ball back to the other player, without missing it. Players can only move up and down (not left and right). The ball may bounce off the top or the bottom of the screen as part of legal play, but if a player misses the ball, it will exit on the player’s side and the other player will receive a point.

Goal: The goal of the game is for a player to reach a score of 11 before the other player.

Design values:

Experience: Pong is a two-player game based on a mashup between the physical games of tennis and ping pong. It uses a simple scoring system, allowing players to focus on competing for the best score.

Theme: Sportsball! Head-to-head competition!

Point of view: Pong is presented from a top-down perspective, which takes the challenge of modeling gravity and hitting the ball over the net away from gameplay—focusing on the act of hitting the ball back and forth and trying to get it past your opponent’s paddle. The graphics are simple and abstract, also keeping the focus on fast and responsive gameplay.

Challenge: The game’s challenge is one of speed, eye-hand coordination, and hitting the ball in ways that your opponent is not expecting.

Decision-making: Decisions are made in real time, with a clear view of the ball’s trajectory and your opponent’s paddle.

Skill, strategy, chance, and uncertainty: Pong is a game of skill, with some chance related to the angle of the ball when it is served and some uncertainty of how your opponent will hit the ball.

Context: The game is played in an arcade context, with your opponent next to you, enabling interaction on the game screen and in the real world.

Emotions: Pong is meant to generate the feeling of being completely focused, grace, intense competition, and excitement.

Basic elements:

Players: Two, represented by a rectangular paddle that moves vertically.

Paddles: Divided into eight segments that determine the angle at which the ball bounces.

Ball: A ball that reacts by bouncing in the opposite direction when hit, depending on what part of the paddle hits it (if it is hit by a paddle) and the angle at which it is moving. The ball speeds up with every successful hit.

Walls: Along the top and bottom of the screen, the ball may bounce off of them, and they keep the paddle from moving offscreen.

Scoreboard: A score on each side, goes up to 11. A sample scoreboard is 09 | 11.

Scoring: Points are scored as single points. Games are played to 11 and can be won by a single point (such as 11 - 10). Points are scored each time a player fails to return the opponent’s volley.

Interface and controls:

Controls: Each player has an analog joystick that controls the movement of the paddle on the player’s side of the net. The analog joystick allows the player to move vertically along the baseline.

The screen: The court is seen from a top view. Players are positioned on opposing sides of the screen (left and right). There is a scoreboard along the top of the screen and a dotted line dividing each side.

Game flow: The Pong game flow is illustrated in Figure 7.3.

Figure 7.3 Pong game flow chart.

Art direction: Simplicity, white on black.

Technical overview: Transistor-to-transistor logic. (It’s 1972!)

Schematics

Closely related to the game design document are schematics. Where the game design document focuses on detailed descriptions of the game’s design, schematics use images to visualize the design. More often than not, these will work hand-in-hand with the game design document, and in some cases, they will be folded into or even replace it. The goal of schematics is to function as wireframes, storyboard, and blueprints of a game’s design, showing how it will work, even if in abstract, cursory forms.

Game design schematics are like the wireframes associated with user-centered design of websites, apps and software (see Figure 7.4). Wireframes use simple geometric shapes and “greek” text to show what elements should be onscreen at any time. As the design becomes better understood, wireframes also represent how the user might move through the experience of using the website, app, or software. Schematics function like this for games. Early on, they capture what should be onscreen at any given moment. Over time, they begin to reflect the composition of core interface elements in the game. Eventually, they provide a guide for what happens during gameplay.

Figure 7.4 Sample website wireframe.

Let’s take as an example what a wireframe for the classic arcade game Pong might look like (see Figure 7.5). The core elements of the game are represented—the two paddles, the net, the ball, the court, and the players’ scores. This information is important in helping everyone understand the objects and playspace of the game. What the single wireframe doesn’t represent, though, is how all of them interact. But when presented as a sequence, ideas about what happens when the game is in play can be expressed.

Figure 7.5 Fictional Pong wireframe.

This raises an important question about wireframing a game—since the game state is constantly shifting and changing based on player experience, how does a game designer determine what should be represented? There isn’t a one-size-fits-all answer, but a general rule of thumb is that key changes in the basic elements should be reflected. So, in our Pong example, what happens when a point is won, showing how the next point begins, or what happens when the game ends should be represented in wireframes.

Schematics are also like the storyboards used in filmmaking. Filmmakers use storyboards (see Figure 7.6) as an important tool for previsualizing the way the camera will capture a scene. They suggest placement within a space, the angle from which it will film, and should the camera move during the scene, an indication of the direction and speed. For many filmmakers, storyboards are based on the film’s script. The storyboards visualize the setting and action described in the script in a way that creates shared understanding among the film crew. For game design, storyboards serve a similar function—making sure everyone understands how the game will be represented onscreen (for those games that use a screen, that is). This is particularly useful for 3D games and games with more complex uses of the screen space.

Figure 7.6 Sample film storyboard from Nina Chernik’s film My Moon.

A step past storyboards are animatics, a technique borrowed from animation. Animatics are simple sequences of storyboards that are used to indicate motion, pacing, and other important kinetic elements.

Schematics can also be like architectural blueprints (see Figure 7.7). Blueprints serve as the hyper-detailed plans from which a building is constructed. Beyond the details of the dimensions and materials, blueprints include information on how water and electric infrastructure are integrated. Blueprints are used to help architects and engineers communicate how a building needs to be built with the construction crews that do the actual construction. This sort of detailed drawing is also useful for game design, particularly once things get further along in the design process. Schematics can indicate things like the basic interactions of objects, or the pixel-specific dimensions of interface elements and other details important for the team to understand.

Figure 7.7 An architectural blueprint by Stone Librande.

In our fictional Pong schematics (see Figure 7.8), a production blueprint might be used to map out the dimensions of the game; the size of the paddles, ball, and net; and even typographic specifications. Because the ball bounces off the paddle in different angles depending on where on the paddle it lands, a schematic for Pong might also help communicate what angles each section of the paddles correspond to.

Figure 7.8 Fictional production blueprint for Pong.

Integrating Schematics into the Game Design Document

As detailed as they might be, the schematics produced for a game aren’t always going to be able to stand alone to capture the full plan. More often than not, they need to be integrated into the design document to illustrate key points, but also to provide greater detail around what is captured in the schematics. Together, the two work well to capture the thinking around a game’s design.

In other cases, a set of annotated schematics (see Figure 7.9) can replace the game design document. With our Pong example, the game is simple enough that this would probably work just fine. The basic information necessary can be added as notes supplementing the schematics. The team would likely want to still create design values, and the art direction process would still need to unfold, but these can happen outside the game design document structure.

Figure 7.9 Annotated Pong schematics.

The Tracking Spreadsheet

While the iterative game design process provides an overarching methodology for designing games, there is still a lot left to sort out around both big-picture milestones and day-to-day tasks that take the team from concept to prototype to playtest to evaluation and back again. In our own game design practice, tracking spreadsheets are particularly helpful. Often, our team is spread out around New York (where we live), with one of our frequent collaborators living in Seattle. Tracking spreadsheets have the additional value of being accessible to everyone, so long as we keep them in a cloud-based repository.

To track our projects through this modified process, we use a spreadsheet made up of six sheets: overview, for discussion, task list, ongoing responsibilities, asset list, and completed tasks. This document structures our process and has the added benefit of providing an agenda for our meetings, keeping things running smoothly and on track.

Overview

The “overview” sheet captures the overall schedule for the game’s design. This sheet plots out an ideal trajectory that the team can refer to and use as a guide throughout the game design process. We tend to organize the “overview” sheet in terms of prototypes, planning three to five prototypes ahead. As the iterative cycle unfolds, things change, and so too will the overview schedule. For each item in the list, we include a title, a summary, and then a group of things to do within that prototype phase. Noel Llopis suggests that the first step is being able to understand the scale of a given task (see Figure 7.10).¹ He breaks things down into four categories: long-range, mid-range, short-range, and immediate:

Long-range tasks: These are the “guideposts” of the game’s design, like getting to the first core game prototype or a feature-complete state. To come up with this list, take the design elements from the design document and turn them into discrete tasks.

Mid-range tasks: These are the more significant milestones in the game’s design and include things like a prototype milestone or completing the game’s art direction for review. Long-range tasks are often made up of sets of mid-range tasks.

Short-range tasks: These are the more substantial tasks that will advance the game’s design. Things like a new set of style frames for the game’s look or implementing a new mechanic for playtesting fit into this category. These tasks should be measured in days, not take more than a week or two to complete, and should be planned as part of achieving mid-range tasks.

Immediate tasks: These are the quick tasks that can be done in shorter measures of time, like fixing a known bug or capturing a new design idea in the design document. This is the most plentiful type of task in any game design project. These in turn should be in service of reaching short-range tasks.

Figure 7.10 Long-range task list.

Organizing your “overview” sheet around long-range tasks, which break down into a set of mid-range tasks, which are made up of a series of short-range tasks, is really helpful. Assigning timeframes to the long-range and mid-range tasks helps the team have shared goals for getting things done.

For Discussion

This sheet lists all the current things the group needs to review and make decisions about (see Figure 7.11). Sometimes, the items on this list are new ideas or design plans that need to be worked through. Often, “blockers” are on this list: things that need to be addressed for team members to complete tasks. Once an item has been discussed, it moves to one of the other sheets. The “for discussion” sheet has three columns: topic, who wants to discuss it, and notes.

Figure 7.11 For discussion list.

Task List

The “task list” sheet is where all current tasks are tracked (see Figure 7.12). These generally relate to the current phase in the iterative cycle and often form a prototype and playtest plan. We divide our task lists into two sections: short term and immediate. The immediate tasks should be grouped under short-term tasks to help the team understand the bite-size chunks of work to be accomplished. For both, there are four columns: tasks, person, time estimate, and notes. As tasks are completed, they are struck through. And at the end of the phase, we move them to the “completed tasks” sheet.

Figure 7.12 Task list.

Ongoing Responsibilities

This sheet tracks which team member is responsible for what as part of the game (see Figure 7.13). As roles change, so too does this sheet. It has three columns: responsibilities, who, and notes.

Figure 7.13 Ongoing responsibilities list.

Asset List

The asset list sheet (see Figure 7.14) keeps track of all the pieces the team needs to make. This includes models, sprites, sound files, in-game text, and any other pieces necessary for creating more complete prototypes. Given the specificity of this sheet’s content, it doesn’t come into play until later in the process, once a game’s design is stable enough for the team to have a solid idea of the pieces needed to produce prototypes. The asset list is organized by the prototype the asset is needed for (from playable to complete), and the stage the asset should be in for that prototype (for visuals, from wireframe to art to art+animation, and for sound, from placeholder to final). If there’s a schematic for the game, the page number is listed so the artist can see how the art is used.

Figure 7.14 Asset list.

Completed Tasks

The last sheet, “completed tasks” (see Figure 7.15), records all the work done in the various phases. It is important, as it helps you reflect on what you’ve already done and questions you’ve asked as a team. Generally, it helps you avoid revisiting work the team has already done. If you are striking through tasks on the overview sheet or task list, they can finally be moved here to keep everything clean and organized.

Figure 7.15 Completed tasks list.

Summary

While this chapter is called “Game Design Documentation,” it’s really about how to stay on track through the iterative design process. While documenting the process involves, well, making documents, it also is a way to ensure that everyone on the team is on the same page. If you are working alone, it ensures that you make progress and stay true to your design values. Documenting gives you clarity about what you are making (through the design document), how it will take form (with schematics), and what to do next (in the task list).

Design Document: Contains all of the concepts, values, and a description of your game.

Schematics: A map of the actual game screens, wireframes screens, or a storyboard of the game experience that helps you make tangible the elements you will need to consider for your prototyping process. These are often integrated into the design document.

Task List: A list of long-range, mid-range, short-range and immediate tasks, issues for discussion, ongoing responsibilities, assets, and completed tasks for your game design process.

Exercise

1. Create a design document for a project you are working on or an imaginary project you would like to work on.

2. Develop a set of schematics for the same game.

3. Plan a schedule for the game, and produce a task list spreadsheet.