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.
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
- 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.
- 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.
- 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?”
- 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.
Have you ever tried Basecamp? We are currently using it, annd it seems to do well its job. Plus, it looks like it's made for the process you're suggesting. Backpack could be a great tool too.
LikeLiked by 1 person
This comment has been removed by the author.
Another vote for BaseCamp, as a PM Tool. However there is no capability to comment on individual blocks of text, and the to-do list functionality is too constrained.@Danc could you post a couple of samples of design logs I think I see where you are coming from based upon the diagram and the explanatory text an actual example of a design log would go a long way in clarifying how these work in my mind.I suspect this model could go a long way to supporting the development process beyond game design and development, the problems you describe are seen through out the concept design spectrum.
I applaud the agile approach, but I have a question.I am often brought on games (mainly free-to-play ones) to improve the business side. To harness virality, to keep customers coming back, and to help the developer make money.I rely on developers to find the fun, add the polish that elevates a game to classic status, and to build a solid enjoyable framework. It is expensive (and unnecessary) to loop me into all of these iterations. (Although I think it is really important to have me involved several times during development of the game).On this basis, the game design document has been very useful. It is the quickest and easiest way for me to understand and comment on all the key features of the title.So do you think that your approach works just as well with an external business consultant?
Hi!Great post! Really liked it! Would it be possible to post some kind of dummy-document? For me it was kind of hard to understand what you actually document in the playnotes. Would be nice to see an example even if it isn't a real one.//Mattias
Would using a Wiki in combination with something like google docs work in your opinion ?
This comment has been removed by the author.
I've found the best way to absorb ideas is to see a picture of the note rather than just text.With some ideas drawings, screenshots, mock-ups or diagrams can communicate the idea more clearly. Design is a visual process and so much can be lost in it's translation to language. If you are visualising something, then avoid writing it if a 5 min sketch will convey a clearer message about the design note.Designers!!! Please don't be afraid to draw 🙂
Great post, really like the idea.@Nicholas, have you found GDDs to be kept up to date in your opinion? The single biggest issue with a GDD (outside the fact that designing a game up front is incredibly complex) is the fact that they aren't up to date. I would have thought that more often than not, the GDDs you've been given are fairly inaccurate which could cause you to design business models that are inaccurate?In answer to your question, I could see these design decision logs coupled with a strong vision document (a PowerPoint or a few key 'one sheet' designs) being enough to help you design a business plan around a game.
Nice post, but this kind of workflow is suitable not just for game dev :)We are doing similar things developing an enterprise app, and Google Wave (soon to become apache wave) is probably the best thing I have seen so far for this kind of workflow. We have a constantly moving spec that sometimes has to be discussed by the whole team and clients at the same time.
That's a really interesting way of dealing with an insidious little problem. Possibly it would be put to better use if it was used in combination with a vision and feature document of some sort; a sort of global overview of the game and where it's going? Programmers and artists could work off the logs, while designers, producers and directors could keep an eye on the map and quickly capture an aggregate of the key points.I think most people are of the opinion now that design tomes are antiquated and unweildy!
Added a spoiler free image of an actual game log. Note that the contents of each day vary quite substantially. Sometimes there are just rough notes. Other times there is a new UI mockup or three. Like many light weight processes, the ideas behind the structure and how you use it are more important than a dogmatic implementation. take careDanc.
Tadhg over at Whatgamesare.com just had a post about the return of the game design doc. I find it interesting that this is popping up as a topic of conversation in various places on th web.
Neat – sounds better than our \”design docs\” which are usually conversations in our heads and e-mails spread over time.At what point during the project do you stop maintaining them? I could imagine having a doc for the core game prototyping … and then as that hardens (roughly after prepro) start having a bunch of individual docs for levels / maps / modes … and then switch over to the bug database (as you go into alpha…)
Well, I'm currently building my first \”serious\” game and I have to say that writing a full design document (about 50 pages) for it as been quite invaluable. It allowed me to better structure my ideas, get a clear perception of the required amount of work/stages/goals, and prioritize tasks. I basically took all my notes, scribbles and thoughts, and condensed them in single source, which I use as a reference both for myself and on pitches to potential investors.I'm working alone at the moment, but understand that in a team and over time it would probably become cumbersome to keep it up to date, and thus completely agree with your design log suggestion (and will try this approach on my next project).However, I do think that the base concept should be complete and highly detailed (even though it might change later through prototyping), at least for more complex projects, for the same previously mentioned benefits.
My last project I kept a \”design journal\” for myself, and it was almost exactly this process. There were a few rules I kept for myself:1) Play the game before writing, and only comment on the game as it is today. Don't be constrained by past ideas or directions.2) Write thoughts, not tasks. Tasks come out of thoughts naturally, but tasks themselves don't really evolve the design.3) Try and say something outlandish in every entry.There were a number of other things that I did or happened to do, such as identifying trends, congratulating successes, and framing my state of mind, but those weren't as pivotal for me.Thanks for writing this, it's always good to have another perspective on a process!
I agree wholeheartedly. Good game design is based on the iterative process of coding and testing, and we should take the advice of 37Signals and keep in mind that the Beginning of the project is the time at which we know the LEAST about the project, hence we should make the fewest binding decisions about the project at the beginning, so long as we maintain the original vision.
I don't consider myself a game designer, but I did have the experience of working on game where we did weekly play tests and prototypes. At first I thought that was too frequent but in the end it worked great. It was amazing how often we were wrong and how quickly we recovered.
I like this idea, but i fail to see how it would work for a large game with many different components/bits. Would this work if the \”design\” was broken down into seperate docs? How do you keep everything \”together\” when there are many moving bits?
Wouter, the person behind Sauerbraten, wrote an article on this topic: http://strlen.com/ultimate-collaboration-tool/Also, would Google docs work well enough?
I totally agree with you!!I have used google doc with other cooperators (despite of not working on game design projects :P) for long time to brain-stream ideas and concepts. Although it is not good in formatting, adding non-text materials (e.g. picture) & archiving, it is good at collaborative and iterate until having a clear & concrete output.Therefore, our current approach is to use it to generate & collect comments & ideas in the design phrase, then use other document editing tools (e.g. msword, iword) to consolidate & finalize to a east-to-read output to a cloud based location (e.g. dropbox, google doc for storing) to further fine tune the output.Do you think it is a good approach? :PMoreover, google doc is not good at linking many ideas/things together. When there is many varied ideas, google doc cannot manage well. We usually use sufficient time to discuss to make a coherent direction, have you tried to solve the similar situations in agiler/faster approach? 🙂
I have found some enthusiasts of this aproach, including myself. It turned easy the task to maintain a GDD coherent with current team views
Pingback: I messed up... - randy