ENGRC Discussion 4
Today's discussion should be spent on two activities, which are due in the next two
weeks. First of all, you should start work on your
which is due this weekend. When that is done, you should start work on your
While that document is not due for a week, we would like for you to have a close to
finished draft of this document for the discussion when you come back from February
At the start of class, Traci will give you some help on how to approach the milestone
document. We know that many of you struggle with this, because it is so early in the
semester. All we are trying to do is to get 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 need help with the process, Traci and the
course staff will go about the
room to provide help.
The milestone document outlines what you plan to do for each two week deliverables
(gameplay, technical, alpha, closed beta, open beta, and 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.
You might find that the milestone document is too big to complete in discussion.
Therefore, you should spend class time on the most important subset. Start with the
six major two-week software deliverables:
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.
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.
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
the gameplay specification
is identical to the format from the introductory course. This does not mean that it will
be easy, but this may mean that you have to go through less revisions. As always, the
instructions page has a lot of examples to help you with writing this document.
It is very likely that you will not get to this document in class. However, we want a
semi-complete version of this document at the next discussion. We will give you more
details when we post the discussion instructions for that day.