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

• A chapter on standardized development practices for programmers, including

the environment they will be programming in, how to build the game, and
how to treat each version.

•

A chapter on how other nonprogramming roles will interface with the technol-
ogy of the engine, such as how the artists export art into the game, the toolset
the designers will use for scripting and placement, how sound engineers get
sound into the game, how all members of the team will be able to test and
play the game, as well as establishing size conventions for how much memory
can be used at a single time, and other technical questions.

• A chapter on localizing the game content: how the game can easily be migrated

into different languages and how to handle that migration.

Asset Lists

Other documents that should be created are asset lists. These are lists showing the
available art assets that developers can place within the game. These are extremely
helpful and can be exported into task lists by producers.

Schedules and Milestones

Producers and the people in charge of maintaining the schedules that the game devel-
opers must follow generally create scheduling charts detailing the entire team's tasks
from the beginning of the game to the end. There are a variety of software solutions
for these documents, led by Microsoft Project. These documents are continually
monitored and updated, as their creation at the beginning of the project takes a lot
of guesswork and conjecture to figure out how much time should be allotted for a
specific task.

4.6 Conclusion

Game documentation can sometimes be the best part of the process of making a
game. The initial potential of creating a game based on a single sheet of paper is
intoxicating. However, as time goes by, maintaining those documents, especially the
game design document, can be the last thing you want to do. However, you must
remember that these documents are sometimes your sole means of communication
with a diverse and spread-out team. They may be your only way of defending a
feature that may be cut otherwise if you can show that the stakeholders already agreed
to put that feature in at an earlier date. Game documentation is the truest source of
the vision of the game, and if the documentation becomes stale or obsolete, you have
to wonder what that does to your game.