Project Milestone 4: Final implementation, report, and presentation

Game and documentation: 11:59pm on Monday, December 11, 2016
Presentation: 4:00-5:15 on Wednesday, December 6th

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.

Web build

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.

Documentation of game design

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.

Documentation of software design and development process

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.


Your group's presentation should include: The length of your presentation depends on the number of students in your group:
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

The times above include set-up time and discussion time. Because of the number of presentations we have and the limited time, it will be important to use your time well and minimize set-up time.

If you don't have a laptop to bring to class, please make arrangements in advance to set up your game and presentation on my computer. If you are using Unity, please make a web build.

Progress report

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.

Individual contribution

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.

Turn in


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 Features
50 Polish
50 Documentation of software design and development process, including user stories and scripts
50 Presentation
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.