Welcome to week seven in the course: Basic Introduction to Game Design. Make sure to read the syllabus and course information before you continue. In this post, we discuss communication and game design documentation. While most textbooks discuss creating game design documents in some way, I feel that, given the scope of a game design class, no truly complete introduction exists for the creation of game design documents. Currently, there is a significant discussion about the worth of design documents for a game design team (such documents are criticised, because nobody ever reads them). The one-page design documents that have become a little bit more popular help to address many of the shortcomings of traditional design documents. However, with games, before making the transition from brainstorming ideas and concepts to writing a design document, you always need to answer these questions first: What is your player going to do? What is the player’s role, and what are the actions available to them?
What is a game design document?
Game design documents have a bad reputation in the games industry. Jesse Schell discusses many myths regarding game design documents (The Art of Game Design, p. 382–383). One these myths is that design documents are a somewhat magical tool for designers to communicate their ideas to the team, on the condition that they are formatted properly and are using the right concept template. However, as he notes, different games require different documents, and it is a rare occurrence that one template will fit all the requirements of your game. The purpose of design documents is twofold:
- Memory aid. Many important design decisions define how a game works in detail. Usually, development of a game takes a significant amount of time, so you are likely to forget some early design decisions if they are not written down. Designers use design documents to record their design decisions as they are made. This way, you do not have to solve the same design problem multiple times.
- Communication tool. Since you are often working with many people on a team to develop games, you will need an effective way of communicating design decisions. The communication with a design document is not one-directional, and establishes a dialogue between you, the designer, and your team. By creating a document that will grow over the development process and that is easy to annotate, you are creating a foundation for improved communication within the team.
The example below shows a character overview that one of our (UOIT) student teams built for their design document, which was submitted as part of a game design competition. The concept visuals clearly communicate ideas regarding the characters, and the stats help the rest of the team to understand the strengths and weaknesses of each character.
— Yanick Roy (@YanickRRoy) June 18, 2013
Schell goes on to mention that different teams in game development have different needs for documentation. This will all depend on your team size and design scope, but in general, he breaks down design docs into the following types:
- Game Design Overview (DESIGN). This is only a few pages, providing a high-level overview of the game, and is often written for management. It is used to communicate the big picture of the game, the main creative vision.
- Detailed Design Doc (DESIGN). In this document, designers describe the game mechanics and interfaces. It helps designers remember details, and communicate these details to artists and engineers. The document can appear stitched together, because it evolves over time and is often abandoned halfway through development as many of the main features are implemented.
- Story Overview (DESIGN). Often external writers work on the game’s narrative, and game designers want to communicate settings, characters, and actions to them. The document can be updated by writers and, in turn, inform the game’s design as well.
- Technical Design Doc (ENGINEERING). Within the engineering team, the technical details of game development have to be communicated (e.g., rendering things on the screen, sending data over the network, saving files). It contains the essential systems architecture underlying the game’s code.
- Pipeline Overview (ENGINEERING). Often the assets (whether art, sound, or other files) in the game need to follow specifications. This document keeps track of these requirements and specifications.
- System Limitations (ENGINEERING). Engineers use this document to communicate the limitations of the game engine and other systems that they are using (e.g., polygon count), which can be helpful for the creative teams to keep their work in scope. If this is done well, it can save a lot of time later in development.
- Art Bible (ART). The game’s art should have a single, consistent look and feel to it, which is often very precisely communicated in guidelines contained within this document.
- Concept Art Overview (ART). Similar to mood boards, the concept art overview helps the rest of the team to understand the vision for the game and helps to keep the creative ideas aligned. Often concept art is also reused in design documentation.
- Game Budget (MANAGEMENT). This is usually a spreadsheet that lists all the work and the attached value to help the management team keep everything within the money limits of the production. For many projects (not just game projects), a budget estimate is always necessary to obtain funding for a project in the first place.
- Project Schedule (MANAGEMENT). Ideally, game development works iteratively, with weekly changes and updates. However, all tasks and important milestones to build the game should be tracked in this document. If scheduling is done well, overtime is minimized, although because of different dependencies within project teams, some overtime is usually very hard to avoid toward the end of a project cycle.
- Story Bible (WRITING). This is only necessary if the game actually features a story. Often limitations from other teams (art, tech) will influence some parts of the narrative, so, again, it is good to keep a common document of the game narrative and annotate it as changes are proposed.
- Script (WRITING). If the game features any dialogue, it is recorded in this document and checked for integrity and correctness.
- Game Tutorial and Manual (WRITING). With the increasing amount of in-game tutorials, manuals have almost become obsolete for games today, but this does not mean that it is not necessary to write down what the basic actions in the game are and how to best teach them to players.
- Walkthroughs (PLAYERS). After the game is released, players often codify their own strategies, and document Easter eggs and other parts of a game that they found particularly exciting.
Rules for good design documentation
Damion Schubert, who was at the time lead designer for Bioware Austin, gave a GDC talk in 2007 about how to create design documentation superior to that used in the concurrent industry. His talk criticised the fact that most documents are not updated often enough, and do not support the iterative process. He goes on to mention a list of rules for good design documentation:
- Know your target. Similar to the target groups and types of design documents that Schell lists, he recommends to target design docs to different groups and ensure that they cater to the needs of the stakeholders.
- Keep it short. Lots of documentation is long-winded and hard to read. Schubert advocates short documents because they are easier to write, read, maintain, and to handle politically (given a team’s internal politics). In his examples, he describes statements that reference another document (for example, a document dealing with common UI dialogues) for reusable elements in the game. He also recommends that designers minimize narrative fluff when describing gameplay actions; for example, here is an item that you can craft it, but you have to pay gold before you can craft, some tools allow you to craft faster.
- Prioritize the design. He recommends that you highlight the game’s features in the document and break them up into development phases, so that the document clearly distinguishes between early phase and later phase (in development) features. The phases could be: (1) prototype feature, (2) core game feature, (3) must have in shipped product, (4) nice to have (or “wish list”), or (5) not going to happen.
- Illustrate. Whenever possible, a picture is likely going to give the development team a better idea than the most detailed description. Screens of other games with similar features are possible, so are diagrams (e.g., a game loop), comics, and iconic or abstract pictures.
- Don’t tell others how to do their jobs. For example, the game design document should not feature the technical implementation details that the coding team is likely going to come up with, but more the number of variables and possible numbers that you are planning to have in your game (e.g., 20 open quests at any given time).
- Use user stories. You want to describe the gameplay experience from the view of your players and ideally have a list of bullet points with player actions that you can walk through. For example: main action is gaining a level when crossing an experience point threshold, the story goes: (1) player hears chime sound, (2) player sees particle effect, (3) player gains 5 points on attributes, (4) player gains 3 points on skills, (5) if reaching level 10 threshold, player may chose a class. Each of these items can be implemented and scoped out easily.
- Separate code from content. Specific design values and variables should be available in an appendix or set of tables, whereas the general information can be found in the text. People do not like to hunt for information, so it has to be presented succinctly and clearly in the document (and possibly cross-referenced).
- Invest in a good format. Find a template that works for your development team and game. Don’t be a slave to this format, but let it serve as inspiration for you and help you guide the design.
- Use clear terminology. Using plain language and avoiding jargon can be really hard, but helps to keep the document informative even for new team members. You want to ensure that you use terms consistently, and possibly create a glossary for words that seem unclear.
- Kill redundancy. Try not to copy and paste sections around in the document; whenever possible, reference another section in the document. Each section or document should have a clear purpose, and be referenced accordingly by the main section/document.
- Avoid weak language. A strong declarative language helps your document to avoid any misinterpretations of your ideas. Words like “maybe”, “could”, or “might” should be avoided.
- Capture your reasoning. Whenever you make a core gameplay decision, you want your team to understand and remember the reasoning behind it. For example, when players cannot place items on the ground, add an item to your FAQ that answers why they cannot do this: To reduce visual clutter and prevent disruptive player behaviour by dropping hundreds of items.
Ubisoft strongly advocates a concept called gameplay pillars, referring to the core features of the game that provide challenge for the players. These are the defining elements of your game, the core actions that your players engage with. For example, if you are developing a first-person shooter game, the shooting mechanic will be your core gameplay; if you develop a platform game, then jumping needs to work flawlessly. It is very important for the design document to communicate the gameplay pillars correctly.
Patrick Plourde, Assassin’s Creed 2 (AC2) game designer, gave a talk at GDC 2010, where he described the core gameplay pillars of AC2: (1) Fight, (2) Navigation, and (3) Social Stealth. Ubisoft then designed the game around these three gameplay pillars. For example, for fighting, they added tactical player choices like new moves, disarming new enemies, and new tools (e.g., weapons). They also focused on the challenge of navigation coming from the environment and not from player controls. The fluidity map above shows how complex the environment is to navigate. The fluid movement is not in the way of navigational decision-making, which is the core challenge that the game was going for. So, you can move around while planning your next move, jump, or escape route. Social stealth was the third gameplay pillar, and it is evidenced by the ability of the Assassin to use the crowd as a gameplay tool. The player can take advantage of the environment by using crowds and benches to disappear. The social behaviour of the Assassin will trigger reactions from the game’s world.
The design documentation format in this class
The format that we will be using in this class and for students participating in GDW is based on the design documents that previous teams have created in student game design competitions (particularly the Ubisoft Academia competition). The format is a ten page document that follows the following specifications for each page:
- Presentation. Your front page features your title and logo, team member names, contact information, game type, target audience, one-liner concept, and representative images. For example, the winning game from the Ubisoft competition (Book Brawl) used this one liner: “Book Brawl is a competitive multiplayer game in which three teams clash using the mighty power of shifting through dimensions, to lure, trick, fight and chase one another to acquire the ultimate tome of knowledge.”
- Gameplay Concept. You describe your gameplay mechanics here. It is also a good place to discuss the required player skills. You usually start with a brief synopsis of the core gameplay pillars (e.g., chase and evade), then go on to describe the game mode. You should also list the games that have inspired certain gameplay mechanics or pillars in your game (e.g., environmental puzzles from Portal 2 or coöperative team play from Left 4 Dead 2). This makes it much easier to grasp your gameplay angle.
- Narrative Context. You do not need a narrative context for every game (this is especially true at game jams), but for this class and this year’s GDW, you will need some form of narrative frame within which your game works. This is the place to describe it, the settings, theme, and visual style. If your game has strong characters, you can use this spot to describe any background story or theme that concerns them.
- Camera, Controls, Character. This section lets you flesh out your interaction details. Most likely in your first year game, you are not going to have a camera (because the game is not in 3D yet), but you can spend some space here on describing controller and keyboard mappings (what keys have what function in the game, what are your core actions, and how are they triggered by the player). You should also describe any special moves that your characters have. If you do not have much to say in this section, then use the space to display an infographic.
- Game Progression. You should talk about your game’s learning and difficulty curve here. How does a player progress from novice, to advanced, to master of your game? It is also a great place to talk about power-ups and hazards in the game world. If you can, you should try to create a simple overview version of your game loop here. What are the main gameplay actions that are repeated during a session? Are there any special rounds during your gameplay session?
- Enemies and Obstacles. If you have any non-player characters (NPCs) in your game, this is a good spot for talking about their main actions. Any stats or abilities that relate to the player or players in your game should be discussed here as well. How did you balance different player abilities (e.g., if there are different characters that a player can choose in your game)? Are there main resources in your game?
- Game World. Talk about the general layout of your game world and its underlying structure here. Are there any paths that are preferred? Did you design the world to facilitate a gameplay pillar (see the above fluidity map from AC2 that was designed to facilitate a certain flow of movement in the level)? What is the visual style in your different levels? Did you use different colour schemes (yes, you can even colour text differently in text adventure games)? What are your inspirations here?
- HUD, Signs, and Feedback. Talk about the user interface of your game. This is not just layout, but also your intent of how to convey information to players. What is the main information that needs to be visible to the player? Are you using scores? Where are they displayed? Is there a timer? Are there energy levels involved? Are you using sound to convey feedback? What type of sound? Is there any music? Any other forms of feedback in your game? How are you guiding the player through the world and gameplay actions?
- Marketing Strategy and Unique Selling Points. What would make people buy your game? What is your target demographic? What is your direct competition in terms of your core gameplay mechanics? Usually you will talk about your inspirations from other games here, because this is likely going to be your competition. What is your branding strategy? What is the most memorable moment in your game? Do you have one? Did you test your game with some players outside your development team? What did they like about it?
- Work Plan. How would you go toward building the full version of this game? List a detailed month-by-month plan for the next term that shows you have an idea of how you will finish your first-year game. Which parts of your game are modular and can easily be extended? How does this relate to your team’s skill? What is your biggest development challenge in the next months ahead?
Create a 10-page game design document that is visually appealing and will sell your game based on the format discussed above. Hand in the document in the tutorial and prepare a concept presentation of your game highlighting those ten points.
Am I missing something? Write a comment to this post at the very bottom of the page.
- Game Design Treatment Document (PDF) for the Ubisoft Academia game Morphlers.
- Adam Grenier’s Portfolio Site, which includes a gameplay flowchart and a level design document he created for a student game.
- The Game Design Document for Morphlers, another game (from Concordia) in Ubisoft’s Academia competition, on Alicia Fortier’s website.