Playtesting

Note: throughout this document I refer to a playtest as a "demo." It really isn't - its a playtest. A player will try out your game so you can get some feedback.

Playtesting of the games will happen on Tuesday, March 27th. You will have time to do more work after the playtesting, but part of the idea of the project is to have something for people to try out at this point.

Feature Freeze

In a real development process, at some point before a milestone you freeze the feature set and focus development effort on testing and bug fixing.

We strongly encourage you to adopt this strategy - for example picking a time a few days ahead of the deadline for "feature freeze." A bad bug will probably detract more from your playtests than an extra feature.

We will not enforce a feature freeze. However, you must tell us at what point it happened (even if it happened implicitly because the playtest started and you had to stop hacking).

Code Freeze

You should freeze your code at 12:01AM on March 27th. You should avoid last minute fixes - you will probably just break something else. We will not enforce this deadline, but we strongly encourage you to adopt it.

In the event that you really believe some last minute things will make a big difference, you must document what changes you made after the freeze.

The playtesting itself

A "playtest" will be an approximately 15 minute session for the tester. You should have everything all ready to go - the program up on the screen, the instructions printed out (or on screen), ... Things are scheduled into 20 minute slots, so its pretty tight.

Ideally, you should be passive during the test: you should just watch the tester play with your game. Your documentation (either on-screen or printed) should be self-explanatory enough that the tester can look at it and go.

In practice, you will probably want to help your tester out. Try to observe as much as possible - you will learn a lot from seeing what is hard for people. But its OK to answer questions, and if you see someone really getting stuck, give them advice. You should not take over for them (except at the end if you want to show off something).

Playtesting is not the time to show off the cool features in your game. Its a time to learn the reactions of a player, so you can refine things later.

The PlayTesters

Each game will need to be playtested by:

1. the instructor
2. the TA
3. at least 8 other members of class (outside of your team)

This means that every team will need to provide at least 10 playtests.

Some other things:

• Every person in class needs to play test at least 2 other groups' games. (the math works out = 6 groups * 8 demos = 24 students * 2 games)
• Every person in class must give at least 2 demos. Some people might

need to give three. (more demos need to be given since there's the TA and instructor, so there's a total of 60 demos)

There will be a scheduling process in which teams and times will be matched up.

Making this go smoothly

Our goal is to pack 60 demos into a very short amount of time. To pull this off, we will need to be efficient.

• please show up early to get set up
• get yourself logged into a computer before having to give a demo. make sure things work. even if you need to play someone else's game before giving your demo (leave yourself logged in if possible). it takes too long to log in/out between demos
• try to stick to the schedule - we are packing a lot in. if you want to play the game more, you can do it afterwards

but most importantly:

• be sure to show up!

Dealing with No-Shows

It is really important that you make your scheduled demos (both as player and tester). Other people are counting on you.

In the event that something goes wrong (you're sick, etc.) let the TA and instructor know ASAP so we can plan around it.

If you show up to play a game in a particular time slot and the tester isn't there, try to find someone else on their team who can get you started with the demo.

If you show up to give a demo in a particular time slot and the player isn't there, try to find someone else to give a demo to.

What happens afterwards

After the playtest, the playtesters will need to write up a brief review of the experience. Be sure to include:

1. Your general opinion of the game's idea (independent of how well its implemented).
2. Your general opinion of the game's promise - how good could this be if the team had some more time.
3. Your general opinion of the game in its current state - how good of a game is it?
4. Your opinion of the game experience. Were there sufficient instructions and tutorials to get you started? Did you have to ask the author a lot of questions to figure things out?
5. How solid is the implementation? Did it crash? Were there lots of things you had to overlook in order to play the game?
6. What do you think is good and bad about the game?
7. What do you think should be fixed/added if the team had some more time?

You can divide your review into two parts: a "public part" that will go to the team, and a private part, that only goes to the instructor and TA. The returned reviews will be semi-anonymous, but since the numbers are small, it might not be too hard to figure out.

You must send your playtest review to Rachel by noon on Wednesday. She will gather all of them up and send the (non-private) parts to each group later that afternoon. Hopefully that feedback will help with your final writeups (and maybe even the final projects). She will remove the names, so each group will get all 10 in one big lump.

After the Playtest

After the playtest, you can go back to finish your project for the final deadline. You will get the writeups from the playtesters to help in this.

A seperate page will discuss what you need to turn in for the final project.