Milestone Document

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.

We outlined some of these milestones the very first lecture. 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 grades, the milestone document counts as part of the team workflow. A milestone document is not a document that we want multiple revisions of. In fact, we expect the milestones that you set out in the document to change significantly as the semester progresses. Instead of revising the milestones documents, teams will update the milestone tasks in the 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 each person in each team thinking about the process now; planning prevents panic. As long as we see that each team is making a good faith effort to plan out work throughout the semester – even knowing that everything will change – we are happy.

Table of Contents

• The Milestone Document
• Milestone Guidelines
• Examples
• Submission

The Milestone Document

For this class, we have identified the basic milestones; it is up to each team to tell us what is planned for each one of them. The milestones officially begin with the conclusion of the nondigital prototype and should address the specific tasks below.

While we care about the other assignments (e.g. the documentation that you write between deliverables), we will not worry about them for this exercise. Start each milestone with the following information:

• A title
• A short description
• A due date
• The production dates
• Presenters (two or three) for each course presentation (see the calendar)

In addition, provide a short paragraph detailing the informtation below.

Deliverables

What do you expect to deliver at the end of this two-week milestone? Please be reasonable in setting these goals. Teams are picking a small list of features from the final project and implementing them over this two-week sprint.

Obviously, the 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 each team to complete a level editor for the game. We strongly recommend finishing 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 start working on it right away. However, if it is a platformer or other game where AI is less important, then the team 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 the team’s test for acceptance, imagine that we are grading the milestone deliverable. How would you like us to evaluate it for a grade? What would count as an A? or a B? While we will not actually give letter grades on an individual milestone, this is a good way to express your team’s test for acceptance. Did you meet or exceed the predicted milestone?

It is very important that teams have concrete goals for the tests for acceptance. Subjective criteria like “the game is fun” is very hard to measure, and so teams cannot tell if they passed the test or not. On the other hand, teams 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 Darksouls.” 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 solid milestones that outline progress.

Risk Assessment

In the test for acceptance, teams have expressed how they would like for us to grade the milestone. Given this, do you believe this is an easy A? Or is there something that the team is worried about? It is okay if this is the case, but the team should list those things here.

Be honest in the answers here. Failing to meet a milestone is okay. This class is all about failure and how even failure pushes us forward. Hiding the reasons why you failed, however, is a no-no. We are likely to subtract from the 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. Hard tasks should be given to team members capable of finishing them.
Use the labs and review the workflow bios for some idea of each team member’s strengths and weaknesses. Remember, also, to specifically list who will be presenters for each of the talks in class (see the course schedule). At the same time, update the workflow task table to include the speakers for each event (all team members must be presenters during the term).

In assigning tasks, we do not need teams 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

This is the first software prototype. It is allowed to be a throw-away prototype in any language.

Technical Prototype

This is an evolutionary prototype. It must be in LibGDX.

Alpha Release

In this release you have completed most of the basic software feature. You need one a playable level, and some evidence of a level editor (3rd party or custom made) is required.

Beta Release

In this release, most of the gameplay features are complete. You have a few playable levels showing a difficulty progression. We expect some user testing after this release.

Golden Master

This release is feature complete with a good number of levels. Your game is finished, but not polished. We expect you to have created an installer that will allow people on the internet to play your game without having to find the right version of Java.

GDIAC Showcase

This is the final public release. There are no more changes at this point. Your game has to be locked and ready to download before the showcase begins.

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.

Luminance

The most recent document on this list, the Spring 2022 game Luminance was eventually rebranded at Dungeon Deception. The presentation of this document is almost perfect, as you can tell from the very few notes in this document. Indeed, our only complaint was the ambitiousness with the project and the lack of a “plan B” if things did not work out. But structurally, this is a very good document to emulate.

Dispossessed

This milestone document was made for the game Dispossessed in Spring 2015. This is one of the best documents made for 3152, and is an excellent document to emulate. as an older document, it does not contain any grading comments to help you see the issues present.

Squeak & Swipe

This document was made for the game Squeak & Swipe for the advanced course in Spring 2016. This team essentially had the same team members as Disposssed. As a result is an even better version of that document. It does an excellent job of identifying deliverables and breaking them down into tasks for individual team members.

Family Style

The most recent document on this list, this set of milestones was made for the game Family Style in Spring 2019. While developed for the advanced course, 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 for the advanced course 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.

Lifted

The oldest document here, the 3152 game Lifted was a game created over a decade ago in 2010 (before the course was even numbered 3152). 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.

Submission

Due: Sat, Feb 25 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 with feedback for possible revision.

As we have said several times, the milestone document is just for teams to get started thinking about how to organize the semester. We will give you a few comments about whether or not we think your plan is feasible. However, we will be happy as long as you show that you took this exercise seriously.