Clan Combat Draft
Basic Introduction to Game Design

Communication and Game Design Documents

[cite]
Welcome to week sev­en in the course: Basic Introduction to Game Design. Make sure to read the syl­labus and course infor­ma­tion before you con­tin­ue. In this post, we dis­cuss com­mu­ni­ca­tion and game design doc­u­men­ta­tion. While most text­books dis­cuss cre­at­ing game design doc­u­ments in some way, I feel that, giv­en the scope of a game design class, no tru­ly com­plete intro­duc­tion exists for the cre­ation of game design doc­u­ments. Currently, there is a sig­nif­i­cant dis­cus­sion about the worth of design doc­u­ments for a game design team (such doc­u­ments are crit­i­cised, because nobody ever reads them). The one-page design doc­u­ments that have become a lit­tle bit more pop­u­lar help to address many of the short­com­ings of tra­di­tion­al design doc­u­ments. However, with games, before mak­ing the tran­si­tion from brain­storm­ing ideas and con­cepts to writ­ing a design doc­u­ment, you always need to answer these ques­tions first: What is your play­er going to do? What is the player’s role, and what are the actions avail­able to them?

What is a game design document?

Game design doc­u­ments have a bad rep­u­ta­tion in the games indus­try. Jesse Schell dis­cuss­es many myths regard­ing game design doc­u­ments (The Art of Game Design, p. 382–383). One these myths is that design doc­u­ments are a some­what mag­i­cal tool for design­ers to com­mu­ni­cate their ideas to the team, on the con­di­tion that they are for­mat­ted prop­er­ly and are using the right con­cept tem­plate. However, as he notes, dif­fer­ent games require dif­fer­ent doc­u­ments, and it is a rare occur­rence that one tem­plate will fit all the require­ments of your game. The pur­pose of design doc­u­ments is twofold:

  1. Memory aid. Many impor­tant design deci­sions define how a game works in detail. Usually, devel­op­ment of a game takes a sig­nif­i­cant amount of time, so you are like­ly to for­get some ear­ly design deci­sions if they are not writ­ten down. Designers use design doc­u­ments to record their design deci­sions as they are made. This way, you do not have to solve the same design prob­lem mul­ti­ple times.
  2. Communication tool. Since you are often work­ing with many peo­ple on a team to devel­op games, you will need an effec­tive way of com­mu­ni­cat­ing design deci­sions. The com­mu­ni­ca­tion with a design doc­u­ment is not one-direc­tion­al, and estab­lish­es a dia­logue between you, the design­er, and your team. By cre­at­ing a doc­u­ment that will grow over the devel­op­ment process and that is easy to anno­tate, you are cre­at­ing a foun­da­tion for improved com­mu­ni­ca­tion with­in the team.

The exam­ple below shows a char­ac­ter overview that one of our (UOIT) stu­dent teams built for their design doc­u­ment, which was sub­mit­ted as part of a game design com­pe­ti­tion. The con­cept visu­als clear­ly com­mu­ni­cate ideas regard­ing the char­ac­ters, and the stats help the rest of the team to under­stand the strengths and weak­ness­es of each char­ac­ter.

Clan Combat Characters

Main char­ac­ters and their attrib­ut­es in the UOIT game Clan Combat (final­ist in the Ubisoft Academia com­pe­ti­tion).

 

Documentation Types

