Wednesday, September 02, 2009

Writing about writing

My present workload involves finalizing a sizable amount of design docs. During my time in the industry, I've found that some companies skew towards the "iterate as soon as possible with basic design direction" philosophy while others insist on having a stack of documents and a game plan well ahead of time. Once upon a time, I think a design bible was meant to be a blueprint for where the game would end up, but nowadays even companies that are design doc heavy tend to use them as springboards rather than destinations. At times, it's a bit of a downer to spend hours upon hours working on docs because, for the most part, relatively few people read them and you may find yourself writing up a bunch of great ideas that never see the light of day.

In spite of the potential for disappointment, I find that there are several benefits to writing design docs. First and foremost, it requires a designer to narrow the focus of their ideas into something that can easily be explained. When it comes down to it, most games can be broken down into a small number of pages with a few supporting diagrams for complex concepts. I find that when you put ideas down on paper, you begin to question the pillars that support that idea as well as the potential consequences for other parts of the game. One thing that has been very helpful to me lately is the encouragement of my lead to continuously evaluate how many words each document needs. He is a fan of being concise, and I can obviously trail off into more words than needed to explain something otherwise. Going through the documents to trim off those words inevitably leads to substituting mock up images instead. By doing this, I get to thinking about the user interface for a feature sooner than I would otherwise. If the UI needed to support an idea starts to become massive, then the original system gets more revision to bring the complexity of the feature set down. This documentation iteration cycle creates confidence and clarity within the person writing the doc and helps to get the brain going about questions that peers may ask. Clarity is good.

Design docs also build team investment into the vision of the game. This happens on several levels. In order to improve the quality of the documents, many design departments have a peer review process. This review process sometimes produces a flurry of tangential ideas, but there is almost always valuable feedback that improves the original drafts. By taking the feedback and integrating comments back into the doc, team members feel more inclined to give the idea a chance even if they disagree with aspects of the premise. Once the peer review process is finished and the doc goes out to the rest of the team, there is additional confidence and trust earned from those who see a polished product that better defines what is generally a nebulous vision. I find that engineers especially appreciate the additional thought a designer put into their system and like to have a reference to check up on when they are building out underlying infrastructure.

The last major benefit I see to documentation is that studio managers and executives generally like to see robust paper plans because it builds confidence that preproduction has yielded a direction that will result in a well executed product. While many game developers groan about "needing to please the executives who don't get games anyway", I think they sometimes undervalue who supports their game and why. Anything that can build more advocates, including those who make funding and resource allocation decisions about the project, is only a good thing in my mind.

I guess I talked my way through this post into being an advocate of documentation. I'm still conflicted about the process of writing them, but in the end I see design documents as a brainstorming, refining, and planning exercise that sets the tone for early iteration on a piece of the game. I don't feel strongly that documents need to be updated, unless they involve details of a process or unless they contain tuning data that needs to be referenced by others down the road. After putting the finishing touches on several documents recently, I'm feeling more confident in the pillars that prop up the game systems that have been a little less defined up until this point. I'm looking forward to taking the next steps into building out these systems in game, and hopefully the fruits of these seeds can alleviate some of my reluctance to write these documents in the first place.