Game Documentation Guide - Professional Techniques for Video Game Writing - page 27

This person is usually the Lead Game Designer. As the core visionary of the
team, the Lead Designer is the one responsible for navigating the development of
the game through the shark-infested waters of entropy, rescoping, and lack of focus.
Other personnel responsible for the upkeep of the game design document could
be a producer, a writer, or it could even be a community affair, where responsible
parties take the time to help maintain the document as changes occur in their own
specialized bailiwick.
Keeping a live document is difficult. One problem is that it is a full-time job.
Someone needs to be on top of all the changes that occur on almost a daily basis.
The next problem is that you'll want to save your old work in case the original plan
comes back into favor. For instance, the planners for the game might find that you
can add back in a few enemy types to the design.
The next difficulty is that the latest document should be available to everyone
who needs to refer to it, from the president of the company to the quality assurance
team. If even one person is holding onto an old document, things can easily go

wrong.
In modern game studios, game documents that live find themselves in one of
two places: in the source control program, such as Perforce or SourceSafe, where old
versions of the doc are easily accessible and everyone always has the most up-to-date
version every time they sync to the depot, or in a wiki on the intranet of the company,
where a quick launch of a browser of their choice gets people to the information they
need.

Source Control
Leaving your game document on a source control program has benefits and risks.
The benefits are that everyone always has the latest version of the documentation.
You can lock out everyone but a few select employees from being able to change the
document, so you limit the chance that somebody will edit the document in a way
that proves disastrous. You also have the ability to recall your old versions in case you
want to refer to or recover old design ideas from the past.
There are few risks to using source control to store your game documentation.
However, in my experience, keeping your doc in a file structure can sometimes make
it easier to ignore. If people have to go searching through their files to find the right
doc, they may not check it at all. Instead, they'll just ask somebody what the game
doc says. This increases the chance they may misunderstand the design and either
do work that isn't necessary or waste time trying to figure out how to accomplish
something that seems so out of place in the original design. Later in this chapter,
we'll cover how to format your game design doc to limit this problem.

Wiki
Wikis have many advantages over the old “huge Word doc� method. Wikis are easy
to edit, easy to place pictures in, easy to create hyperlinks between related pieces of
information, easy to find information in, and generally kind of fun to explore.