Schell goes on to men­tion that dif­fer­ent teams in game devel­op­ment have dif­fer­ent needs for doc­u­men­ta­tion. This will all depend on your team size and design scope, but in gen­er­al, he breaks down design docs into the fol­low­ing types:

  1. Game Design Overview (DESIGN). This is only a few pages, pro­vid­ing a high-lev­el overview of the game, and is often writ­ten for man­age­ment. It is used to com­mu­ni­cate the big pic­ture of the game, the main cre­ative vision.
  2. Detailed Design Doc (DESIGN). In this doc­u­ment, design­ers describe the game mechan­ics and inter­faces. It helps design­ers remem­ber details, and com­mu­ni­cate these details to artists and engi­neers. The doc­u­ment can appear stitched togeth­er, because it evolves over time and is often aban­doned halfway through devel­op­ment as many of the main fea­tures are imple­ment­ed.
  3. Story Overview (DESIGN). Often exter­nal writ­ers work on the game’s nar­ra­tive, and game design­ers want to com­mu­ni­cate set­tings, char­ac­ters, and actions to them. The doc­u­ment can be updat­ed by writ­ers and, in turn, inform the game’s design as well.
  4. Technical Design Doc (ENGINEERING). Within the engi­neer­ing team, the tech­ni­cal details of game devel­op­ment have to be com­mu­ni­cat­ed (e.g., ren­der­ing things on the screen, send­ing data over the net­work, sav­ing files). It con­tains the essen­tial sys­tems archi­tec­ture under­ly­ing the game’s code.
  5. Pipeline Overview (ENGINEERING). Often the assets (whether art, sound, or oth­er files) in the game need to fol­low spec­i­fi­ca­tions. This doc­u­ment keeps track of these require­ments and spec­i­fi­ca­tions.
  6. System Limitations (ENGINEERING). Engineers use this doc­u­ment to com­mu­ni­cate the lim­i­ta­tions of the game engine and oth­er sys­tems that they are using (e.g., poly­gon count), which can be help­ful for the cre­ative teams to keep their work in scope. If this is done well, it can save a lot of time lat­er in devel­op­ment.
  7. Art Bible (ART). The game’s art should have a sin­gle, con­sis­tent look and feel to it, which is often very pre­cise­ly com­mu­ni­cat­ed in guide­lines con­tained with­in this doc­u­ment.
  8. Concept Art Overview (ART). Similar to mood boards, the con­cept art overview helps the rest of the team to under­stand the vision for the game and helps to keep the cre­ative ideas aligned. Often con­cept art is also reused in design doc­u­men­ta­tion.
  9. Game Budget (MANAGEMENT). This is usu­al­ly a spread­sheet that lists all the work and the attached val­ue to help the man­age­ment team keep every­thing with­in the mon­ey lim­its of the pro­duc­tion. For many projects (not just game projects), a bud­get esti­mate is always nec­es­sary to obtain fund­ing for a project in the first place.
  10. Project Schedule (MANAGEMENT). Ideally, game devel­op­ment works iter­a­tive­ly, with week­ly changes and updates. However, all tasks and impor­tant mile­stones to build the game should be tracked in this doc­u­ment. If sched­ul­ing is done well, over­time is min­i­mized, although because of dif­fer­ent depen­den­cies with­in project teams, some over­time is usu­al­ly very hard to avoid toward the end of a project cycle.
  11. Story Bible (WRITING). This is only nec­es­sary if the game actu­al­ly fea­tures a sto­ry. Often lim­i­ta­tions from oth­er teams (art, tech) will influ­ence some parts of the nar­ra­tive, so, again, it is good to keep a com­mon doc­u­ment of the game nar­ra­tive and anno­tate it as changes are pro­posed.
  12. Script (WRITING). If the game fea­tures any dia­logue, it is record­ed in this doc­u­ment and checked for integri­ty and cor­rect­ness.
  13. Game Tutorial and Manual (WRITING). With the increas­ing amount of in-game tuto­ri­als, man­u­als have almost become obso­lete for games today, but this does not mean that it is not nec­es­sary to write down what the basic actions in the game are and how to best teach them to play­ers.
  14. Walkthroughs (PLAYERS). After the game is released, play­ers often cod­i­fy their own strate­gies, and doc­u­ment Easter eggs and oth­er parts of a game that they found par­tic­u­lar­ly excit­ing.

Rules for good design documentation

