Guidelines for the Functional Specification
Created by: Game Designer
Target audience: Game
Development Team
Approval: Game Producer/Project Manager
The functional
specification (or spec for short) outlines the features and functions of
the product. The target audience is the team doing the work and those
responsible for approving the game design. The functional spec is a culmination
of the ideas, criticisms and discussions to this point. It fleshes out the
skeleton of the vision as expressed in the game concept and game proposal. It
is a springboard from which the software plan and production schedule is
derived and the implementation begins.
It’s important that it is
all written from the user perspective. In other words, what is seen,
experienced or interacted with should be the focus of the document. Readers
are really just looking to this document to visualize what’s in the game, not
how it works.
The length can vary from
five pages to a few hundred, depending on the complexity of the game. You really
should not aim for a page count. It is just important that each section under
these guidelines be addressed. The time involved in writing the functional spec
is anywhere from a few days for say a puzzle game, a month for a shooter, to a
few months for a complex game such as a strategy game.
It is useful to have
summary level paragraphs at the start of every section, so that readers can get
the gist without skipping any sections or losing any confidence in the
thoroughness of the specification.
Note – the functional
spec in not a technical document so programming terms should not be used. Use
the 100-year rule where the information would be understood 100 years in the
past and the future.
The functional specification can be broken down into a few major
sections:
1
Game Mechanics
2
User Interface
3
Art and Video
4
Sound and Music
5
Story (if applicable)
6
Level Requirements
7
Game demo – pass/fail
1 Game
Mechanics
The game mechanics describe the game play in detailed terms,
starting with the vision of the core game play, followed by the game flow,
which traces the player activity in a typical game.
Avoid using actual numbers or programming terms. These will
come later in the technical specification, written by the programmers who will
want to do things their way (usually the right way). Just tell them what you
want to accomplish. For example: "The units should slow down when going up
hill and speed up when going down, unless they are a hover or flying vehicle.
How much they are affected should be a factor of their climbing and
acceleration statistic as well as the angle of the incline."
Game mechanics are broken down as follows;
- Core
Game Play: In a few paragraphs describe the essence of the
game. This is similar to the description section in the game concept,
except that it’s non-narrative, and usually expressed clearest in bullet
points, though this could vary depending on the type of game.
- Game
Flow: Trace the typical flow of game play with a detailed
description of player activity, paying close attention to the progression
of challenge and entertainment. All activity should actualise and extend
from the core game play. Be specific about what the player does, though
try to use terms like "shoot", "command",
"select" and "move" rather than "click",
"press" and "drag". This keeps the description
distinct from how the actual GUI will work, which is likely to change.
Refer readers to specific pages in the User Interface section when you
first mention a GUI element such as a screen or window or command bar.
- Game
Pacing: The game needs to move at a good pace. The overall game
length and level length (how long to finish) need to be considered here.
How quickly does the game become difficult and what factors make the game
more difficult/ challenging to the player. Both these points need to be
detailed and included later in the Level Design seeds.
- Characters
/ Units (if applicable): These are the actors in the
game controlled by the players or the AI. This should include a brief
description and any applicable statistics. Statistics should be on a
rating scale i.e. A to Z or Low to High, so that it’s clear where units
stand in relation to each other in broad terms. Special talents or
abilities beyond the statistics should be listed and briefly described,
but if they are complex, they should be expanded upon in the game play
Elements section. To visualise the characters, the following
characteristics should be detailed:
- Personality
traits
- Appearance
- Motivation
- Catch
Phrase
- Name
- Game
Play Elements: This is a functional description of all elements
that the player (or characters/units) can engage, acquire or otherwise
interactive with. These are such things as weapons, buildings, switches,
elevators, traps, items, spells, power-ups, and special talents. Write a
paragraph at the start of each category describing how these elements are
introduced and interacted with.
- Game
Physics and Statistics: Break out how the physics of
the game should function, i.e. movement, collision, combat etc.,
separating each into subsections. Describe the look and feel and how they
might vary based on statistics assignable to the characters, units and
game play elements. Indicate the statistics required to make them work.
Get feedback from the programmers as you write this, as how the game
handles the physics and the quantity of the statistics will severely
impact performance issues.
- Artificial
Intelligence (if applicable): Describe the desired
behaviour and accessibility of the AI in the game. This includes movement
(path finding), reactions and triggers, target selection and other combat
decisions such as range and positioning, and interaction with game play
elements. Describe the avenue through which the AI should be controlled by
the level designers, i.e. using .INI files, #include files of game stats
or C-code, proprietary AI scripts, etc.
- Multiplayer
(if applicable): Indicate the methods of multi-player play (i.e.
head-to-head, cooperative vs. AI, teams, every man for himself) and how
many players it will support on the various networking methods. Describe
how multi-player differs from solo-play in game flow, characters/units,
game play elements and AI.
Prioritise the key elements of the game. This is vital for
the production schedule. In addition, build in flexibility to allow alternative
game elements be used if the original designs cannot be used.
2 User Interface
It’s starts with a flowchart of the screen and window
navigation, then breaks down the functional requirements of all the screens and
windows. That done, the GUI artist is free to do what he or she feels is right
as long as it meets the requirements. To get him or her started you should
provide mock-ups. This often is to the designer’s benefit to think everything through.
Then follow up with a description of all the GUI objects that need to be
programmed to make all the screens work.
- Flowchart: This
charts the navigation through the various screens and windows. Use VISIO
or similar flowcharting tool to connect labelled and numbered boxes
together, representing screens, windows, menus, etc. On the corner of each
sheet, put a numbered list of all the items for easy referencing and ease
of defining tasks for the programmers.
- Functional
Requirements: This functional breakdown of every screen,
window and menu lists the user actions and the desired results and may
include diagrams and mock-ups. While the specific interaction (buttons,
hotspots, clicks, drags and resulting animations) can be listed, it’s
often best to keep this separate from the list of functional requirements
as these can evolve during implementation. Of course if it’s just easier
to think in terms of clicking a button or it’s really important that
something work a certain way, then by all means get specific about the
method of interaction.
- Mock-ups:
Create a mock-up for all the screens, windows and menus. It’s a good
starting point for the artists if they have no idea what else they may
want to do. Don’t waste your time creating anything really pretty. Just
create simple line drawings with text labels. Colour can be very
distracting if it’s bad, but if it’s important, go ahead. Some drawing
programs have templates that make creating mock-ups very quick and easy.
- GUI
Objects: These are the basic building blocks used to create all
the screens, windows and menus. This should not include the items seen in
the main view portal, as these are covered in the art list in the next
section. The GUI objects are primarily listed here for the programmers to
know what pieces they’ll need to code and have for putting together the
screens. You should explain in detail how each is interacted with and how
they behave. It may seem a bit obvious and not worth documenting, but it
really helps when drafting together the technical spec and schedule to
know exactly everything the game will need. For some games, this can be a
very quick list to put together – buttons, icons, pointers, sliders, HUD
displays etc. But it’s much more complicated in games where the interface
is at all different.
3 Art and Video
This should be the definitive list for all the art and video
in the game. If all design elements are not locked down (v common) add a couple
of placeholder references for art to be named later, like mission specific art
and art for marketing materials, demos, web pages, manual and packaging.
- Overall
Goals: This is where you should spell out the motifs,
characteristics, style, mood, colours etc. that make up the goals for the
art. Gather consensus with the lead artists and art director and make sure
they see eye to eye with the project’s director or producer. Doing so now
will save a lot of time later if they end up redoing everything because
the goals were never clearly defined
- 2D
Art & Animation: To include all know elements. Break your art
down into sections, as detailed below;
-
Game Play Elements: Player and enemy
animations (sprites or models), game play structures and interactive objects,
weapons, power-ups, etc. Don’t forget damage states.
-
Terrain: Environment art like tiles,
textures, terrain objects, backgrounds
-
GUI: Screens, windows, pointers,
markers, icons, buttons, menus, shell etc
-
Special Effects: Salvo, explosions, sparks,
footprints, blood spots, debris, wreckage
-
Marketing and Packaging Art: This
includes web page art, sell sheet design, demo splash screens, magazine adds,
press art, the box and manual
- 3D
Art & Animation: This serves the same purpose and has the same
requirement of the 2D Art list above. The difference may be in how the
work may be divided. Art teams like to divide 3D art task lists into
models, textures, animations and special effects, as they usually divide
the tasks this way to maximize talent and skill and maintain consistency.
- Cinematics:
These are the 2D or 3D scenes often shown as an intro, between
missions, and at the end of the game. These should be scripted like a film
script as separate documents. This, however, is production work. For the
purposes of the functional spec, just list them here with the general
purpose, content and target length. If any video is involved, list it in
the following subsection.
- Video:
If you have any video in your GUI for say pilot
messages, break it down here. All video tasks will require scripting, but
that is production work. List the general purpose, expected length, and
general content like number of actors and set design, even if it ends up
being blue-screened into a 3D rendered background.
4 Sound and Music
Overall Goals: Stress the aesthetic and
technical goals for the sound and music. Describe the themes or moods you want.
Name existing games or films as examples to aspire to. Issue technical edicts
and editing objectives, such as sampling rates, disk space, music formats, and
transition methods.
Sound FX: List all the sound FX required in
the game and where they will be used. Include the intended filenames, but be
sure to consult with the sound programmer and sound technician (or composer) on
the file naming convention. This makes it easier for people to find the sound
FX and fold them into the game. Don’t forget about all the areas that sound FX
may be used. You don’t want to overlook anything and throw off the schedule. Go
through all the game elements and your art lists to see if there should be some
sound associated with them. Here are some to consider:
GUI: Button
clicks, window opening, command acknowledgments
Special Effects: Weapons
fire, explosions, radar beeping
Units/Characters: Voice
recordings, radio chatter, stomping, collisions
Game Play Elements: Pick-up
jingle, alerts, ambient sounds
Terrain (Environment): Birds,
jungle sounds, crickets, creaks
Motion: Wind,
footfalls, creaking floors, wading, puddle stepping
Music: List all the music required in the game and where it
will be used. Describe the mood and other subtleties. Music will often reuse
the same themes and melodies. Mention where these themes should be reused.
Consult the composer on this.
Event Jingles:
Success/failure/death/victory/discovery etc.
Shell Screen: Mood
setting for title screens, credits, end game
Level Theme: Level
specific music (designers choose the theme)
Situations: Sets the
mood for situations (lurking danger, combat, discovery)
Cinematic Soundtracks
5 Story (if
applicable)
Write the synopsis of the story told by the game. Include
the back-story and detailed character descriptions if it helps. Indicate the
game text and dialogue requirements so they can be added to the schedule.
6 Level Requirements
- Level
Diagram: Whether this is a linear campaign, a branching mission
tree, or a world-hopping free-for-all, the level diagram should be the
backbone upon which all the levels are built. The important thing is that
it just presents a road map for the level designers and for the readers.
- Asset Revelation Schedule: This should be a table or spreadsheet
of what level the game’s assets are to be revealed to the player for the
first time. There should be a row for each level and a column for each
general type of asset. Assets include power-ups, weapons, enemy types,
tricks, traps, objective types, challenges, buildings and all the other
game play elements. The asset revelation schedule ensures that assets, the
things that keep the players looking forward to the next level, are
properly spaced and not over or under used.
- Level
Design Seeds: These are the seeds for the detailed paper
designs to follow. Detailed paper designs at this point are less
legitimate and unlikely to survive intact. Designs created after the
designers have had time to experiment with the tools and develop the first
playable level are much more likely to succeed. It’s best to just plant
the seeds for each level with a description of the goals and game play and
where it ties into the story (if applicable). A thumbnail sketch is
optional, but very helpful if the designer already has a clear idea of
what he or she wants. Be sure to list any specific requirements for the
level, such as terrain, objectives, the revelation of new assets, and
target difficulty level.
7 Game Demo – pass/fail
The 1st playable demo is a crucial milestone in
the project – it will determine whether the game concept is successful. The key
features (the essence of the game) needed for this demo are to be listed. All
team members must be aware of these features.
Common Mistakes
Here are some common
mistakes to look out for:
- Insufficient details: The descriptions need to be
specific enough to convey intent and function. Avoid using vague terms
unless you follow up with specifics.
- Duplicate development specs: Programmers, artists, sound
technicians and level designers will create their own schedules and
technical doc from this document – do not duplicate their work here.
- Ambiguous or contradictory material: Watch for this. It clouds the
vision, creates misunderstandings, and invalidates the functional
specification.
- Unrealistic designs:. Try to keep a mental total of
how long the design is going to take to implement when fleshing out the
specification. Cut extraneous, non-essential features and save them for
the sequel; or be prepared to argue the merits of keeping the features and
extending the ship date.
- Getting too personal with the design: The Game Designer produces the
game design doc – he/she does not own it. Game design is a collaborative
process - the functional specification should include all valid inputs.
- Wandering vision: This may happen as you write
the functional spec. Even with a good concept document and proposal,
there’s still some room for interpretation. Avoid being influenced by
whatever game is in vogue at present, or a game that has a serious
influence with the development team.
·
Poor
layout – make it
readable! .
·
Plenty
of white space
·
Serif
font for body text
·
Bold
headers
·
Spaces
between paragraphs
·
Short
lines of text
·
Direct
the eye towards important material