This is the final assignment that you will complete for this course. This project focuses on testing and evaluating the prototypes that another group in the class has developed. As with the first project, you will work by yourself (not in a group), playing the part of a tester/critic of the work in the interest of improving the final games.

Many of us have at some point played the game with the impossible level, the game that crashed every five minutes, the game with the glaringly superior strategy, or the game with the painfully clunky interface. At some point during one of these unfortunate experiences, it is not uncommon to wonder whether the game's creators had ever actually played the game before shipping it out the door. Many of these pitfalls could have been avoided if the care was taken to more rigorously test these games.

Certainly if we care for the quality of our work and take pride in providing a fun experience to the player then we must take the time to ensure that our game meets certain standards of quality and playability. Unfortunately, many times we find that testing reveals more issues than we have time to resolve. In these cases we must prioritize what to fix based on factors such as what is most important to fix or what is easiest to fix. The purpose of this assignment is for us to put into practice the testing, balancing, and prioritizing that are necessary for eliminating the bugs and honing the "fun-factor" of our games.

For this project, you will evaluate and test another group's prototype, providing feedback on how they could improve upon their game. You will be documenting the suggested fixes that you find in the prototype and prioritizing them based on which you think are most important to fix before the prototype is demo'ed to the public.

You have been randomly assigned to evaluate and test the game prototype of one other group. You will be given the code for their project (.gmk/.gm8.1/.exe file) and their initial Game Treatment (from Project 2), for reference.

Here is the assignment for each group, along with links to all the treatment docs:

Game Treatment	Evaluators
The Battle of Castle Greenway	CSL Studios
Avalon	Brainstorm
TRIAL	The Upperclassmen
Behind the Maze	Benny and the Jets
Iron Angel	Team Winged Kuriboth
Chrono-Guardians	First & Last Games
Super DAKA Chef	VADA
Condiment Carnage	Prototype Productions
WaffleQuest	The Lost Defenders
The Coming Swarm	WaffleBat
Lab Rat	KeJaMa Studios
Scritch Scratch Attack	Team Elder Squerrels

For the evaluation, you will be comparing the other's final prototype against their Game Treatment. You should consider how well the prototype exhibits the potential of the design goals set out in the treatment, with the understanding that the prototype is only a demo of what the game would ultimately be like. Please feel free to be forthright with your critique, as your evaluation will have no bearing on the other group's grade. Qualitative, constructive assessment, as well as positive feedback, is encouraged.

What you will create is a Fix List, where you document as many changes to the game you think are needed. These can be bugs, mistakes in the code that do not work or fixes that need to be made for balance or fun or to meet the original design goals. For each fix, give it a descriptive title, categorize it as either CODE (if a programming mistake), ART (if a fix to the art is needed), GAMEPLAY (if a change to the game/rules/level) or OTHER (if something that falls into none of those categories). Each fix should be given a priority of HIGH, MEDIUM, or LOW. The priority that you assign to each fix should be relative to the other fixes, so that it is clear which fixes should be addressed by the other group first. Then, write a short description of the fix (it can be one sentence, if needed or maybe a bit more).

The lenngth of the list you create will depend upon the quality of the other project and the thoroughness of your testing. However, it is extremely likely you will have a list of at least 10 items, so pursue testing at least until you have that many. In many cases, you will have many more in your list.

The format of the document is up to you. A readable format will have comments for the above categories (and can be done in Excel) but clearly marked categories done in Word or some other format is suitable, too.

When you are ready to submit, zip everything up into a single archive file. Name the file LastnameFirstname_eval.zip.

You will use the new Web-based "Turnin" facility to submit your work. Information about submitting can be found here:

http://web.cs.wpi.edu/~kfisler/turnin.html.

Each person should make his/her own submission.

Your WPI user ID should be used to login, and you should have been emailed a password.
The Turnin assignment ID is eval.