Appendix A: Game Design Documentation

While you will learn many technical and practical aspects of game development as you work through the example projects in this book, it is equally important to have a solid foundation in the theoretical aspects of game design. The first effort to create a framework for these concepts was discussed in a paper published by Robin Hunicke, Marc LeBlanc, and Robert Zubek in 2004. ¹ In it, they proposed the Mechanics-Dynamics-Aesthetics (MDA) framework , which provides a useful way to categorize the components of a game.

They defined Mechanics as the formal rules of the game, expressed at the level of data structures and algorithms, Dynamics as the interaction between the player and the game mechanics while the game is in progress, and Aesthetics as the emotional responses experienced by players as they interact with the game. Since then, other frameworks have been proposed, each of which provides a different way of analyzing games. A popular example is Jesse Schell’s Elemental Tetrad , ² which consists of Mechanics, Story, Aesthetics, and Technology (where aesthetics is defined more broadly than in the original MDA framework). Frameworks such as these are valuable tools to help people consistently and fully analyze games. Players can use frameworks to better understand and express what they enjoy about particular games. Developers can use the formal structure to help them create a more cohesive design and to organize and document the development process; explaining how to write such documentation is the goal of this appendix.

A game design document (GDD) serves as the blueprint or master plan for creating a game: it describes the overall vision of a game, as well as the details (often based on a game design framework such as MDA). Practical aspects are also included, such as a schedule that lists when certain features will be completed, a list of team members and responsibilities, and plans for testing and releasing the game. A GDD can provide clarity and focus, while serving as a guide and a reference to the person or people working on the game. To be most effective, the GDD should be as complete as possible before the development process begins. Depending on the flexibility of the developers, a certain amount of modification may be permitted over the course of development, and various adjustments may need to be made after collecting feedback from gameplay testing.

There is no one standard format for game design documents; an Internet search will provide many templates for a variety of development scenarios. GDD templates often contain a bulleted list of topics or questions for your consideration (when applicable). In what follows, we present a similar list of questions for you to ponder as you design your own games; the scope of these questions is particularly good for individual developers or small teams working on projects with game engine software such as Construct 2. By recording detailed responses to the following queries, you will effectively create your own game design document to help guide you through the development process.

1. Overall vision .

   1. Write a short paragraph (three to six sentences) explaining your game. (This is sometimes called the elevator pitch : a short summary used to quickly and simply describe an idea or product during a 30-second elevator ride.)

   2. How would you describe the genre(s)? Is it single-player or multiplayer (and if the latter, cooperative or competitive)?

   3. What is the target audience? Include demographics (the age, interests, and game experience of potential players), the game platform (desktop, console, or smartphone), and any special equipment required (such as gamepads).

   4. Why will people want to play this game? What features distinguish this game from similar titles? What is the hook that will get people interested at first, how will the game keep people interested, and what makes it fun?

2. Mechanics : the rules of the game world. (Note that the following questions are phrased in terms of the game’s main character, as distinguished from the player, since the player is the focus of the section on dynamics. However, if no such character exists, the player can be considered as the character.)

   1. What are the character’s goals? These may be divided into short-term, medium-term, and long-term goals.

   2. What abilities does the character have? This should include any action the character is capable of performing, such as moving, attacking, defending, collecting items, interacting with the environment, and so forth. Describe the abilities or actions in detail; for example, how high can the character jump? Can the character both walk and run?

   3. What obstacles or difficulties will the character face? Some obstacles are active (such as enemies, projectiles, or traps) and should be described in detail (how they affect the player, their location, their movement patterns, and so forth). Other obstacles are passive (such as doors that need to be unlocked, mazes that need to be navigated, puzzles that need to be solved, or time limits that need to be to beat). How can the character overcome these obstacles (items, weapons, spells, quick reflexes)?

   4. What items can the character obtain? What are their effects, where are they obtained, and how frequently do they appear?

   5. What resources must be managed (such as health, money, energy, and experience)? How are these resources obtained and used? Are they limited?

   6. Describe the game world environment. How large is the world (relative to the screen)? Are there multiple rooms or regions? Is the gameplay linear or open? In other words, is there a strictly linear progression of levels or tasks to complete, or can the character select levels, explore the world, and complete quests at will?