Damion Schubert, who was at the time lead design­er for Bioware Austin, gave a GDC talk in 2007 about how to cre­ate design doc­u­men­ta­tion supe­ri­or to that used in the con­cur­rent indus­try. His talk crit­i­cised the fact that most doc­u­ments are not updat­ed often enough, and do not sup­port the iter­a­tive process. He goes on to men­tion a list of rules for good design doc­u­men­ta­tion:

  1. Know your tar­get. Similar to the tar­get groups and types of design doc­u­ments that Schell lists, he rec­om­mends to tar­get design docs to dif­fer­ent groups and ensure that they cater to the needs of the stake­hold­ers.
  2. Keep it short. Lots of doc­u­men­ta­tion is long-wind­ed and hard to read. Schubert advo­cates short doc­u­ments because they are eas­i­er to write, read, main­tain, and to han­dle polit­i­cal­ly (giv­en a team’s inter­nal pol­i­tics). In his exam­ples, he describes state­ments that ref­er­ence anoth­er doc­u­ment (for exam­ple, a doc­u­ment deal­ing with com­mon UI dia­logues) for reusable ele­ments in the game. He also rec­om­mends that design­ers min­i­mize nar­ra­tive fluff when describ­ing game­play actions; for exam­ple, 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.
  3. Prioritize the design. He rec­om­mends that you high­light the game’s fea­tures in the doc­u­ment and break them up into devel­op­ment phas­es, so that the doc­u­ment clear­ly dis­tin­guish­es between ear­ly phase and lat­er phase (in devel­op­ment) fea­tures. The phas­es could be: (1) pro­to­type fea­ture, (2) core game fea­ture, (3) must have in shipped prod­uct, (4) nice to have (or “wish list”), or (5) not going to hap­pen.
  4. Illustrate. Whenever pos­si­ble, a pic­ture is like­ly going to give the devel­op­ment team a bet­ter idea than the most detailed descrip­tion. Screens of oth­er games with sim­i­lar fea­tures are pos­si­ble, so are dia­grams (e.g., a game loop), comics, and icon­ic or abstract pic­tures.
  5. Don’t tell oth­ers how to do their jobs. For exam­ple, the game design doc­u­ment should not fea­ture the tech­ni­cal imple­men­ta­tion details that the cod­ing team is like­ly going to come up with, but more the num­ber of vari­ables and pos­si­ble num­bers that you are plan­ning to have in your game (e.g., 20 open quests at any giv­en time).
  6. Use user sto­ries. You want to describe the game­play expe­ri­ence from the view of your play­ers and ide­al­ly have a list of bul­let points with play­er actions that you can walk through. For exam­ple: main action is gain­ing a lev­el when cross­ing an expe­ri­ence point thresh­old, the sto­ry goes: (1) play­er hears chime sound, (2) play­er sees par­ti­cle effect, (3) play­er gains 5 points on attrib­ut­es, (4) play­er gains 3 points on skills, (5) if reach­ing lev­el 10 thresh­old, play­er may chose a class. Each of these items can be imple­ment­ed and scoped out eas­i­ly.
  7. Separate code from con­tent. Specific design val­ues and vari­ables should be avail­able in an appen­dix or set of tables, where­as the gen­er­al infor­ma­tion can be found in the text. People do not like to hunt for infor­ma­tion, so it has to be pre­sent­ed suc­cinct­ly and clear­ly in the doc­u­ment (and pos­si­bly cross-ref­er­enced).
  8. Invest in a good for­mat. Find a tem­plate that works for your devel­op­ment team and game. Don’t be a slave to this for­mat, but let it serve as inspi­ra­tion for you and help you guide the design.
  9. Use clear ter­mi­nol­o­gy. Using plain lan­guage and avoid­ing jar­gon can be real­ly hard, but helps to keep the doc­u­ment infor­ma­tive even for new team mem­bers. You want to ensure that you use terms con­sis­tent­ly, and pos­si­bly cre­ate a glos­sary for words that seem unclear.
  10. Kill redun­dan­cy. Try not to copy and paste sec­tions around in the doc­u­ment; when­ev­er pos­si­ble, ref­er­ence anoth­er sec­tion in the doc­u­ment. Each sec­tion or doc­u­ment should have a clear pur­pose, and be ref­er­enced accord­ing­ly by the main section/document.
  11. Avoid weak lan­guage. A strong declar­a­tive lan­guage helps your doc­u­ment to avoid any mis­in­ter­pre­ta­tions of your ideas. Words like “maybe”, “could”, or “might” should be avoid­ed.
  12. Capture your rea­son­ing. Whenever you make a core game­play deci­sion, you want your team to under­stand and remem­ber the rea­son­ing behind it. For exam­ple, when play­ers can­not place items on the ground, add an item to your FAQ that answers why they can­not do this: To reduce visu­al clut­ter and pre­vent dis­rup­tive play­er behav­iour by drop­ping hun­dreds of items.

