Monday, May 2, 2011

Game Design Logs

If you still practice or encourage the outdated practice of writing long design documents, you are doing your team and your business a grave disfavor. Long design docs embody and promote an insidious world view: They make the false claim that the most effective way to make a game is to create a fixed engineering specification and then hand that off to developers to implement feature by bullet-pointed feature.

Great game development is actively harmed by this assumption.  Pre-allocating resources at an early stage interrupts the exploratory iteration needed to find the fun in a game. A written plan that stretches months into the future is like a stake through the heart of a good game process. Instead of quickly pivoting to amplify a delightful opportunity found during play testing, you end up blindly barreling towards completion on a some ineffectual paper fantasy.

Yet, there is still a need for documentation.  Why?
  • We need a persistent repository of decisions: Teams include many people and conversation occurs asynchronously.  Without centralized documents, you end up with a fragmented conversation where many decisions made in one-on-one conversations are lost to the broader team forever.   
  • We need a shared vision: Documents also helps forge a common vision of the next iteration.   In a situation where everyone has strong and varied opinions, it is essential that someone can lead the team to by unambiguously stating what comes next.  Apparently even God needed documentation. 

Design logs

What I do now is write a little something I call a 'design log.' Game design is a process of informed iteration, not a fixed engineering plan that you implement.  The form of your design documentation should flow from this philosophy.

How to write a design log

  1. Start with a concept:  At the very bottom of the design log is the initial concept.   This is the rough idea started the design in the first place.  These are 2 to 10 pages long and contain just enough text, images and inspiration to start development.  I usually focus mine on the core interaction loop that we want to first prototype. 
  2. Build the prototype:  Design logs exist as a supplement to a working version of the game.  Make something you can play as soon as humanly possible.  Kill graphics, features, plot or anything that gets in the way of making a game you can react to on a tactile and experiential level. 
  3. Add a Daily Entry: After substantial fiddling with your prototype, add a daily entry above the concept to your design log.  This contains daily play notes, prioritized next steps and ideas.  The goal of the daily entry is to move the project forward. You are constantly trying to answer the question "How do we improve the current game?" 
  4. Repeat: Every day or two, you add a new daily entry and the old ones eventually roll off the bottom of the screen.  Much like a blog, the fresh stuff is at the top and the old stuff is at the bottom. 
For the daily entry, I try to keep to the following format, but it is really quite flexible.
  • Heading: The heading is today's date.     
  • Play Notes:  These are the designer's reaction to the day's working build.  I list what worked well and issues I ran into.  For every issue that's raised, I try to come up with a reasonable solution. 
  • Prioritized Next Steps:  If the list of issues is long, I'll call out the order in which they could be tackled.  Sometimes I'll work to create this list, if the backlog has gotten large.  For those agile folks out there, think of it as a Just-In-Time backlog. If you don't need this section at a point in time, don't add it.  
  • Tasks accomplished:  If work has been done, we mark it on the document.  Some teams add a new list of work accomplished to the daily entry.  Others just cross off notes directly in the doc.  
  • Experiments: Big, crazy experiments that move the game forward in big steps.  Without these, you cannot leap to a better local maxima. 

Tools for creating a design log

I personally love using Google Docs for my design logs.  Here are some of the advantages.
  • Real time conversation:  Multiple people can edit the doc at the same time.  I've had some very high bandwidth editing sessions with 3 people all adding and resolving comments like crazy.  No more passing documents around or managing versions. 
  • Comments tied to text:  People can comment on specific section of the text. They can also reply to the comments.  This keeps the conversation focused on specific details instead of hand waving.  No more long rambling thread that diverged from the original topic long ago. 
  • Ability to resolve comments:  Once a comment thread is finished and the resolution incorporated back into the doc, you can resolve it and hide it away.  This keeps the document clean and lets you know when it is time to move on. 
  •  Email alerts: When someone adds a comment, other users subscribed to the doc get an email.  This acts as a re-engagement system that brings the very busy people on the team back to the document. 
Some tools are poor choices for creating design logs:
  • Microsoft Word:  The lack of decent collaboration tools results in locked files, overwritten files and stagnant conversations.  Word is the single most used writing tool, yet it remains the worst possible choice for working designers. 
  • Email: Email lets you reply to specific issues nicely, but the thread of the conversation seems to splinter off rather rapidly. Or you get the counter productive 'epic email thread'. For short term issues it works reasonably. For designs that live longer than a week, email designs turn into an incoherent mess. 
  • Blogs:  I've been trying to get blogs to work as design spaces for years.  The inability to tie comments directly to text is the major failing as is the inability for others to edit the post simultaneously.  Many developers create developer blog, but most feel like one-to-many medium instead of a collaborative conversation that moves the game forward.  Consider these issues a challenge for those of you who love blogs. 

Some tips for using the design log effectively

  • Don't add too much in a single day:  It can be tempting for the designer to add dozens of pages of notes and ideas in a single day.  This just overwhelms the team.  A good rule of thumb is to keep the daily notes to a level that can be read in 5 minutes.  It is uncommon that even a large team will be able to accomplish more than a page or two worth of work in a day, so self edit and focus the writing on things that will make the biggest impact.   When it comes to design, there are no awards for quantity only quality.  Instead of pouring out a giant missive, take a walk and consider what really matters.  Your designs will improve. 
  • For larger teams consider having a handful of logs.  We have a design log and an art log for one project and that splits up the discussion nicely.  I intentionally work with small teams, so I'd be curious to hear how the concept works with production heavy teams that traditionally have difficulty iterating on and evolving their design. 
  • Make sure you have a conversation, not a monologue: Ultimately, a good design log is an ongoing conversation, not the rambling of an isolated individual.  By talking things through together, everyone internalizes the design and makes it their own. Without this conversation, you just have meaningless words on a page.  


Here are the benefits I've noticed of the design log approach.  These are attributes you should look for in any healthy design process.
  • Real:  The design notes are heavily based off the last working build.  This reduces the tendency for the designer to wander off into la-la land imagining cool systems that don't tie back to the game you are actively growing. 
  • Actionable:  Each day there is a list of improvements that the team can work on next.  Very little about the design is theoretical. 
  • Communal:  Everyone can jump in and comment and make suggestions. The design notes often act as a lightning rod for directing comments and prompting ideas. 
  • Focused:   This is not a spaghetti wiki.  There is a clear thread of intentional design from the bottom of the document all the way to the top.  You can approach the document as a new team member and read the story of how the game has evolved.   
  • Fresh: The topmost items on the log are always new insights based off new learning from the latest build.   Stale items fall to the bottom of the doc.  This ensures that the document is meaningful to reads and encourages you to create an always living and evolving document. 
  • Agile:  As you learn more about the dynamics of the design, you can very easily steer towards the most promising opportunities.  For many teams, especially ones in preproduction, a design log can replace backlogs and task lists. 
Most importantly, the game design log fits the nature of design:  It is an essential quality of a game design that it evolves over time.  At the heart is a functioning product used by real people who have real reactions to what you've built.  You try new things.  You trim experiments that you imagined would work but didn't.  You double down on the delightful surprises that you could have never predicted upfront.  A design is not plan of execution.  A design is living process that grows a result organically from the journey that team takes together. It is an alchemical chain reaction of players, systems, teams, talents and design.  The starting point influences, but cannot fully define the end result.

There is no place for a dusty design tome in such a dynamic world of evolution.  On the other hand a design log fits. It helps remove the oppressive emphasis on completing preordained features.  Day-by-day, an active design log encourages the team to embrace the iterative spirit of great game development.

take care