Milestone Workshop

The focus of today’s discussion is to work on the
milestone document, which is due this weekend, together with your nondigital prototype. In this document, you will layout your sprints for the semester, predicting what features will appear in each deliverable for the remainder of the semester.

We know that this is a hard document to write, because it is so early in the semester.
While you might have a good idea what you will do for the gameplay prototype, beta release is very far off. We simply want you think constructively about the process. We understand that these milestones are very likely to change as the semester progresses. But making a guess about what you are going to do helps you get organized.

If you are unsure about anything, the course staff will be available to help during this time. They have been through this exercise before, do not hestitate to call on them for help.

Lab Focus

The milestone document outlines what you plan to do for each two week deliverables (gameplay, technical, alpha, beta, final), and how you plan to split up the work.
This document is not a contract; you are allowed to change your mind as the semester progresses. However, it is a good way to start thinking about your process.

Obviously, the milestone document is to big to do in a single communication lab. Therefore, we want you to focus on the most important subset. We only want you to focus on the deliverables and the tests for acceptance (as these two are the hardest for students to get right). Write these us up for each of the five major, intermediate milestones.

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 at least run on a mobile device simulator of your choice.

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. The release should run on a device of your choice.

Closed Beta

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

Open Beta

This release is feature complete with a good number of levels. We expect a complete user-testing plan, with extensive user testing after the release is presented.

Deliverables

Provide us a paragraph explaining the deliverables for the milestone. What do you expect to show us in class for this particular milestone? Remember our description of Scrum(lite); you are picking a small list of features from your final project, and implementing them for this smaller milestone. Which features are you choosing for for this milestone?

Obviously, your features should match the description of the tasks listed 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 finished this by alpha release. However some groups only create a simple editor for alpha, and push the 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.

Tests for Acceptance

Now that you know what the deliverables are, how do you measure success? Or more appropriately, how would you tell that the milestone was a failure?
Answers like “playable gameplay prototype” are not enough; we need to know what you mean by terms like “playable”. Once again, we want you to describe this in single paragraph.

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.

If you are unsure of what consitutes a good Test for Acceptance, look at the milestone document for Lifted. This early document has served as a good model for acceptance tests in this class.