3. Dynamics : the interaction between the player and the game mechanics.

   1. What hardware is required by the game (keyboard, mouse, speakers, gamepad, touchscreen)? Which keys/buttons are used, and what are their effects? How is the player informed of the control scheme (a separate manual document, game menus, tutorials, or in-game signs)?

   2. What type of proficiency will the player need to develop to become proficient at the game? Are there any complex actions that can be created from combinations of basic game mechanics? Do the game mechanics or game world environment directly or indirectly encourage the player to develop or discourage any particular play strategies? Does the player’s performance affect the gameplay mechanics (as in feedback loops)?

   3. What gameplay data is displayed during the game (such as points, health, items collected, time remaining)? Where is this information displayed on the screen? How is the information conveyed (text, icons, charts, status bars)?

   4. What menus, screens, or overlays will there be (title screen, help/instructions, credits, game over)? How does the player switch between screens, and which screens can be accessed from each other?

   5. How does the player interact with the game at the software level (pause, quit, restart, control volume)?

4. Aesthetics : the visual, audio, narrative, and psychological aspects of the game; these are the elements that most directly affect the player’s experience.

   1. Describe the style and feel of the game. Does the game take place in a world that is rural, technological, or magical? Does the game world feel cluttered or sparse, ordered or chaotic, geometric or organic? Is the mood lighthearted or serious? Is the pace relaxing or frenetic? All the aesthetic elements discussed should work together and contribute to create a coherent and cohesive theme.

   2. Does the game use pixel art, line art, or realistic graphics? Are the colors bright or dark, varied or monochromatic, shiny or dull? Will there be value-based or image-based animations? Are there any special effects? Create a list of graphics you will need.

   3. What style of background music or ambient sounds will the game use? What sound effects will be used for character actions or for interactions with enemies, objects, and the environment? Will there be sound effects corresponding to interactions with the user interface? List all the music and sounds you will need.

   4. What is the relevant backstory for the game? What is the character’s motivation for pursuing their goal? Will there be a plot or storyline that unfolds as the player progresses through the game?

   5. What emotional state(s) does the game try to provoke: happiness, excitement, calm, surprise, pride, sadness, tension, fear, frustration?

   6. What makes the game “fun”? Some players may enjoy the graphics, music, story, or emotions evoked by the game. Other features players might enjoy include the following:

      1. Fantasy (simulating experiences one doesn’t have in real life)

      2. Role-playing (identifying with a character)

      3. Competition (against other players or against records previously set by oneself)

      4. Cooperation (working with others toward a common goal)

      5. Compassion (providing assistance or rescuing others)

      6. Discovery (finding objects or exploring a world)

      7. Overcoming challenges (such as defeating enemies or solving puzzles)

      8. Collection (including game items or badges/trophies for achievements)

      9. Social aspects (both within the game and the communities that form around the game)

5. Development .

   1. If working with a group: list the team members, and list their roles (game designer, programmer, illustrator, animator, composer, sound editor, writer, manager, etc.), responsibilities, and skills.

   2. What equipment will you need for this project? Include both hardware and software that will be needed for content creation (graphics and audio), game development, and playtesting.

   3. What are the tasks that need to be accomplished to create this game? Estimate the time required for each task, the estimated completion date, and the team member responsible; then estimate the priority of each feature (in case some features need to be eliminated because of time constraints or unexpected circumstances).

   4. What points in the development process are suitable for playtesting? How will you find people to playtest your game? What specific kinds of feedback are you interested in gathering? (For example, you could ask how clear the goals are, how easy or intuitive the controls are, how balanced the difficulty level is, and which parts of the game were most or least enjoyable.) Finally, how will you collect this information (such as a questionnaire or a brief discussion)?

   5. What are your plans for dissemination? Do you have plans to promote this game through social media, forum postings, gameplay videos, or advertisements?