Due TBA (end of the term)
Scores for Milestone 4 will be based on the following items: a web build, playability, game design documentation, features, polish, software design and development process documentation, presentation, an individual progress report, and individual contributions as described below. There is a Turn in section that lists all of the things that need to be turned in. At the bottom of this page is a point break-down that tells how many points are in each category.
Build your game for the web. You will need to turn in the .unity3d file and the .html file. Please test your game in a browser to make sure that it works. Include a README.txt or README.html file that tells how to play your game. I will have limited time to play your game when I'm grading, so it's a good idea to include hints, cheat codes, etc., in the README file so that I can see as much of your game as possible.
It's better to have a relatively simple game that's fun to play than a more complicated game that isn't fun. If your game is fun to play, shows good application of the game design concepts we discussed, and incorporates results of play testing, then it will receive full credit in this category.
Your game design documentation should include descriptions of game mechanics, play test results, documentation of decisions that your group made about how the game should work, and other information about your game. Tuning information (damage done by weapons, movement speeds, etc.) and level design information should also be included.
It's a good idea to document decisions by explaining what you had to decide, what alternatives you considered, how you evaluated the alternatives, and why you chose the alternative that you did. Two important issues in evaluating alternatives are play test results and game design concepts like Costikyan's.
This category includes parts of the game that aren't directly related to playability but are helpful or make the game more interesting. Examples are mini maps, customization, and help information.
Graphics and the general appearance and ease of use of your game go in the category of polish.
Document the software design of your game, including classes and important methods. Also document the development process in terms of the user stories you used. Explain how your group used a repository or otherwise managed code.
|Individual project||5 to 10 minutes|
|Groups of 2 or 3 students||10 to 15 minutes|
|Groups of 4 or 5 students||15 to 20 minutes|
Each member of the group should turn in a separate progress report.
The progress report should be a plain-text or HTML file that includes
the following information:
--A rating of each of the other members of your group in terms of how much they contributed to the project and how well they communicated with the group. The rating should be a single number on a scale of 1 to 5, with 5 being the best. You don't need to rate yourself.
--A description of how your group functioned as a whole with regard to communication and coordination and with regard to implementing the project.
--A short summary of the contributions of each of the other members of your group.
--A longer summary of your contributions to the group.
I will use progress reports to assign individual grades based on the group's grade, but more importantly I will use them to help groups resolve issues before they become major problems.
One member of the group should put the following files in a zip file and turn the zip file in on Canvas:
• Each student should turn in a progress report in a plain-text file (progress.txt) or HTML file (progress.html).
|100||Web build of your game|
|100||Game design document and documentation of play testing|
|50||Documentation of software design and development process, including user stories and scripts|
|20||Progress report, including rating of other group members. Turned in individually.|
|80||Individual contribution, based on your progress reports and the progress reports of other members of your group.|