At the Office

Home

On the Couch

At the Office

In the Library

Mailbox

Neighborhood

Pitfalls of the Working Game Designer: The Devil's in the Documents

Every job description I’ve ever read for a design position includes a line like “excellent verbal and written communication skills a necessity”, and for good reason. Aside from meetings, what designers do more than anything else is write documents. It should come as no surprise, then, that there are many dangers in documentation.

Just as it’s essential to define the tasks, relationships, and roles of design on a team, it’s critical to do the same for your documents. While everything needs to get documented eventually, knowing what to document now and how to do it will save you tremendous headaches in the long run.

The first rule of documentation is to know your audience. If you’re pitching a concept to a publisher, keep it short and sweet. If you’re writing a feature up for testing, make sure you account for every possible interaction. There is no “one size fits all” design document. If you make it too detailed, it won’t get read; if you leave the detail out, the team is going to have to keep coming back to you to get definitions. For this reason, the design “bible” is on its way out. With project intranets, Wiki boards, and file-sharing applications becoming more and more common, targeted documentation is not only viable, it’s the only way to go.

At the same time, you need to be very careful that your targeted documents are absolutely clear. With design as with wishes, you only get what you ask for, not what you want, so it’s your job to make those two things as closely related as humanly possible. Since every reader is different, the worst thing you can do is to take it for granted that people are getting out of your documents what you think you’re putting into them.

Put drafts in front of the people who are going to use the documents, then follow up with them. Don’t ask them “Do you get it?”. Ask open-ended questions: “What do you think of this system?”, “How do you think this will work?”, “What changes would you like to see?”, “What else would you like to know?”. Don’t stop at the contents either. Be willing to adopt your format to the work style of your team. Visual thinkers may be more comfortable with flow-chart diagrams than with blocks of narrative prose. The text may be exactly the same, but the format may make the difference between comprehension and confusion.

Every project is going to have its own needs for documentation. As much as we may want to come up with one format, one way of organizing information, one set of documents we can call “design complete”, the reality is that the only valuable document is the one that gets read and understood. Be flexible to the needs of the team and you’ll save yourself a lot of work in the long run.

Aside from how to document, you also have to know when to document. While the fantasy of design is to have it all done before the team ever starts production, that just doesn’t fly in reality. You can’t put the final numbers into the spreadsheet until you’ve done the balancing; the UI that works on paper may go through a dozen revisions before it needs to be documented for test.

So, what can you do in pre-production? First, all of the “big picture” elements need to be done up front. You absolutely have to define the scope of the game, both in the types and numbers of systems and in the types and numbers of assets, before you can finalize the schedule. Even within those larger-scale, more abstract documents, you need to map out where the next level of detail fits in, and you need to have priorities for how you’re going to scale those systems up or down depending on what happens in production.

Second, pre-production is a great time to work on background, the stuff the player may not need to see but that helps you to build a coherent world and get the team into the spirit of the game. Back-story, character definitions, world rules: these are all great pieces to polish up in pre-production. Just keep in mind that there is such a thing as too much detail.

The farther ahead the design can be pushed during pre-production, the better, but there are limits. Polish that grain of sand too fine and you’ll become attached to it before the team even starts to evaluate it.

It’s been said that no battle plan ever survives contact with the enemy; the same can be said of design documents and production. No matter how tirelessly you’ve worked on documenting the game, once things start getting built, there will immediately arise deviations, unexpected consequences, and questions that need to be answered. You can detail a system down the nth degree, but there will be some issue at n+1 that will have to be taken care of, and it will be, with or without your input.

The key here is that as those details get worked out, they need to be incorporated back into the documentation. Even if they are small and seem insignificant, the worst thing you can do is to blithely move forward and ignore them. For one thing, testing is going to need to know what those details are so they can verify functionality; if you let them accumulate, you’ll find yourself spending hours and days writing documentation just for the testers, when you should be balancing the game. For another, whatever decision-making process you used to arrive at the solution, the rest of the team needs to know about it. Local knowledge may fix one problem, but global knowledge will fix many. Failing to document will lead everyone who comes up against a similar problem to your doorstep (or even worse, they will charge forward with their own solutions regardless of how it integrates with the rest of the game’s logic), and again, you’re going to spend serious chunks of time going back over the same ground with different people.

Revisions are the key, but they are also their own problem. After all, if you update the documentation constantly, then people need to constantly check for updates, and “document fatigue” will set in. The designer’s job may be to document the game, but the engineers and artists have other jobs besides reading the design documents. On the other hand, rare updates run the risk of missing critical events in the development process, causing more work because things have to be re-done.

There are all kinds of tips, like highlighting changes, notifying affected team members when documents that involve them are updated, summarizing changes in e-mails, keeping a consistent location for all up-to-date documents, etc., etc. However, these are only pieces that may contribute to a solution. Unfortunately, like the level of detail problem, this can only be solved for a specific project with a specific team.

Next: Bright, Shiny Objects
Back to Top
Previous: More and More Features

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood