Homework: due before class, Monday April 11

Goal: Create prototype 0 of your game. This prototype needs to be able to run, and should
allow at least minimal user interaction. During class you will startup your prototype but a
member from a different team, the player, will "try" to use it. You will not be allowed to
interfere by taking over mouse and keyboard. This exercise will serve as early evaluation
and will provide feedback regarding design assumptions. The player is allowed and
encouraged to comment on usability, engagement and education aspects of your game.

Don't spend too much time on having a complete game. Just make sure there is some
testable part of your game. Don't worry about incomplete artwork. The player will be
allowed to ask any question and you will be allowed to answer. Just no ripping keyboards
out of hand and "just let me quickly …"

Make your prototype available in GORP: If you have an AgentSheets/Flash/Shockwave-
based game make sure to export it so that it will work in a Web page:
-      keep project in a folder (e.g., AgentSheets + Ristretto generated applet folder).
-      Folder must contain "index.html" file with reference to your applet/flash thingy
-      Zip up that folder into a file called "prototype0.zip"
-      In GORP edit your project and goto View/add attachments
-      Upload your "prototype0.zip" file
-      Make SURE that you check the applet check box

Don't wait until Monday in class to find out that your applet is not working. TEST your
applet by launching it from the GORP page.

Before you spend time further developing your prototype make sure to upload your
current version to experience the upload + test cycle.

Notes for Playtesting

Playtesting is one of the most important activities in game development. You don't want to waste the time of your testers. Expect the unexpected. Keep an open mind. Things may not quite turn out the way you anticipated. Learn as much as possible from your experience. The best way to understand your results may be in a reflective mode AFTER the test. Try to record as much as possible. Have one member of your team take notes. Record if you can. Professional developers/testers will record audio and video of users.

Preparation

(Theme: you don't want to waste playtester time fumbling around... be ready to go with minimum startup delay)

coordinate with your sponsor so that you know what the session format will be... will you be working with a few students or with a large group? If a large group, how will your team divide up to manage this, including note taking?
unless it is definitely unrealistic, plan to have the students work in groups of at least two (you will learn a great deal from how the students interact around the game; less from watching solo players). Also, you will be asked for less help this way, which will probably make the sessions more realistic
also, IF you are assuming some kind of teacher guidance for the game, plan that in advance with your sponsor
work out what version of your code you will use, what level materials, what platform, exactly how to set up for the session, in advance
Install your SW before the testing. Testers that need to wait for you while you install, fix etc. will be unhappy testers. Bring a laptop as backup. Keep a stable version of your game.
if you are going to give instructions because they are not yet incorporated in the game, work out what these are, so you are not winging it when the playtest starts
similarly, if you are going to "fake" some parts of the game that are unfinished (as in telling students "at this point what you will see in the actual game is ...") work out what you are going to say in advance (and, obviously, you want to minimize this.)
bring materials for taking notes

Process

(Theme: your aim is to learn things that can help you improve your game, by seeing how it works in a realistic setting)

Aim to make the playtest session as realistic as possible. For most of you, that means as close as possible to the students playing the game without your intervention. If you are assuming some kind of teacher guidance for the game, have your sponsor provide some version of it
Tell the students you are interested in any questions or comments that they have
BUT don't get drawn into providing ongoing help
If they get stuck, ask them what they are thinking, and provide only enough help to get them unstuck. Don't provide long, unrealistic explanations. TAKE NOTES whenever you have to provide help, no matter how minor
Note that "getting stuck" includes "not doing anything", not just "trying to do something and being unable to".
After getting a group started, leave things to them... avoid having them look to you to manage or guide what they should do
KEEP NOTES during the sessions of their questions and your observations. Assign one person from your group to be the scribe. The scribe should not get involved with helping users. The scribe should take notes of what the testers are doing and saying but also what other members of your team say, e.g., what kind of help do they need to offer. These notes should, after the testing, be turned into a document that you can upload to the Gorp.
Pay attention to the atmosphere and emotional tone of the students while they are playing. Are they having fun, or going through the motions, or being frustrated, or being bored? When the fun level goes up (if it does) what phase of your game are they in? When the fun level goes down? Are there things they ask to be able to do again? Are there things they want to show their friends? What?
At the end of a session, ask the students what they think about the game, and for any comments and suggestions. Do this in the small playgroups, not in the whole class together, to limit me-too reactions.

Reporting

(Theme: what are the specific design lessons from the playtest?)

Make a list of weaknesses and strengths, based on what you observed. Where possible, include ideas for how to remedy the weaknesses and amplify the strengths.
General observations (they really had fun, or they were bored) are not as helpful as more specific observations that you can tie to particular features of the game, because you can change particular features.
Evaluative opinions the students express (I really like the dragon) are worth noting, but are not as RELIABLE as observations (the kids got pretty excited when the dragon appeared.) Expressed opinions are very sensitive to bias, either positive (I want to tell these nice CU students what they want to hear) or negative (school is really boring, no matter what people try to do to juice it up).
If students make suggestions about how to improve the game, take them seriously but don't assume you have to incorporate them. Their suggestions are inputs to a design process that YOU are responsible for, so YOU have to be convinced the suggestion is a good one. The customer is NOT always right where design is concerned.

For an industry view of playtesting, see http://www.gamasutra.com/features/production/070797/playtest.htm