Gameplay pillars

Ubisoft strong­ly advo­cates a con­cept called game­play pil­lars, refer­ring to the core fea­tures of the game that pro­vide chal­lenge for the play­ers. These are the defin­ing ele­ments of your game, the core actions that your play­ers engage with. For exam­ple, if you are devel­op­ing a first-per­son shoot­er game, the shoot­ing mechan­ic will be your core game­play; if you devel­op a plat­form game, then jump­ing needs to work flaw­less­ly. It is very impor­tant for the design doc­u­ment to com­mu­ni­cate the game­play pil­lars cor­rect­ly.

Fluidity Map of Venice in AC2

Fluidity map of a dis­trict of Venice in Assassin’s Creed 2 (Ubisoft 2010)

Patrick Plourde, Assassin’s Creed 2 (AC2) game design­er, gave a talk at GDC 2010, where he described the core game­play pil­lars of AC2: (1) Fight, (2) Navigation, and (3) Social Stealth. Ubisoft then designed the game around these three game­play pil­lars. For exam­ple, for fight­ing, they added tac­ti­cal play­er choic­es like new moves, dis­arm­ing new ene­mies, and new tools (e.g., weapons). They also focused on the chal­lenge of nav­i­ga­tion com­ing from the envi­ron­ment and not from play­er con­trols. The flu­id­i­ty map above shows how com­plex the envi­ron­ment is to nav­i­gate. The flu­id move­ment is not in the way of nav­i­ga­tion­al deci­sion-mak­ing, which is the core chal­lenge that the game was going for. So, you can move around while plan­ning your next move, jump, or escape route. Social stealth was the third game­play pil­lar, and it is evi­denced by the abil­i­ty of the Assassin to use the crowd as a game­play tool. The play­er can take advan­tage of the envi­ron­ment by using crowds and bench­es to dis­ap­pear. The social behav­iour of the Assassin will trig­ger reac­tions from the game’s world.

The design documentation format in this class

