Assignment 6
Milestone Document

Due: Saturday, February 22nd 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. Consider this assignment a continuation of the team workflow.

We outlined some of these milestones on the first day of class. Remember that these milestones also correspond to our notion of the sprint in Scrum(lite). For each milestone, you will 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.

When determining your grade, the milestone document counts as part of your team workflow. This is not a document that we expect you to revise over-and-over. In fact, we expect the milestones that you set out in the document to change a lot as the semester progresses. Instead of revising your milestones document, you will update you milestone tasks in your two-week reports later in the course.

Because it is so early in the semester, many students wonder about the usefulness of this document. Since the milestones are so likely to change, why are we writing them down? The purpose of this document is simply to get you thinking about the process now, so that you do not procrastinate until later. As long as we see that you are making a good faith effort to plan out your work throughout the semester -- even knowing that everything will change -- we are happy.

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:

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? Please be reasonable in setting these goals. Teams should pick a small list of features from the final project, and implementing them over this two-week sprint.

Obviously, spring 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 each team completes a level editor for their game. We strongly recommend that teams finished this by alpha release. However some groups only create a simple editor for alpha, pushing most of the work on the level editor off until beta (and their games are not as good because of this).

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

Test for Acceptance

Now that you know what the deliverables are, how can the team 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 each test for acceptance, imagine that we are grading the team’s milestone deliverable. How should we evaluate it for a grade? What would count as an A and what would count as a B? While we will not actually give letter grades on an individual milestone, this is a good way to express the test for acceptance.

It is very important that teams create concrete goals for the tests for acceptance. Subjective criteria like "the game is fun" are very hard to measure, and so we cannot tell if teams passed the test or not. On the other hand, teams can measure elements such as "My roommate really likes the game," or "The majority of the focus group we invited 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."

Risk Assessment

In the test for acceptance, teams identified how graders might "grade" the teams' milestones. Given this scaffolding, does your team believe this is an easy A? Or is there something that plagues the team? It is okay if this is the case, but you should list those concerns here.

Be honest in your answers. Failing to meet a milestone is okay; this class is all about failure. Hiding the reasons why you failed, however, is a no-no; we are likely to subtract from the team’s final game grade if we 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 in more detail that in the team workflow document. 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, we do not need you to assign hours (yet). Just tell us 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. But we are only asking for a good-faith effort here.

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 of a technical component; should be written in LibGDX.
• Alpha Release: Basic code complete with a playable level; should include a level editor
• Beta Release: Basic features complete with a several playable levels. Plans for user testing.
• Final Release: Levels complete but perhaps not polished. Bug fixing only at this point.
• Showcase: Public demonstration and release.

In addition to these milestones, please remember to allocate time/people for testing and debugging. That includes both playtesting and good old unit tests. Most of the milestones we see are written as if the team expects all of the code to be perfect on the first try.

Level design is another important piece in milestones. Programming is only part of what you need to do. A game without content is nothing.

Examples

The challenge of the milestone document is that 3152 students are so uniformly bad at it. This is to be expected -- most of you have never worked on a project of this size before. But since you do not revise this document (the two week reports act as your revisions), this makes it hard to show you an example of a good milestone document.

What this means is that most of our examples come from 4152. By the time you are in that class, you have a better idea of how to construct milestones. But they do have a slightly different milestone schedule: two betas instead of a final release. With that in mind, we hope these example are helpful.

Family Style

The most recent document on this list, this set of milestones was made for the game Family Style in Spring 2019. It is a solid set of milestones, and most of the issues are with formatting and presentation. As you do not get to revise this document, we have left our grading comments in this document to see what we are looking for.

Dive

Dive was another game made in Spring 2019. Overall this is a good document, but we had some questions for the team. We have left these questions in the document so that you can see what to watch out for.

Squeak & Swipe

This document was made for the game Squeak & Swipe in Spring 2016. It is one of the better examples from this class. It is short, but it 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.

Dispossessed

The lone 3152 game in this set of examples, this milestone document was made for the game Dispossessed in Spring 2015. This team had some of the same members as Squeak & Swipe, which is why the document is similar. It is an excellent document to emulate.

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; use them as a model for designing your own tests.

Revised Workflow

As we said, your grade for this document is part of your team workflow grade. Because that, you should also use this time to update your team workflow document (assuming that you did not get a perfect grade the first time). If you update your document, you should add it as a PDF to the CMS submission. If you do not update your workflow, your next chance will be at the two-week report following the gameplay prototype.

Submission

Due: Saturday, February 22nd 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.