Design Doc

Week Thirty-six

(or Is There A Doc In The House?)

As I promised in my last post, I spent part of this past week merging external documents into the main document to create a complete design doc. The final version of the AIM< design doc is finished and can be viewed here. A link to the document can be easily accessed from the AIM< homepage as well.

Part of the process involved highlighting all the parts of the design that did not make it into the finalized build. I’ll talk about the specific features cut in a bit more detail over the next couple of posts. Getting the final document put together was a bittersweet experience as I had a chance to review past builds, early concepts, and examine how the design document evolved over the development process.

I realized this week that I haven’t really talked much about my process in creating the design document. As I explained in my very first post, the game design document is like a game’s rule book. I completely understand if this doesn’t elicit excited squeals. The document is important, though, as it ideally functions to keep development on track and serves as a place where the teams agreed upon design is kept. Anyone can look at the doc anytime and get a sense for what each aspect of the game looks like.

“Ideally” is the key word. For the document to work as intended, the team needs to read the sections that pertain to the work they are doing. Leads should probably read the whole thing, at least when major updates are implemented.

For everyone to want to read the document, the formatting needs to be very readable. The document makes for some dry reading already (unless you’re me and like that sort of thing) and can be bogged down by poor structure or formatting. I had to make a lot of changes before I found something that started to work well for the team.

The “Mech Powers” build version of the document was where readability was really improved. I discovered that dispersing main portions of the document into their own separate documents was easier to update. Separate documents can be linked from the main document for easy access to connected areas of the game’s design. Team members had an easier time keeping up-to-date with changes since all they had to do was read the portions they needed by clicking on the links or checking the separate document.

Separating the largest portions of the game doc also allowed me to create more concise sections. I wrote very brief summaries and descriptions for each section. Any details I tried to limit to a handful of bullet points. My intent was for everyone to be able to get a general overview and quickly decide whether they needed to read the more detailed linked document.

Commenting worked far better with separate documents as well. Previously, if too many comments were made, it was a chore to read through each area due to the unwieldy size of the document. Separated, I could focus on individual sections and quickly get in touch with certain team members about specific comments and design decisions.

Some of my research into game documentation lead me to consider wikis and proprietary software. Google docs is free, though, and I think the system that I worked out is viable for future projects.

I didn’t have much time to experiment with the current document before AIM< was finalized. The change-log has not been updated since the “Mech Powers” build and some last-minute design decisions have not been documented. Violent Traversal doesn’t have any plans to re-visit AIM< in the current iteration so my time would be better spent by writing a couple retrospectives.

If you’re interested in some of the ideas Violent Traversal had in store for AIM<, please check out the doc. It contains a wealth of content I’ve not had time to write about here, including a pretty sweet narrative written by Daniel Bodunov and myself.

Have a beautiful weekend!