With all of the proposals discussed, and the critiques available, teams can choose to build any of the games proposed (each team must pick one of the proposals). A team is welcomed to build a proposal even if they weren’t the ones to propose it. Each team will prepare a written document describing the game they intend to build. The purpose is to force your group to work together to agree on what to do, and how to do it.
This planning document is due on Friday, November 11th at 9am. We need it early since the professor and TA need to read it before the afternoon (when we will meet with each group to discuss it).
On Friday, November 11th (during the lab time slot), each group will meet with the professor to discuss their plan and to get “approval” to proceed.
You should not do any coding until your plan has been approved.
We do not have any way to enforce this, however, we hope you will comply. The idea is that this initial week is spent planning.
In order to make this meeting effective, your team must provide the planning document to the TA and Instructor by 9am on November 11th.
The plan should contain (at least) all of the information included in the original proposal. Update all of those parts as appropriate. The plan should also address the following topics:
- Response to Critiques
- What criticism did the original design get, and how did it affect your final proposal. Note: you might respond to positive as well as negative feedback. Note: in previous years, there was a process where each design got formal critiques. You won’t have that this year, so this section may be blank. But try to seek some feedback from your classmates.
- Group Inventory
- What skills, talents, and resources do the members of your project team bring? Are there things your team is missing or is really good at? How should these effect what you try to achieve?
- Tools Choices
- What tools do you plan to use to implement the project (note: you might change these choices later – but for now, you should have an idea of what to try first)
- Division of Labor
- How do you propose to divide the effort of building the game amongst the members of your team?
- Milestones
- What milestones do you see along the way of building the game? Describe what you expect to have done at the 1 week, 2 week and 3 week marks (these are the “signs of life,” “tech demo,” and “play test” milestones).
- Risks
- What are the biggest unknowns or risks facing the project that jepordize its chances of success?
You might also want to work out block diagrams, module specifications, concept sketches, … – basically, the more thinking you do about what your project will be and how you will do it, the more likely you are to make good progress. Please include as much of these details as you can.
At this point, the key is to have a plausible plan. One that, if followed, would lead to the right outcomes. We want to make sure that there is at least one path to success, and that you know it. If you end up changing the plan and succeeding in a different way, that’s OK.
As the project proceeds, make sure that you consult your plan. If you are making major departures from it, please let the instructor and TA know. For example, we don’t want you to scale back your project too much (so that it isn’t interesting), or if you’re really stumbling on something, maybe we will have some ideas.
Please send the document in some convenient form to the Professor and TA by email, before 9am on Friday, November 11th.
Here are some previous examples of plans. Note: in the past there was more of an emphasis on critiques, some game engines were more or less popular (there was a phase when everyone was building games in Irlicht), …
- http://graphics.cs.wisc.edu/Courses/Games10/wp/tags/game-plan/
- http://www.cs.wisc.edu/graphics/Courses/679-s2008/GameProject/Examples (list of stuff from 2007 – has examples of all phases, unfortunately just 2 plans)
- I can’t find the 2008 plans, or other 2007 plans
Comments on this entry are closed.
{ 1 trackback }