The for­mat that we will be using in this class and for stu­dents par­tic­i­pat­ing in GDW is based on the design doc­u­ments that pre­vi­ous teams have cre­at­ed in stu­dent game design com­pe­ti­tions (par­tic­u­lar­ly the Ubisoft Academia com­pe­ti­tion). The for­mat is a ten page doc­u­ment that fol­lows the fol­low­ing spec­i­fi­ca­tions for each page:

  1. Presentation. Your front page fea­tures your title and logo, team mem­ber names, con­tact infor­ma­tion, game type, tar­get audi­ence, one-lin­er con­cept, and rep­re­sen­ta­tive images. For exam­ple, the win­ning game from the Ubisoft com­pe­ti­tion (Book Brawl) used this one lin­er: “Book Brawl is a com­pet­i­tive mul­ti­play­er game in which three teams clash using the mighty pow­er of shift­ing through dimen­sions, to lure, trick, fight and chase one anoth­er to acquire the ulti­mate tome of knowl­edge.”
  2. Gameplay Concept. You describe your game­play mechan­ics here. It is also a good place to dis­cuss the required play­er skills. You usu­al­ly start with a brief syn­op­sis of the core game­play pil­lars (e.g., chase and evade), then go on to describe the game mode. You should also list the games that have inspired cer­tain game­play mechan­ics or pil­lars in your game (e.g., envi­ron­men­tal puz­zles from Portal 2 or coöper­a­tive team play from Left 4 Dead 2). This makes it much eas­i­er to grasp your game­play angle.
  3. Narrative Context. You do not need a nar­ra­tive con­text for every game (this is espe­cial­ly true at game jams), but for this class and this year’s GDW, you will need some form of nar­ra­tive frame with­in which your game works. This is the place to describe it, the set­tings, theme, and visu­al style. If your game has strong char­ac­ters, you can use this spot to describe any back­ground sto­ry or theme that con­cerns them.
  4. Camera, Controls, Character. This sec­tion lets you flesh out your inter­ac­tion details. Most like­ly in your first year game, you are not going to have a cam­era (because the game is not in 3D yet), but you can spend some space here on describ­ing con­troller and key­board map­pings (what keys have what func­tion in the game, what are your core actions, and how are they trig­gered by the play­er). You should also describe any spe­cial moves that your char­ac­ters have. If you do not have much to say in this sec­tion, then use the space to dis­play an info­graph­ic.
  5. Game Progression. You should talk about your game’s learn­ing and dif­fi­cul­ty curve here. How does a play­er progress from novice, to advanced, to mas­ter of your game? It is also a great place to talk about pow­er-ups and haz­ards in the game world. If you can, you should try to cre­ate a sim­ple overview ver­sion of your game loop here. What are the main game­play actions that are repeat­ed dur­ing a ses­sion? Are there any spe­cial rounds dur­ing your game­play ses­sion?
  6. Enemies and Obstacles. If you have any non-play­er char­ac­ters (NPCs) in your game, this is a good spot for talk­ing about their main actions. Any stats or abil­i­ties that relate to the play­er or play­ers in your game should be dis­cussed here as well. How did you bal­ance dif­fer­ent play­er abil­i­ties (e.g., if there are dif­fer­ent char­ac­ters that a play­er can choose in your game)? Are there main resources in your game?
  7. Game World. Talk about the gen­er­al lay­out of your game world and its under­ly­ing struc­ture here. Are there any paths that are pre­ferred? Did you design the world to facil­i­tate a game­play pil­lar (see the above flu­id­i­ty map from AC2 that was designed to facil­i­tate a cer­tain flow of move­ment in the lev­el)? What is the visu­al style in your dif­fer­ent lev­els? Did you use dif­fer­ent colour schemes (yes, you can even colour text dif­fer­ent­ly in text adven­ture games)? What are your inspi­ra­tions here?
  8. HUD, Signs, and Feedback. Talk about the user inter­face of your game. This is not just lay­out, but also your intent of how to con­vey infor­ma­tion to play­ers. What is the main infor­ma­tion that needs to be vis­i­ble to the play­er? Are you using scores? Where are they dis­played? Is there a timer? Are there ener­gy lev­els involved? Are you using sound to con­vey feed­back? What type of sound? Is there any music? Any oth­er forms of feed­back in your game? How are you guid­ing the play­er through the world and game­play actions?
  9. Marketing Strategy and Unique Selling Points. What would make peo­ple buy your game? What is your tar­get demo­graph­ic? What is your direct com­pe­ti­tion in terms of your core game­play mechan­ics? Usually you will talk about your inspi­ra­tions from oth­er games here, because this is like­ly going to be your com­pe­ti­tion. What is your brand­ing strat­e­gy? What is the most mem­o­rable moment in your game? Do you have one? Did you test your game with some play­ers out­side your devel­op­ment team? What did they like about it?
  10. Work Plan. How would you go toward build­ing the full ver­sion of this game? List a detailed month-by-month plan for the next term that shows you have an idea of how you will fin­ish your first-year game. Which parts of your game are mod­u­lar and can eas­i­ly be extend­ed? How does this relate to your team’s skill? What is your biggest devel­op­ment chal­lenge in the next months ahead?

Final Homework

Create a 10-page game design doc­u­ment that is visu­al­ly appeal­ing and will sell your game based on the for­mat dis­cussed above. Hand in the doc­u­ment in the tuto­r­i­al and pre­pare a con­cept pre­sen­ta­tion of your game high­light­ing those ten points.

Further Reading

Am I miss­ing some­thing? Write a com­ment to this post at the very bot­tom of the page.

  1. Game Design Treatment Document (PDF) for the Ubisoft Academia game Morphlers.
  2. Adam Grenier’s Portfolio Site, which includes a game­play flow­chart and a lev­el design doc­u­ment he cre­at­ed for a stu­dent game.
  3. The Game Design Document for Morphlers, anoth­er game (from Concordia) in Ubisoft’s Academia com­pe­ti­tion, on Alicia Fortier’s web­site.

Further Viewing

Standard

One thought on “Communication and Game Design Documents

  1. Pingback: File and Time Management in Game Design – Ana's Animation Blog

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.