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.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Class 4: Monday 11.05
Iteration and playtesting
Playtest your puzzles!
trying out ideas
What are the project constraints?
Resources? Engine? Schedules? Deadline?
Who is the target audience?
How will you measure success?
Write down the answers
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?
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?
Quick and dirty
All that matters is:
Have you answered the question?
You will polish later
Prototype code and design ideas will and must be thrown away
“You must learn how to cut up your babies.”
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.”
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
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
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
Offer a sense of solvability
Assure players that they are not wasting their time!
Can you begin the puzzle in its
Increase difficulty gradually
Each step towards the solution
should get a little harder
Let players choose order of steps
Examples: Jigsaw puzzle, crosswords
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
Well-timed hints help avoid bottlenecks
Gradual hints work really well
Solving a puzzle with a hint is better than not solving it at all
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
The sine qua non of
great game design
The sine qua non of
Focus group testing
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 & developmentTwo years for user testing“They just iterated and iterated.”Sequel has been in development since 2009
Is the player having the experience
we thought they would have?
Does the puzzle actually work as
If testers get quiet or hesitate,
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
Refine and polish – no errors!
Update your journal
Post final puzzle on team Web page
Bring puzzle and journal to class
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?
Did we see any interesting techniques or ideas used by other teams that we can stealadaptto our project?
Was another team’s puzzle obviously similar to ours? If so, what can we do to distinguish our puzzle?
Comment your codeAt 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 noonthisThursdayMake a backup for each team member on USB flash drives and bring them to class
Next class: Thursday 11.08