Design Document Structure

  • Uncategorised

Part one of a retrospective on my temporary role as a design lead, writing design documentation for reference and presentation.

Apologies for two weeks of fairly free-form, perhaps nonsensical writing. I’m still very new to this ‘Friday 500’ style of scheme that John McKnight got me onto, but I haven’t been paying its dues recently thanks to ‘crunch time’ at university. Today though, as one half of a module has been sent to the printers and cast from conscious concern, I have time to reflect on the new role I took on as a lead designer.

Before I plunge into the meat of this article, in which I claim some semblance of amateurish insight, some context: for the past six months I have been working first as a level designer, then lead designer for Awesome Cheese’s Floaters – an exclusively two-player co-operative action and puzzle title for Xbox Live and Windows PCs. Inside of a thoroughly entertaining module for my games design degree’s final year, I have been working with four other designers and four programmers to create a demo piece based on this game. While making it, I discovered an utter fascination and passion for writing games design documentation, and so I took the mantle of lead designer.

I feel proud of the work I’ve done, not because I’m confident in the product or my skills, but simply because writing the document has taught me so much. I owe a serious tipping of the hat to Brenda Brathwaite (fast becoming my unwitting guru), and to Mark Baldwin [.DOC], for being amongst a rare number of people actually telling we students what makes a good design document. Even putting the work into practice feels like only a small step in the right direction, but then every little bit of practice helps.

Where we started was probably the same place everyone else starts – lobbing ideas about the meeting room until a few of them go well together, and somebody volunteers to write the useful information down. At the start this was our minutes man, and without a formal document in place the team were able to discuss any new ideas or changes they may have thought up outside the meeting room, via an online forum. Work did start to have to be committed though, so I arranged a wiki installation. It’s from here that I realised how quickly the whole structure of a document can and must change. The first hurdle, as in any large document or general wiki, is working out the structure. How should the pages on this wiki be categorised? Where shall the multimedia go? How should I allow users to navigate the document? As a perpetual fan of the alphabetised bookshelf, online library and neatly-structured Picasa gallery, the hardest thing for me to do here was find a good solution fast – I had no trouble trying to start! So, as in any other coursework or essay, we look to precedents.

As much as it is irritating never to be allowed to see a working design document (at least, from outside of the industry), it is of course understandable why studios would never wish them read by the general public. This then, is the one good thing to come from the canning of a game project. My sole design doc. reference was that written by SEGA Technical Institute for Sonic Mars. Its worth lies in its structure, and particularly in its attention to detail, if not the actual game design itself. Little details like being shown animations for each of the main characters may not occur to a student working without such guidance. As Brathwaite (2008) says, “design docs [..] tell a programmer or an artist everything they need to know to create your game.”

The contents table was revised two or three times before the final structure stuck, and although the details would bore you I noticed a particular change in writing style, as a result of structuring. The best example of this is in a level design pitch, which in my original draft occupied only a few paragraphs. Restructuring that to include greater depth of detail led to vaste swathes of the document being.. fairly unreadable. Brathwaite suggests that designers should “write in an average, everyday voice” – tricky to do when you’ve had to rethink your style thanks to a lack of information. She makes a good point of reminding us that these are colleagues we’re writing for though, and that they may be seeing the document at 3am hoping to find precisely what they need. How does one balance an easy writing style which runs the risk of cluttering, with delivery of cold, hard facts that can turn a disheartened programmer off reading?

Perhaps I’ll never find an answer for that. I certainly can’t think of one now.