CS/INFO 4152: Advanced Topics in Computer Game Development

Assignment 5
Milestone Document

Due: Saturday, February 27th at 11:59 pm

Typically the timeline for developing software, games or otherwise, is divided into what are called 'milestones'. Milestones are important markers that signify the completion of crucial tasks in the development cycle. The development team creates a Milestone Document, detailing the specifics of each milestone.

Those you from the introductory class should be very familiar with the milestones. The correspond to bolded deadlines on the project schedule page. These milestones are two week sprints where you are expected to have a playable deliverable at the end. For each milestone, you should identify a small list of features to implement, and you will implement them as part of this sprint. By the last milestone, you will have hopefully implemented all of the features necessary to complete your game.

Unlike the concept document, the milestone document is not a single document that you will revise once. Instead, it will be a continually evolving document that you revise as the course goes on. Sprints will fail to implement everything that you set out to achieve, and you will need to reassess your goals. Indeed, this is the primary purpose of the two-week reports; they tell me whether you succeeded and what you plan to do next time. You can think of them as the revisions of the milestone document, if you want.


The Milestone Document

For this class, we have identified the basic milestones for you; it is up to you to tell us what you plan to do for each one of them. The milestones officially begin with the conclusion of the Nondigital Prototype, and should address the following tasks:

Week Task Deadline
Week 1 Group Orientation 1/30/16
Week 2 Group Charter 2/06/16
Week 3

February Break

Concept Document 2/13/16
Week 4 Nondigital Prototype 2/17/16
Gameplay Specification 2/20/16
Week 5 Milestone Document 2/27/16
Content Repository 2/27/16
Week 6 Gameplay Prototype 2/29/16
Week 7 Architecture Specification 3/12/16
Design Specification 3/12/16
Week 8 Technical Prototype 3/14/16
Week 9 Document Revision 3/26/16

Spring Break

Week 11 Alpha Release 4/04/16
Week 12 Level Design Document 4/16/16
Week 13 Closed Beta Release 4/18/16
Week 14 App Store Proposal 4/30/16
Week 15 Open Beta Release 5/02/16
Week 16 Postmortem 5/09/16
Final Document Portfolio 5/13/16
Week 17 GDIAC Showcase 5/20/16

You should provide us with a milestone for every two week period that ends with a deliverable in bold after nondigital prototype (e.g. gameplay prototype, technical prototype, etc.). You should start each milestone with the following information:

  • A title
  • A short description
  • A due date
  • The production dates

In addition, you should provide us with a short paragraph detailing the following elements:


Deliverables

What do you expect to show us at the end of this two-week milestone? Remember the process from the introductory course. 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, we require that everyone complete a level editor for their game. We strongly recommend that you finishe this by alpha release. However some groups only create a simple editor for alpha, and push most of the work on the level editor off until beta (and their games are not as good because of this).

Another thing to keep in mind is issues such as game AI. If your game is a strategy game, where AI really matters, then you should start working on it right away. However, if it is a platformer or other game where AI is less important, then you can delay it until the end.


Test for Acceptance

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.

It is very important that you have concrete goals for your tests for acceptance. Subjective criteria like "the game is fun" is very hard to measure, and so you cannot tell if you passed the test or not. On the other hand, you can measure things like "my roommate really likes the game" or "the majority of the focus group we kidnapped off the street believe the game is better than Modern Warfare". Other examples of good tests are "we can play the game for 20 minutes without it crashing" or "our artist, who has no programming experience, can use the level editor to make a level". These are the types of things we are looking for.


Risk Assessment

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.


Contributors

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.


Milestone Guidelines

Because we are always tinkering with course, we do not post the instructions for each of the deliverables above until the start of that sprint. That might seem a little unfair; we are asking you to mention deliverables without actually telling you what we are expecting for each deliverable. This is lessened a bit by that fact that most of you have been through the introductory course before, but the deliverables are not exactly the same.

In order to help you with your milestones, here is what we are roughly expecting for each major deliverable.

  • Gameplay Prototype: First software prototype; a throw-away prototype in any language.
  • Technical Prototype: An evolutionary prototype; should at least run on the device simulator.
  • Alpha Prototype: Basic code complete with a playable level; should run on a device.
  • Closed Beta: Basic features complete with a few playable levels. Limited user testing.
  • Open Beta: Feature complete with good number of levels. Complete user-testing plan required.
  • Showcase: Public demonstration and release.

Examples

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.

Dispossessed

The most recent example, this document was made for the game Dispossessed in Spring 2016. It is one of the better examples from this class. It is short, but covers all of the key concepts. It also does an excellent job of identifying deliverables and breaking them down into tasks for individual team members.

Ballin' Beavers

This milestone document, for a game designed in Spring 2009, is another excellent example. Again, it does a great job of identifying deliverables and breaking them 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

Those of you from the introductory class may recall that we used Lifted for several examples. 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.


Submission

Due: Saturday, February 27th at 11:59 pm

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.