IMGD 2900
Digital Game Design I
Class 4: Monday 11.05
Today’s topics
Prototyping
Designing puzzles
Iteration and playtesting
Playtest your puzzles!
Assignment 05
Prototyping
The purpose of prototyping
is to answer questions
about your game by
trying out ideas
Begin with a
problem statement
What are the project constraints?
Resources? Engine? Schedules? Deadline?
Who is the target audience?
How will you measure success?
Write down the answers
Start with specific questions
How large should the grid be?
Should we use arrow keys or the
mouse to move around?
Should the background scroll?
What colors should we use?
What sounds should we use?
How fast should zombies move?
How many types of weapons?
Move on to general questions
Is the core play fun?
Does it stay fun?
How many levels do we need?
How large do levels need to be
to feel right?
Are zombies lame?
Is our title lame?
Is our ending lame?
Each prototype should answer
one question
Forget quality!
Quick and dirty
All that matters is:
Have you answered the question?
You will polish later
Don’t get attached
Prototype code and design
ideas will and must be
thrown away
“You must learn how to cut up
your babies.”
Nicole Epps
Designing puzzles
Designing puzzles 1
Build a toy first
When people see it, do they want to
start fooling around with it, even
before they know what to do?
“To design a good puzzle,
first build a good toy.”
Scott Kim
Designing puzzles 2
Make the goal easy to understand
If the player doesn’t know what to do,
they will lose interest
Make sure you are clear about what
you want the player to know about
the goal of your puzzle
Designing puzzles 3
Make it easy to get started
Make it act like something they have
seen before
Draw attention to any similarities
to familiar things
The power of the title
Designing puzzles 4
Provide a sense of progress
What does it mean to make progress?
Can we add progress steps?
Provide real-time feedback
Let the player know whether they’re
on the right track or not
Designing puzzles 5
Offer a sense of solvability
Assure players that they are not
wasting their time!
Can you begin the puzzle in its
solved state?
Designing puzzles 6
Increase difficulty gradually
Each step towards the solution
should get a little harder
Let players choose order of steps
Examples: Jigsaw puzzle, crosswords
Designing puzzles 7
Avoid bottlenecks
Add parallel challenges, something
else to work on while stumped
Don’t make challenges too similar
If possible, connect the challenges so
that progress in one eases the others
Designing puzzles 8
Offer hints
Well-timed hints help avoid bottlenecks
Gradual hints work really well
Example: InvisiClues
Solving a puzzle with a hint is better than
not solving it at all
Designing puzzles 9
Give the answer
Give players a way to find the answer
from within the game
If they turn to the Web, you have failed
Example: “Solid Gold” Infocom Games
Today’s vocabulary
Sine qua non
“Without which [there is] nothing”
Indispensible, essential, must-have
Today’s vocabulary
Sine qua non
“Without which [there is] nothing”
Indispensible, essential, must-have
Today’s vocabulary
Iteration
Today’s vocabulary
Iteration
The sine qua non of
great game design
Today’s vocabulary
Playtesting
Today’s vocabulary
Playtesting
The sine qua non of
effective iteration
Many types of testing
Design review
Focus group testing
QA testing
Usability testing
Playtesting
Playtesting is embarrassing
The whole point is to find out which
of your assumptions are wrong
But you need to find out what’s wrong
as soon as possible!
Great games come from exhaustive,
ruthless playtesting
One year for game design & development
Two years for user testing
“They just iterated and iterated.”
Sequel has been in development since 2009
3,000 hours of playtesting
600 testers
Playtest questions
Is the player having the experience
we thought they would have?
Does the puzzle actually work as
we intended?
Is it easy to understand?
Is it complete yet? (Probably not.)
Is it balanced yet? (Probably not.)
Shut up and pay attention!
Ask testers to think out loud
If testers get quiet or hesitate,
ask what they’re thinking
Watch faces, not the screen
Record everything they say,
especially questions.
Be alert for surprises
Round 1
Beadwalkers vs Colored Blocks
D N Algorithms vs Hambingers
Pearl Etched Spears vs Team Ishmael
Team Rocket vs Team Sauce
Team Subtlety vs Team Swag Check
Teampest Sereande vs Stormriders
Post-test questions
What is the goal of the game?
Is anything confusing or difficult?
Is there any info that would have been
good to know before starting?
What did you like? Dislike?
How would you describe this game
to someone who has never
played it?
Record the answers.
Assignment 06:
Refine and polish your puzzle
Refine and polish – no errors!
Update your journal
Post final puzzle on team Web page
Bring puzzle and journal to class
Ask yourselves
Is our puzzle easy to understand?
What can we do to make it clearer?
Is it too easy or too hard?
Can/should we add difficulty levels?
Can we make it more attractive?
Should we change the color
scheme, improve the layout, add
sounds or choose better ones?
Can we make it more like a toy?
Ask yourselves
Did we see any interesting techniques
or ideas used by other teams that
we can steal adapt to our project?
Was another team’s puzzle obviously
similar to ours? If so, what can we
do to distinguish our puzzle?
Comment your code
At the top of your main .js file:
// PuzzleName
// Team Boring
// Joe Lazy (jlazy), Mary Idle (midle)
// Released to the public domain (optional)
Post your puzzle on your
team Web page before
noon this Thursday
Make a backup for each
team member on USB
flash drives and bring
them to class
Questions?
Next class: Thursday 11.08