In our previous module we discussed the importance of the adaptive and repetitive process known as "Iterative Design" and how it can be used to bound and frame the refinement of game design ideas. However, most games get to a point where specific designs, plans, and approaches are finalized and the endless repetition could begin to feel like an ever-shifting state of chaos. Ultimately plans and approaches get codified by teams and there needs to be actual plans put in place as to how to build the game. This work is collected into design documentation and is used to keep clients, management, budgets, and creative/technical teams in line.

Onward!

There is not a one-size fits all approach to design documentation. Different teams and different game approaches will demand different levels of detail or breakdowns in order to codify just the right amount of information, plans, and schedules to get the work done. Different individuals, team leads, and clients will require different information as well. However, we have to start somewhere.

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.

Design Document

The design document functions as the overview for a game’s design and includes guiding elements such as design values.

Schematics

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.

Tracking Spreadsheets

Tracking spreadsheets are like the to-do list that guides the team through the tasks of producing prototypes and running playtests.

Macklin, Colleen; Sharp, John. Games, Design and Play (Game Design) (p. 132). Pearson Education. Kindle Edition.

This module we will introduce each of these design documents, but will spend most of this lesson on the Design Document... But first! We must talk a little bit about Design Values

Most simply stated, design values are the qualities and characteristics a game’s designer wants to embody in the game and its play experience. Design values help designers identify what kind of play experience they want to create and articulate some of the parts that will help their game generate that experience. Designing games can be challenging in large part because of the way games work. Game designers have many reasons for creating games. Sometimes they want to share a certain kind of play. Sometimes they have ideas that are best expressed through a game. Regardless of the reasons, being able to fully realize the goals you have for a game can be difficult. This is because of the second-order design problem we discussed earlier this semester; the designer doesn’t have direct control of how players will play; instead, they simply define the parameters within which players play.
Macklin, Colleen; Sharp, John. Games, Design and Play (Game Design) (pp. 117-118). Pearson Education. Kindle Edition.

Design values are the qualities and characteristics you want to embody in a game. This can reflect your own goals as a creator, but also the experience you want your audience to have. While not every game begins with all of these, the following are the general questions to discuss while establishing the design values for a game.

• Experience: What does the player do when playing? And how does this make the player feel physically and emotionally?
• Theme: What is the game about? How does it present this to players? What concepts, perspectives, or experiences might the player encounter during play? How are these delivered? Through story? Systems modeling? Metaphor?
• 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? Simple graphics? Stylized geometric shapes? Highly detailed models?
• Challenge: What kind of challenges does the game present? Mental challenge? Physical challenge? Or is it more a question of a challenging perspective, subject or theme?
• Decision-making: How and where do players make decisions? How are decisions presented?
• Skill, strategy, chance, and uncertainty: What skills does the game ask of the player? Is the development of strategy important to a fulfilling play experience? Does chance factor into the game? From what sources does uncertainty develop?
• Context: Who is the player? Where are they encountering the game? How did they find out about it? When are they playing it? Why are they playing it?
• Emotions: What emotions might the game create in players?

Macklin, Colleen; Sharp, John. Games, Design and Play (Game Design) (pp. 119-120). Pearson Education. Kindle Edition.

Much of these design values should look familiar as we have covered them, in part, throughout our first 5 modules in this class especially in Module 3 (Game Design Tools). The important thing to remember is the values represent the collective "Why" the game will exist and "What" the game will be about in a broader context of societal terms. Not so much how, when, or where.

Now let's get into the main sections of a Design Document

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:
Macklin, Colleen; Sharp, John. Games, Design and Play (Game Design) (p. 134). Pearson Education. Kindle Edition.

• Working Title: This is the title of the game at the point of document creation. Early on you can use codename for the title while you and the team brainstorm different ideas for actual titles. This can change as often as it needs to until it's settled.
• 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 should be short and concise.
• 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 or main elements/objects of the game.
  • How many player's?
  • What are the players goals?
  • How many player's?
  • What are the main objects of the game?
  • What are the objects used?
  • What is the playspace?
  • What are the rules governing the above elements?
• Annotated List of Design Values:
  • Experience: What players can do?
  • Theme: What is the game about?
  • Point of View: What does the player see or hear? Also cultural reference point and info provided
  • Challenge: How does the game challenge players?
  • Experience: What players can do?
  • Decision Making: How do players make decisions?
  • Skill, Strategy, Chance, Uncertainty: How are these elements used and balanced?
  • Context: Who's playing? When and where are they playing? 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.
• 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.

Macklin, Colleen; Sharp, John. Games, Design and Play (Game Design) (p. 136). Pearson Education. Kindle Edition.

Here are some sample design documents that can help you see just how variant the approach, formatting, content, and styles can be. As covered in class, creating a design document is all about communication and choosing what information you put in the document will depend on your purpose, scope, audience, etc.

• Gamescrye.com
  • This is the source site that hosts dozens of samples of design documents
• Far-Cry GDD Presentation
  • This is the slide deck I showed about game design documents.
• Prince of Persia 2
  • Very detailed GDD with a unique style of presentation that follows gameplay.
• Indiana Jones and the Last Crusade
  • A shorter GDD that is more geared toward a pitch than a full plan.
• Shadows of the Empire
  • Comprehensive but very professional GDD from Lucas Arts

This week I want to make things a little easier to give you a bit of a respite given the sprinting we have been doing so far this semester. You might have been expecting that we would be creating a full design document for this assignment. We will be doing that, just not quite yet. For this week I want to focus on design values

1 Your task is to develop a response to the design values for the game of... Chess.

2 Download this Microsoft Word Template. Download Template

3 Fill out the template with content for each area with as much detail as possible.

4 Submission: Once complete please save the Word Document with a file name matching this format. Replace 'Lastname-Firstname' with your actual name.
'Lastname-Firstname'_Assignment7.docx
(Example: Swardson-Brad_Assignment7.docx)

5 Click on Assignment 7 in the UNM Canvas Assignments Listing.

6 Scroll down to Assignment Files and Browse Local file to select the file you created and attach it to your submission for this assignment.

Please make sure you also complete the other requirements in your todo list like discussion post and quiz. Don't forget those.