Storyboards................................
Storyboards are an established film and television device for sketching or mocking-up
shots before they are actually filmed. Storyboards may be included as part of the art
bible or can stand alone as their own separate document. Storyboards are most handy
for mapping out non-interactive cut-scenes, which are quite cinematic in nature and are
thereby well suited to storyboarding. This allows members of the development team to
provide feedback and corrections on those cut-scenes before someone goes to the trou-
ble of filming or rendering them. Storyboards can also be used as concept sketches or
mock-ups for how the game-world will appear to players if the game’s engine is not yet
ready to be used. Such storyboards can be useful both for making the entire team
understand at an early stage where the game is heading, as well as convincing finan-
ciers to fund the project’s development. Much like the game minute document
described above, storyboards can be problematic because they necessarily represent a
single way of playing a given area. Since they have their origins in film, traditional
storyboards are completely linear and may suggest to readers that the game is more
cinematic than it really should be. Indeed, when people fall in love with what they see in
a storyboard they may try to limit the player’s choices to doing only what has been
drawn out. It may be advantageous to use some kind of branching storyboards, where
the consequences of major player choices are drawn and then laid out like a flowchart or
decision tree. Unfortunately, sometimes when people get overly excited by
storyboarding a game it can be another case of movie envy, where developers actually
wish they were filmmakers. Storyboards can be helpful, but only up to a point. In the
end, they cannot replace actually prototyping gameplay on the computer, getting the
game to a somewhat playable state, and then refining it until it is truly fun and all the
player’s choices are available for playtesters to explore.
Technical Design Document.......................
A technical design document (TDD) is the sister specification to the design document.
Whereas the design document focuses on how the game will function, the technical
design document discusses how that functionality will be implemented. You can also
think of it this way: the design document communicates how the player experiences
the game, while the technical design document goes into how that experience will be
implemented. Sometimes called the technical specification, the technical design docu-
ment is customarily written by the lead programmer on a project, and is used as a point
of reference by the programming team. Here is where the code’s structure is laid out
and analyzed. The technical design document is where programmers on the project can
turn to figure out how they should implement a specific system. The document may
include the overall code structure, what major classes will be used, descriptions of the
rendering architecture, details of how the AI will function, and any amount of other
implementation-side information. Pseudocode is appropriate, though not required, in
the technical design document. Though the technical design document may be a good
idea, in the past many projects have managed to undergo perfectly successful develop-
ment cycles without a technical design document ever being created. On the other
hand, with today’s ever more complicated projects, escalating budgets, and the resul-
tant increase in scrutiny placed on all titles, most all games developed now use one or
Chapter 17: Game Development Documentation 317