Claypool's Lectures at Osaka University

Claypool's Lectures at Osaka University, Summer 2010
Project 4: Play Testing

Due date: Sunday, July 25^th, by 11:59pm

Objective:
This is the fourth and final project that you will complete in working in the game development process. 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.

Motivation:
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.

Details:
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 will be randomly assigned to evaluate and test the game prototype of one other group. You will be given the code for their project (.gmk file) and their initial Game Treatment (from Project 2), for reference.

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.

Submission:
Your Fix List document is to be emailed by 11:59pm on the day the assignment is due.

Name your document lastname_firstname (with the appropriate extension .doc, .txt or .pdf).

Email your zip files to me (claypool at cs.wpi.edu).

Objective:	This is the fourth and final project that you will complete in working in the game development process. 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.

Motivation:	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.

Details:	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 will be randomly assigned to evaluate and test the game prototype of one other group. You will be given the code for their project (.gmk file) and their initial Game Treatment (from Project 2), for reference. 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.

Submission:	Your Fix List document is to be emailed by 11:59pm on the day the assignment is due. Name your document lastname_firstname (with the appropriate extension .doc, .txt or .pdf). Email your zip files to me (claypool at cs.wpi.edu).

Back to course page.