Design documentation stages
- Design
treatment or concept paper
- Design
summary/design documents
- Design
specification/product specification/production document
Game/design treatment
- Game
story
- Game
play and look
- Focus
on appearance
- Player
roles and actions
- Strategies
and motivations
- Development
specifications – HW and SW, Algorithm style
Design document
- Start
with basic idea of the game
- Start
detailing plot line
- Players
goal and achievements and work backwards
- Outline
every section of the game
Game outline
- Describe
universal elements- common features to every part of the game (scoring
rules, names, special powers etc)
- Details
of every scene or game level
- Name
for scene
- Detail
- Physical
and audio appearance
- Background
or playfield
- Foreground
objects and characters
- Animations
present for the scenes
- Music
and sound effects
- Script
for characters
- Scenes
and transitions
- Flow
charts for story branches
- Anything
else
Design documents
- Executive
summary
- Product
specification
- Game
specification
- Art
specification
Product specification
- Production
team
- Target
audience
- Time
— game play and shelf life
- Production
tools
- Schedule
of milestones and deliverables
Game specification
- What
is it like to play
- Mock
up the interface
- Summary
of the story line
- Story
boards
- Character
bibles
- Flow
charts to show transitions
- Scripts
for each scene
Considering detail
- What
can characters do? Fly jump invisible?
- How
many enemies does hero fight?
- What
weapons are available?
- How
does the player get rejuvenated?
- Multi-player
stuff?
- What
is game perspective?
- What kind
of sound track?
- What
about main character personality?
Designing the puzzle (LaMothe CD) makes the game interesting
Types of puzzles
- Ordinary
use of objects
- Unusual
use of an ordinary object
- Information puzzles
- Codes
and word puzzles
- Excluded
memo – cause and effect kind of actions
- People
puzzles
- Timing
puzzles
- Sequence
puzzles
- Logic
puzzles – riddles, dialog …
- Trial
and error
- Machinery
puzzles
- Alternate
interfaces
- Mazes
What makes puzzles bad?
- Unnecessary
repetition
- Restore
puzzle – find answer to puzzle when you die
- Arbitrary
puzzles – cause should be linked to effects instead of random
- Designer
puzzles – only designer can solve the puzzle
- Binary
puzzle – wrong à death
- Hunt
the pixel
- Unnecessary
interludes
What makes puzzles good?
- Solvable
- Being
fair
- No
down time
- Randomness
– different each time you played
- Naturalness
to environment
- Amplify
a theme
- Principle
of least astonishment
- Hints
Levels of difficulty
- Bread
crumbs – at first everything works well and then give less direct help, if
user struggles give more help
- Proximity
of puzzle to solution – a fair game gives a user everything they need to
know
- Alternate
solutions
- (Bad)
red herrings
- Steering
a player
Character bibles
- Journals
– designer writes a biography of the characters, updates the life
experiences
- Scripting
– hypertext or linear
Prototyping – design a little, implement a little, and test
a little
- Get
client involved early – customer driven design
- Goals
- What
will finish product look like?
- What
do you need to do?
- Can
we produce the product at all?
- Can
we attract a publisher?

Key points to design document
- Explicit
philosophy game goals
- Make
it readable
- Give
priorities to idea so everyone knows what is important and what is
rejected
- Give
all details cause and effect tables
- How
will you do things -- motion,
animation