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