One pagedesigns


Published on

This is a version of the presentation by Stone Librande at GDC 2010, converted for people who don't have powerpoint. Please visit Stone's site at

Published in: Design, Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • [The notes you are reading are the high-level key points of the talk. If you are interested in seeing the full talk please visit the GDC 2010 Vault ( ). Note that you will need to be a member to view the video there.] Intro I’ve been working as a programmer and a designer in the industry for over 10 years. I want to share with you a technique of design presentation that I’ve been experimenting with for several years. But first…
  • Overview First, we’ll take a brief look at other types of design documentation. Then I’ll explain what I mean by a one-page design and show you examples of one-page designs that I have worked on. I’ll share some tips and techniques about making your own one-page designs. We’ll wrap it up with a summary of the pros and cons of one-page designs.
  • Design Bibles In the mid-90’s most design documents were printed and physically distributed to the team members. As the name implies, these “bibles” contained the total design: levels, art and sound requirements, puzzles, scripts, UI needs and more.
  • Templates The idea was that you could start with a standardized outline and fill in the blanks. The design is finished when the document is complete. There were many talks at GDC about the best outlines and formats to use.
  • Creature Ball Here is one of my first video game proposals from the mid-90’s. Notice the dense text blocks. Illustrations and tables also help. Needless to say, it didn’t take me long to realize that this type of document was not inspiring people. But, as a designer, it is a great way to make sure you understand every detail of your game.
  • Leisure Suit Larry Design Doc Here is a professional design doc I found on the web. The entire document was about 30 pages of black and white text.
  • Grim Fandago Design Doc Here are a few of the 72 pages from the Grim Fandango design doc. (I put it up on my website at
  • Pros Forces thoroughness The designer must think about every aspect of the game. The act of writing each sentence forces the designer to think through all the implications of that sentence. Cons As the team gets bigger less people will be motivated to read it. Some of the team will skim the document, but most people would rather just ask me to tell them what it says when they need to know. Hard to manage updates. Game design is about iteration. Since revisions happen so frequently it can hard to make sure all the changes are written down. Even if you do write it down it is hard, if not impossible, for another team member to find out what’s changed. Some of these documents can be over 100 pages long.
  • Design Wiki The solution to many of these problems is to put the design documentation up the company intranet.
  • Spore DS Wiki This is the design section of the Spore Hero wiki site. It is basically a design bible, but constructed on the web instead of in Word. Each high level topic links to a page of design details.
  • Spore Wiki The Spore wiki home page. This one looks nice on the home page, but since each team managed their own section (cell, creature, tribe, etc.) it was a bit chaotic once you left this page.
  • The Simpsons Wiki The Simpsons game used the wiki for all the design documents. I was on a team of 4 designers and each of us had our own section. We had a full-time design producer who was in charge of keeping the wiki up to date. We had frequent meetings and each page went through a process of concept, design approval and engineering approval. If you are going to use a wiki then you need a dedicated owner of the site. Otherwise it will quickly become unorganized and out of date.
  • Marge’s Meals Within each section of The Simpsons wiki every designer could do what they wanted, but it needed to follow a certain style.
  • Pros Can access from anywhere As long as you are near a networked computer you can view the documentation. Easy to update Double-click to go to edit mode and make the changes while you are discussing them with someone else. Bite-sized chunks No one needs to read the whole document (although you hope the lead designer will). Click on the link (or search) to get to section you want. Everyone on the team can contribute and edit. All the changes are stamped with both the person’s name and the time of the change. You can look back at the history and see why a design is changed. Cons Needs constant maintenance In the early phases of pre-production everything tends to stay organized and up-to-date. But when production starts then it is easy to forget to document important decisions. You need a dedicated wiki manager to keep everything organized and relevant. Need to be near computer If you are in a room without a computer then the design is inaccessible. Low resolution The pages don’t print out nicely and the resolution of the graphics is low. Large, detailed illustrations don’t fit on the screen. Can’t write on it While it is easy to make text changes it is impossible to make quick diagrams. You have to open up a separate illustration program, save your work, upload it to the wiki and link to it.
  • Observation Both printed Word documents and electronic wiki sites have a common problem. Most of the team won’t read them. They are too busy. It’s easier to ask. It’s not their department, etc. So if you are really trying to communicate design information to the entire team then you have to realize that any information that is not right in front of someone had the potential to be ignored.
  • Inspirations Before I start talking about the specifics I wanted to share with you some non-game designs that inspired me.
  • Architectural Drawings When I was younger I wanted to be an architect. I like how an entire building can be summed up on one page. The information on the page is tailored to the audience. The client usually wants to see the elevation view, while the contractor wants the floor plans and material lists.
  • Lego Manuals I’m sure you have seen these. Lego manuals have no words yet convey a huge amount of information.
  • Cut-away Diagrams These show the internal workings of common objects. This clearly shows the relationships between the different elements. Imagine converting this drawing into text and putting it on a wiki. How many pages of text would it take to describe this engine?
  • Kid’s Placemat Placemats for kids are one page and contain playfully disguised information.
  • Napoleon’s March This is a famous chart by Charles Joseph Minard. When I first saw this illustration I was impressed by how much information was contained on one page. The width of the line shows the size of Napoleon’s army as it marched into, and back out of, Moscow. It shows also shows geographical information, dates and temperatures.
  • One-Page Design Examples
  • UI When I was working at Blizzard I was making UI flow diagrams and I noticed that a few engineers were hanging the documents on their walls for reference. Why would they hang these on the wall but my design documents would just get ignored in a stack of paper on their desks? Could I make the designs as compelling as these charts?
  • DHack Overview We were working on a prototype of Diablo 3 to test our new 3D engine. Instead of writing up a traditional design bible I made a simple graphical map that shows the different levels and what type of monsters, traps and treasures appear on each one.
  • Act 1 Overview After the DHack prototype I kept using the same style as the game grew. I would make these diagrams and take them to meetings so we could get a good overview of the how the game was shaping up.
  • Act 1 Diagram (later) After 2 years of iteration this is how it looked. I started taking the one-page technique to the extreme, wondering how far I could push the concept before it would break. This diagram shows the relative location of areas, the approximate timing, the player’s expected level, monster names, monster model thumbnails, special abilities and damage types. Here I realized the most important trick behind one-page designs: print on large paper.
  • Act 1 Diagram (close up) Here’s a close up showing some of the detail. For each section of the map you can see the dominant terrain feature, the player’s assumed level, the approximate amount of time the player should be in the area, the total elapsed time from the start of Act 1. There is information about each monster: The model name, AI combat style, elemental damage.
  • Winterstone Castle Detail When necessary, the individual areas were fleshed out in more detail and given their own one-page design. This one shows a top-down view, an isometric view, and several tech trees describing how the castle levels up as the game progresses.
  • Diablo Combat Ask an artist to explain Diablo combat in one page and you will get this. While concept art is a powerful way of emotionally expressing the theme, it typically informs the art design, not the game design. It tells you the end state, but doesn’t tell you how to get there.
  • Combat Diagram Sadly, as a game designer, this is how I would make a diagram showing combat in Diablo. The illustration needs to focus on the iconic rather than be an actual screenshot. If you are too literal then people will focus on the surface, not the information. This chart shows the different attack patterns that take place in Diablo’s 2D, isometric combat.
  • Combat Detail By combining the primitives from the previous chart you can get many different types of attacks and abilities. Think of the previous page as the dictionary of standard words, and this page as a paragraph constructed using those words.
  • The Simpsons Game After I left Blizzard I went to EA and worked on the design for the Springfield section of the Simpsons game. I thought it would be easy because I could just find a map in the TV show. But this was the best we could find. Not too helpful…
  • Cardboard Design we made a cardboard model that took up the whole table in the design area.
  • Cardboard Design (later) Over time the map was fleshed out. I consider this a one-page design, even though it is technically on a table, not a page. But it meets all the requirements. There are no pages to turn, not a lot of text to read, and hard to ignore. (It was out in the middle of the design area and everyone had to walk around it every time they came and went to their desks.)
  • Springfield Overview After the cardboard map was finalized I made this simple diagram to show the high-level layout and how the various sections were connected. But I missed the benefits of the map on the table.
  • Springfield Map Grows So I printed it out on a plotter and started adding more and more detail. Eventually I made little models of the main buildings to get a sense of the vertical scale.
  • Springfield Map (final) Here is the final map. This was a giant poster and was in scale with the final 3D layout. (Including the width of the sidewalks.)
  • Springfield Interiors There were also several interior layouts that I had created. These show all the objects needed to make each location authentic. (I had to watch a lot of Simpsons episodes!) This information went to our level producers who turned these into asset lists for the external groups that were creating all the props.
  • Springfield Interiors More…
  • Springfield Interiors More…
  • Springfield Interiors More…
  • Springfield Map (really final) I wanted to put all of the information onto one massive diagram. There wasn’t really a need to do this, but I wanted to see how far I could push the one-page idea. It turns out that you can get pretty far as long as you have a plotter.
  • Springfield Map (close-up) Unfortunately, PowerPoint is a terrible way to show this document. Even if this image was projected onto a large screen it would still look bad because of the low resolution. Blowing up the image just makes the pixels bigger, it doesn’t add any detail. Here is how it really looks… [Switch over to Adobe Illustrator and zoom and pan around the actual document.]
  • Creating a One-Page Document Hopefully by how you are getting excited about trying some of these techniques out at your workplace. Here are a few tips and tricks I have picked up over the years.
  • Basic format Here is a simple template to use. What is the title of your document? If you don’t know then ask yourself why you are making it. Make sure to date everything. Since these will be printed out and passed around the office it is the only way to keep some sort of version control. Give your diagram a lot of whitespace. If you cram things too close together than no one will want to take the effort to read it. A central illustration in the middle of the diagram can help draw attention and acts as a focal point. Under the central illustration put a description with additional explanation text. Use callouts around the illustration to give extra detail. Some of your callouts may be illustrations, too. Add notes underneath to clarify important concepts. Use sidebars and bullet points as checklists, high-level goals, or other necessary information. Pay attention to the size of things. Make important things bigger. This includes font sizes as well as illustrations. Start out at letter size, then work up to legal, 11 x 17, and posters as the need arises.
  • Tools and Software You will want to use a vector illustration program like Adobe Illustrator. Vectors keep the file size is small. You need to be able to translate, scale and rotate the elements around quickly. Mathematical description gives perfect resolution for your printer. Can export as JPG, Flash or PDF for the wiki.
  • Actual Example This diagram is from a pet training game and demonstrates the principals shown on the previous slide. (Central illustration, title, callouts, etc.) This design shows how a pet might grow up to have different personality traits based on how it was trained by the player.
  • Flow Charts From the same pet training game. This Flow charts are particularly good at showing relationships between systems. This is the main loop that shows how the player’s actions influence the simulation. The two basic functions, “Player Action” and “Computer Action” is a common loop that appears in nearly all games. This simple diagram clearly shows the actions the player can take and the effect it will have on the creature’s behavior in the future. Be careful when working with flowcharts because this could happen…
  • Bad Flow Chart If your drawing gets too complex you are probably thinking about the problem at a too high of level. My rule of thumb is that if I have to cross lines in a flow chart then I’m doing something wrong. Simplify! Distill the chart down to the essentials. Compartmentalize systems. (I found this chart by doing a Google search for “bad flow chart”. It is meant to show how the recent Health Care Bill is structured.)
  • Story Boards A simpler form of a flow chart is a one-dimensional storyboard, which takes you from one scene to the next. Unlike a traditional storyboard for a movie or animated sequence, this is not meant to show every event, but only the key moments. It covers the entire player experience from the introductory tutorial to the end-game.
  • Timing Diagrams This is a map of the Creature game portion of Spore. It shows how the creature moves across the land as it levels up and shows the approximate strength of the carnivores and herbivores it will meet along the way. The actual geometry/geography of the map is unimportant. What is more important is the relationship between space and time. I think of this type of a diagram like a musical score. Music written on the page is not the same as music being played. Similarly, this diagram is not the game itself, but shows the structure of the game and sets expectations about the minute-to-minute, hour-to-hour and day-to-day play patterns.
  • Relationships Between Modules This chart is from a robot combat game where the player has to battle robots from three different galactic clusters. It is a type of flow chart, but also contains information about the relationships between the different portions of the game (building your robot, fighting, choosing an arena, etc.). In many ways this diagram is showing the entire game (at a very high level) on one piece of paper. Every game has similar modules. If you were to diagram your game at this level how would it look?
  • Relationship Between Units This is a rock-scissors-paper style diagram showing the strength and weaknesses of different robot factions. It functions similarly to the previous chart, but instead of looking at the whole game we are now only looking at one small section: the strengths and weaknesses of the different robot factions. The first version of the chart looks nice, but the drawing made me realize the design lacked variety and was too predictable. Looking at the central triangle gave me the idea to try something else…
  • Relationship Between Units (2 nd pass) Instead of having each faction occupy a corner of the triangle, I made it occupy a side. This gives each faction a dynamic range that the player can explore. Basically each faction goes from a single, focused “point” to a spectrum along a “line”. For instance, instead of always having the Futurions be the “High Damage” faction, they can now range between “High Damage” and “Fast”. Since the player builds the robots it adds a lot more depth to the game and significantly increases the number of possible battles.
  • Matrices and Tables Thinking about a design as a matrix is a great way to breakdown a complex problem into an easy to manage whole. I use this matrix approach all the time as a way to organize and understand design problems. First, you want to determine two primary attributes of your problem and make a grid.
  • Matrices and Tables In this hypothetical example I’m trying to create skills for an RPG. The table is divided into Class and Faction cells.
  • Matrices and Tables I wanted each Class to have 2 skills and each Faction to have 3. As an added constraint, no two Classes would share the same Faction categories. In just a few minutes I was able to make this chart and it clearly shows the relationships. Imagine how much more difficult it would be to work from the bottom up. (i.e., Take a bunch of pre-made skills and then try to organize them in a meaningful way.)
  • Matrices and Tables Here is a real world example from Spore’s Cell game. This chart shows all of the NPC cells that appear in the game and is arranged by environment (time) on the vertical axis and by size on the horizontal axis.
  • Matrices and Tables This is a more complicated example showing how every cell part interacts with every other part. The programmer working on this part of the game was initially trying to “bottom up” the interactions by playing the game, noticing an interaction, and then trying to fix it base on what he felt was right. But every day during the playtest we would find new interactions that needed work. So instead of working through it by trial and error I made this chart and we met to fill in every square in one meeting. In this way we knew we had a complete solution, we could see all the relationships between the interactions, and the programmer could use it as a checklist to make sure every case covered. Eventually we gave this chart to the testing group so they could validate that the design matched the actual gameplay.
  • Matrices and Tables Sometimes the information is too complex to represent as an easy to digest diagram. This is an Excel spreadsheet used to figure out the archetype of your space-faring species in Spore. It takes into account 4 dimensions: how you played as a cell, as a creature, as a tribe, and as a civilization. All those factors combine to determine which 1 of 12 archetypes you will be (and the associated bonus you will get). This chart bothered me because, although it was complete, it seemed overly complicated. I started playing with the data to see if I could come up with another way to represent it…
  • Spore Archetype Diagram This was my first pass. The player starts out as a cell (“CLG” in the middle) and makes decisions that eventually lead to the final archetype around the outer ring. The red dot means you did something “mean”, the green dot means you played “nice” and the blue dot means you were neutral. At each phase of Spore you get to make the same choice over again. This diagram looks cool, but is an inaccurate representation of the data. For instance, it implies that the final choices form a circular loop, when actually…
  • Spore Archetype Diagram …it is a spectrum, with the “meanest” guy (the Warrior) on the opposite side of the “nicest” guy (the Shaman). This is basically the same diagram as the previous slide, but squished into a 180 degree arc instead of a 360 degree arc. (Think of it like a Japanese folding fan. In the previous slide it was open all the way, in this slide it is half closed.) Although more accurate, this illustration still seemed wrong to me. For instance, the pattern of colors that formed along the outer edge looked too random.
  • Spore Archetype Diagram I’m going to skip the technical details, but eventually I realized that the problem was easier to solve using vector coordinates. Each time you did something “mean” (red) you moved up. “Nice” actions (green) move you down to the right. “Neutral” actions (blue) move you down to the left. This was the final one-page diagram that I used to explain the algorithm to engineering. Well…it could have been the final diagram, but I got somewhat obsessed with the problem and kept on going. I had this urge to see what the full space of possibilities looked like when charted.
  • Spore Archetype Diagram I drew out every possible vector that could occur. At this point I didn’t really know what I was doing, I was just visually playing with the data. After I drew all these shapes I was curious to see what it would look like if I aligned all the origins…
  • Spore Archetype Diagram To my surprise I got this! This was what I had been searching for: a visual representation of the giant Excel spreadsheet.
  • Spore Archetype Diagram After some clean-up and explanatory notation, this was the final, final diagram. Don’t worry if it doesn’t make sense to you, because to fully interpret it you need to be very familiar with the inner workings of Spore. The main point of this series of slides is not to explain Spore’s design, but to show you how working on a one-page diagram can help the designer uncover new elements of the design. In other words, the act of creating the diagram is the act of designing.
  • Benefits You might have a specific person or group that needs the information, but if you do it right then everyone on the team will benefit. (Level designers, programmers, artists, marketing, testing.) Make sure it gets seen. Hang it up on the wall. Print it out and put one on key team members’ desks. (Take old ones back.) Put thumbnail versions on wiki pages and link to a printable PDF. Encourage them to draw on it and give it back to you. (“Battle map” meetings.)
  • This is the design that came off the printer…
  • …and here’s how it looked after the level designer had it for a day. You want this to happen! Take this information and work it back into the next iteration. Just because it is printed doesn’t mean it is final. The purpose of this approach is to get the team engaged in the design, not to make artwork that will be framed.
  • Benefits To make a diagram like the ones I’ve been showing involves a lot of thought about the game. What is important enough to put on this diagram? Forces concise design: How can I simplify the core design? What is the essence? Highlights relationships between modules: How do all the systems fit together? Aids problem solving: Complex problems are broken down into simpler chunks.
  • Summary What is the purpose of design? A design that is only read by designers is worthless. You have to let the team in on it, too. One-page designs (when done correctly) can make communication easy for everyone and gives the whole team a common visual reference point. Like your game itself, the document will go through several revisions. It can take a lot of time and energy, but when you pull it off it is worth it. From experience I can guarantee you that your team members will read a one-page design.
  • Please try these techniques out at your own workplace. Start small and simple with sub-systems of your game. If it works and you (and your team) are benefiting from the approach then gradually expand the technique and see where it takes you.
  • One pagedesigns

    1. 1. Note: Please turn on the notes view to see the spoken portion of this presentation. One-Page Designs Stone Librande Creative Director, EA/Maxis
    2. 2. Overview • Standard design documentation • What are one-page designs? • Creating your own one-page designs • Benefits
    3. 3. Design Bibles
    4. 4. 1. Game Mechanics 4. Sound and Music 1.1. Core Gameplay 4.1. Goals, style, format 1.2. Game Flow 4.2. Sound effects 1.3. Characters/Units 4.2.1 GUI 1.4. Gameplay Elements 4.2.2.Special effects 1.5. Game Physics 4.2.3.Environment 1.6. Statistics 4.3. Music 1.7. AI 4.3.1. Events 1.8. Multiplayer 4.3.2. System screens 4.3.3. Level theme2. User Interface 4.3.4. Situations 2.1. Flow chart 4.3.5. Cinematic soundtrack 2.2. Functional Requirements 2.3. Mock-up 5. Story 2.4. Buttons, icons, pointers 5.1 Backstory and world 5.2. Character descriptions3. Art and Video 5.3. Game text, dialog requirements 3.1. Goals, style, mood 5.4. Sample scripts 3.2. 2D art and animation 3.2.1. GUI 6. Level Requirements 3.2.2. Special Effects 6.1. Level Diagrams 3.3. 3D art and animation 6.1.1. Flow diagrams 3.4. Cinematics 6.2. Asset revelation schedule
    5. 5. Pros • Definitive source of information • Entire design is in one place • The act of creating the document is the act of designing the gameCons • Doesn’t scale up • Hard to manage updates • Difficult to search
    6. 6. Design Wiki
    7. 7. Pros • Easy access • Easy to update • Bite-sized chunks • Team contributions • History tracking and accountabilityCons • Requires constant maintenance • Hides design relationships • Low resolution • Frustrating viewport limitations
    8. 8. Observation • Problem: Most people don’t read past the first page or screen. • Solution: Only use one page.
    9. 9. One-Page Design Inspirations
    10. 10. One-Page Design Examples
    11. 11. Creating a One-Page Design
    12. 12. Flow Charts
    13. 13. Storyboards
    14. 14. Time + Space
    15. 15. Relationships Between Modules
    16. 16. Relationships Between Units
    17. 17. Matrix
    18. 18. Character Class Fighter Archer Mage Scout Thief Warlock Fire MetalFaction Nature Water
    19. 19. Character Class Fighter Archer Mage Scout Thief Warlock Rage x Fireball x x Demon Fire Metal Cleave Piercing x x Backstab xFaction Nature x Hunting x Tracking x Golem Water x x Ice Bolt Swimming Potion x
    20. 20. Benefits• Team  Easy to share designs across team  Make sure the designs are seen  Hand out pencils and encourage participation
    21. 21. Benefits• You (the designer)  Forces a complete understanding  Forces concise design  Highlights relationships in the system  Aids problem solving
    22. 22. • The goal of design is to efficiently communicate ideas.• It can take a lot of time and effort, but isn’t that what you are getting paid for?• People will read your designs!
    23. 23. Thank you!