Due: Thursday, October 19, 2017
For the second milestone, your group should make the first playable version of your game, write a game design document, maintain and update your backlog of user stories, and put your game in an online repository (GitHub or Bitbucket). Along with your updated backlog, turn in a plan that describes what you plan to do for the third milestone.
Each person in the group should turn in a short progress report as described below.
Write a game design document that describes the design and implementation of your group's game. The original pitch will be a good starting point for this document. This document should also include information about the software design and implementation of the game, so perhaps "game design document" is a bit misleading.
There are lots of books and web sites that talk about how to make a game design document, and there are even more books and web sites that talk about how to document software design. However, for this project I am not interested in the format as much as I'm interested in the usefulness of the document for your group.
Here are a few places you can look at for ideas about game
• Chapter 9 of Games, Design, and Play: A Detailed Approach to Iterative Game Design
The Structure section of the Wikipedia page has a good list of sections that you should consider: story, characters, level/environment design, gameplay, art, sound and music, and user interface and game controls. For purposes of this class I'm not interested in the marketing information described on the tutsplus web page.
Your game design document should answer these questions:
• What makes the game fun?
• What decisions will the player make? • What are the game mechanics?
Diagrams and sketches can be very helpful.
In the software design parts of your game design document you should include descriptions of the most important game objects (C# classes), their methods, and their inspector attributes. You should also explain how the game objects communicate with each other.
Although the point break-down for Milestone 1 included points for playability, the build for that milestone was extremely limited. For Milestone 2, your game should include all of the most important features in the game, even if they are somewhat simplified. The idea is to get other people to play your game and give you feedback. If your game doesn't give players a good feel for what the game is about, they probably won't be able to provide useful feedback.
As group members complete implementation of user stories in the backlog, add information to your group's backlog.xls file that tells when the user story was implemented, who implemented it, and how much time was required. You can also add short notes or explanations to the user stories, but longer explanations should go in the game design documentation.
For Milestone 3 I will ask your group to update your game design based on feedback you receive on your first playable game and based on our discussion of game design in class. Explain which user stories you will be implementing for Milestone 3 and how they relate to the feedback you receive and the game design concepts we talk about in class.
Make a repository for your game on GitHub (http://github.com) or Bitbucket (http://bitbucket.org). This is a requirement for Milestone 2. I recommend that you use an online repository because it's a good way to manage code for a group project, and knowing how to use code repositories is a valuable skill. However, if your group finds that it doesn't work well, due to lack of experience or for other reasons, you can use some other way of managing your code. In your README file, explain how I can access your group's repository.
For each group milestone, 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. You can include comments in addition to the numberical rating.
--A description of how your group is functioning as a whole with regard to communication and coordination and with regard to progress on the project.
--A description of your contributions to the project during this milestone.
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.
The rating should be on a scale of 1 to 5, with 5 being the best. The total of the ratings of your group members should not be more than the number shown below for your group size.
|Number in group||Total points|
You can also include comments with your numeric ratings.
If you are not in a group, turn in a progress report that tells what you did for the milestone.
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).
|70||Web build of your game|
|30||Implemented user stories make a playable (fun) game and give a good feel for the game so that playtesters can give meaningful feedback.|
|30||Game design document|
|20||Project is in GitHub or Bitbucket|
|15||Plan for Milestone 3 (in README file)|
|15||Progress report, including rating of other group members. Turned in individually.|