Chapter 4
Game Design
for Indies
    to document? at is the question: whether
‘tis nobler in the mind to suer the slings and arrows of outra-
geous and sudden ideas, or to take arms against a sea of troubles and begin
by writing everything down?”
If Hamlet were an indie game designer, he might have thought some-
thing like that. Indeed, most indie developers ask themselves something
similar when beginning a new project: why make the eort of document-
ing our ideas and trying to crystallize them before the actual work starts?
Is it really useful? Or should we just go along day aer day, iteration aer
iteration, and see where our inspiration leads us? And, if we decide to
document, which format is most suitable for a given project? Will anyone
really read it?
In this short chapter we’ll try to answer these questions and see how
to approach design documentation eectively from an indie perspective.
In professional settings, game design documents still take the shape
of the infamous “Game Design Bibles,” tomes oen spanning 100+ pages
outlining every possible detail in the game. Every studio has its own spe-
cic formats, but in general, most tend to include sections covering the
following topics:
42  ◾    HTML5 Game Development from the Ground Up
1. Introduction/general information: A high-level description of the
game, just one paragraph to capture the attention of the reader.
2. Detailed game description: e nuts and bolts of the game, in as
much detail as possible, usually including several subsections:
(a) Core gameplay and its elements (e.g., race to an end, territorial
acquisition, etc., and how they are implemented)
(b) Game ow (e.g., whether the game is structured in chapters, lev-
els, etc.)
(c) Characters/units (including detailed descriptions in terms of
classes, abilities, and eventual statistics)
(d) Game physics
(e) Articial intelligence (purposes and approaches used)
(f) Multiplayer (how it works and which specic game modes it is
used for)
(g) Walkthrough (a step-by-step guide for the whole game or at least
for the rst few levels)
3. Level requirements and progression: How the game progress is
structured, including the following:
(a) Level diagrams and maps
(b) Flow diagrams (usually accompanying the maps, describing
what is going to happen in each area of the levels)
(c) Description of puzzles (if any)
(d) Assets (which are used in each level and how/when they are pre-
sented to players)
4. Story: If story plays an important role in the game, it should have its
own dedicated section.
(a) Backstory and world description (for example, describe the lore
of the fantasy world the game takes place in)
Game Design Documentation for Indies  ◾    43  
(b) Character descriptions (go more in depth on histories and back-
grounds of both playing characters and nonplaying characters)
(c) Game text, dialog requirements (how we are going to tell the
story to players)
i. Sample scripts
5. Graphical user interface (GUI): All the information and options
that are displayed to the player across the game, from the rst menu
screen onward.
(a) Flowchart (how the dierent screens are linked, e.g., menus,
options, etc.)
(b) Functional requirements (what kind of information do we need
to display?)
(c) Buttons, icons, pointers, bars, text (e.g., how and where score,
health/mana bars, dialog windows, etc. are displayed)
(d) Mock-up (an overall view of how the GUI will look)
6. Art: e general graphic style used and eventual references: in particular,
(a) Goals, style, mood, references
(b) Two-dimensional art and animation
(c) Special eects
(d) ree-dimensional art and animation
(e) Cut scenes
7. Sound and music: Special eects, voice-overs, and music
(a) Goals, style, and formats used
(b) Sound eects
i. GUI (e.g., mouse clicks)
ii. In game

Get HTML5 Game Development from the Ground Up with Construct 2 now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.