|Week 5||Game Wiki||02/26/11|
|Week 6||Gameplay Prototype||03/03/11|
|Week 7||Architectural Specification (Initial Proposal)||03/12/11|
|Week 8||Technical Prototype||03/17/11|
|Week 9||Game Website||04/02/11|
|Week 10||Alpha (Code Complete)||04/07/11|
|Week 11||Game Manual||04/16/11|
|Week 12||Beta (Feature Complete)||04/20/11|
|Week 13||Final Portfolio||04/30/11|
|Week 14||Release (Balanced and Tested)||05/02/11|
|Week 15||GDIAC Showcase||05/14/11|
You should provide us with a milestone for each of the weeks above. You should start each milestone with the following information:
In addition, you should provide us with a short paragraph detailing the following elements:
What do you expect to show us at the end of this two-week milestone? Remember our description of Scrum(lite). You are picking a small list of features from your final project, and implementing them over this two-week sprint.
Obviously, your deliverables should include the tasks in the schedule above. However, it is also a good idea to put in smaller tasks that are important, but not on the schedule. For example, it is a good idea for everyone should complete a level editor; when do you plan to finish this (hint: Alpha). Similarly, when do you finally plan to start programming the AI for your game?
Now that you know what the deliverables are, how do you measure success? Or more appropriately, how would you tell that the sprint was a failure? Answers like "playable gameplay prototype" are not enough; we need to know what you mean by terms like "playable".
To help you with your test for acceptance, imagine that I am grading your milestone deliverable. How would you like me to evaluate it for a grade? What would count as an A, and what would count as a B? While I will not actually give letter grades on an individual milestone, this is a good way to express your test for acceptance.
In the test for acceptance, you told me how you would like for me to "grade" your milestone. Given this, do you believe this is an easy A? Or is there something that you are worried you might screw up. It is okay if this is the case, but you should list those things here.
Be honest in your answers here. Failing to meet a milestone is okay; this class is all about failure. Hiding the reasons why you failed, however, is a no-no; I am likely to subtract from your final game grade if I find "surprising" problems at the end of the course.
Once you understand the deliverables, the test for acceptance, and the risks, it is time to delegate tasks. Hard tasks should be given to team members capable of finishing them. Use the labs to give you some idea of each team member's strengths and weaknesses.
In assigning tasks, I do not need you to assign hours (yet). Just tell me roughly what each person should be focusing on each week. Do not worry if you cannot think of everything; this is the one thing you will change the most as the semester progresses.
It is not as important to get the milestone document correct, as it was to get the concept document and gameplay specification correct. However, it is always good to get it as right as possible on the first try. Therefore, we have provided some examples of solid milestone documents from semesters past. You should use these as templates when writing your own milestone document.
This milestone document, for a game designed in Spring 2009, was one of the best we have ever seen. It does an excellent job of identifying deliverables and breaking it down into tasks for individual team members. However, please do not follow their example; put the title of your game in the milestone document.
Lifted was the overall winner for the 2010 GDIAC Showcase. Their milestone document shows an excellent understanding of the term "Test for Acceptance". All of their tests are great; you should use them as a model for designing your own tests. Unlike Ballin' Beavers, they remembered to include the name of their game.
Every two weeks starting with the completion of the Gameplay Prototype, we would like each group to provide us with a very detailed two-week breakdown of tasks leading to the next boldface milestone. You should think of a two-week report as an individual milestone (or pair of milestones), where you go into much more detail about each of the bullet points.
In particular, in the contributors bullet point, the two week report needs to allocate all of the hours of each team member. Recall that each group member is committed to 10 hrs/wk of work on the project. This means that for each two-week period, the project leader has 20 hours of work to allocate to each member of the team. Your two-week breakdowns must account of all of those hours.
To get a better idea of the two-week reports, look at the instructions for the one that accompanies the Gameplay Prototype. Once you have finished the milestone document (and gotten feedback from it), they are relatively easy to write.
Due Saturday, February 26th at 11:59 pm through CMS.
You should submit a PDF file called milestones. Again, we ask that the file be a PDF so that we cannot annotate it in order to return it to you with feedback for possible revision. It is fine if you create the document in a program like Microsoft Word, but you should convert it to PDF before submission.
The milestone document is not a major part of your document grade. You will get a lot of feedback on it, but we will not grade it as harshly as the concept document and gameplay specification. We are not expecting you to revise the milestone document. Instead, you should treat the two-week reports as your milestone revisions. If we make a comment about the milestone document or the two-week report, we expect you to improve for the next two-week report. If a problem persists for two reports in a row, then we will take off points.