Communication Lab 5
Due: Tuesday, March 1st at 11:59 pm
The focus of today's lab is to work on the
This is not one of the documents that you get to revise, so we want to use the
communication lab to give you a shot at a first attempt at this document.
You will get this feedback returned before you have to submit the final document.
In order to give you some fast turn-around on this lab, we do not want you submitting
a complete milestone document draft. We want you to only turn in what you complete
during the lab. Do not spend a lot of time on this exercise outside of the lab.
Just write down what you come up with
during lab time.
If you are unsure about anything, the
course staff will be
circulating about the room. They have been through this exercise before, do not
hestitate to call on them for help.
Preparing for the Gameplay Prototype
Part of the purpose of this lab is preparing for your
next week. We you define the deliverables below, we want
to pay close attention to the gameplay prototype. You are using this lab as a way to
give us a heads up on what you plan to do.
Because we are thinking about the gameplay prototype, Traci will also use some time in
this lab to talk about our expectations for the next round of presentations. The
presentation format for gameplay is different for gameplay prototype, and we want you
to be prepared.
Outlining the Milestone Document
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. Start with the five
major two-week software deliverables:
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 and Java
Alpha Release: Basic code complete with a playable level; should include a level editor
Beta Release: Basic features complete with a several playable levels; should have plans for user testing.
Final Release: Levels complete but perhaps not polished; bug fixing only at this point.
For each of the these five milestones, write a paragraph describing the following two items.
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.
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 milestone 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.
If you are unsure of what consitutes a good Test for Acceptance, look
at the milestone document for
This document has some of the best acceptance tests that we have ever
Due: Tuesday, March 1st at 11:59 pm
Limit yourself to the work that you do in the lab. We do not want you working
on this lab outside of class; you have too much other work to do. Put your
answers in a simple text file called milestones.txt
and submit this to CMS. You only need to submit this file once for the entire group.