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!
