Main
About: Schedule Staff FAQ News Materials: Sessions Discussion Engine Reading Writing Style Project: Assignments Groups Requirements Showcase Resources: Code Samples C++ Online Piazza GitHub GameDevNet Submissions: CMS CATME |
Assignment 5
|
Week | Task | Deadline |
---|---|---|
Week 1 | Team Workflow | 1/25/20 |
Week 2 | Initial Proposal | 2/01/20 |
Week 3 | Concept Document | 2/08/20 |
Week 4 | Nondigital Prototype | 2/12/20 |
Milestone Document | 2/15/20 | |
Week 5 | Gameplay Specification | 2/22/20 |
Week 6 |
February Break | |
Gameplay Prototype | 2/26/20 | |
Week 7 | Architecture Specification | 3/07/20 |
Design Specification | 3/07/20 | |
Week 8 | Technical Prototype | 3/09/20 |
Course Redesign | ||
Course Redesign | ||
Spring Break | ||
Week 12 | Document Revisions | 4/11/20 |
Week 13 | Pre-Beta Release | 4/13/20 |
Week 14 | Promotional Video | 4/25/20 |
Week 15 | Beta Release | 4/27/20 |
Week 16 | Final Document Portfolio | 5/09/20 |
Week 17 | Golden Master | 5/11/20 |
Week 18 | GDIAC Showcase | 5/22/20 |
Provide a milestone for every two week period that ends with a deliverable in bold after the nondigital prototype (e.g. gameplay prototype, technical prototype, etc.). Start each milestone with the following information:
In addition, provide a short paragraph detailing the informtation below.
What do you expect to deliver at the end of this two-week milestone? Remember the process from the introductory course. 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.
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 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 solid milestones that outline progress.
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.
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.
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. This is lessened a bit by that fact that most of you have been through the introductory course before, but the deliverables are not exactly the same.
In order to help you with your milestones, here is what we are roughly expecting for each major deliverable.
It is not as important to get the milestone document correct as it was to get the concept document and gameplay specification correct. However, it is always good to get it as right as possible on the first try. Therefore, we have provided some examples of solid milestone documents from semesters past. Use these as templates when writing the milestone document.
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 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.
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.
This milestone document was made for the game Dispossessed, created for the introductory course 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.
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.
As we said, your grade for this document is part of the Team Workflow grade. Because of that, teams should also use this time to actively update your team workflow document. If your team updates Workflow, 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.
Due: Saturday, February 15th at 11:59 pm
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.
In addition, for teams that have revised the Team Workflow document, submit that as a PDF, as well. This is a separate upload in CMS. Do not attach the Workflow to the milestone document.
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.