Major Deliverables | Dates | Component | Points |
---|---|---|---|
Management Plan (120 pts) | 9-22, 9-27, 10-4, 10-11, 10-25 | Weekly updates | 20 each |
Architectural Design (140 pts) | 9-27 | First Architectural Design Draft | 30 |
10-4 | Second Architectural Design Draft | 30 | |
10-6 | Architectural Design Review Package | 20 | |
10-11 | Design Review | 40 | |
10-20 | Final Architecture | 20 | |
UI Design (100 pts) | 10-4 | Initial UI Design | 40 |
10-4 | User test | 40 | |
10-11 | Final UI Design | 20 | |
Testing (100 pts) | 10-11 | Test Plan | 40 |
10-20, 10-25 | Test plan implementation (2 stages) | 30 each | |
Prototypes/Code development (90 pts) | 9-27, 10-4, 10-11 | Executable | 30 each |
Alpha release (100 pts) | 10-25 | Executable | 60 |
10-27 | Class presentation | 20 | |
10-27 | Documentation | 20 |
In phase 1 you developed your game concept. In phase 2 you'll develop an alpha release, which is a small, playable game that will be tested in the classroom. The alpha release will be a scaled down version of your final game, but one that provides a good representation of the gameplay experience. In terms of implementation, the alpha release should include a stable architecture and user interface. It is up to you to define your alpha release then carry out its planning, design, construction, and testing.
For phase 2, you will be working both top-down and bottom-up to produce an alpha release. It is up to you to define your alpha but it is important that it incorporate core architecture and provide a playable experience. The top-down efforts include architecture, UI, and test plan designs and reviews. The bottom up efforts are primarily prototypes and it is your job to define these well, based on risk assessment, to ensure your alpha can be completed on time.
As you plan this phase of the project you will define your alpha (through use cases) as well as the weekly prototypes you'll develop throughout the phase. The prototypes may be defined through uses case (prototypes that will evolve to your alpha) but may also represent proofs of concept to help ameliorate project risks. Your initial goal stack will consist of the uses case and proofs of concept you identify as well as the other deliverable described throughout this document. As usual, goals should be prioritized based on risk and those near the top of the stack should be well defined; by well defined we mean that they should be broken down into tasks that take no more than 2-3 hours. Note that many of the deliverables of phase 2 may take more than a week of effort, so be sure to plan ahead.
In this phase you should issue tickets for work assignments. Each team member should also keep a work log where they document the work they do, when they do it, and how long it takes. One of the goals of the third phase of the project is to develop your skill at developing time estimates; the logs you keep in phase 2 will be important for that effort.
You should have (at least) weekly meetings and post meeting notes (as described for Phase 1). The final meeting of this phase should be used to perform a postmortem on the phase.
This deliverables table trac template should be used for phase 2.
A major component of the phase 2 work is development of your software architecture. You will develop a design,
the design will be reviewed by another team, and then you'll revise the design based on review recommendations. The core architecture should be
implemented in the alpha release.
2.2.1 First Architectural Design Draft
Your initial draft design will include:
Your revised draft design should address issues raised in your analysis. You should also extend your design to include
Your design will be evaluated according to this rubric.
The revised draft of your architecture will be reviewed by another team using this rubric. You will prepare an architectural review package that includes the following:
You will review another team's architectural design with the goal of answering the following questions:
You will design the user interface of your game (not the just the alpha release), user test it, then revise the design based on the test.
2.3.1 Initial UI Design
You will develop a preliminary UI design using whatever technology you deem best (e.g. paper, electronic wireframes, etc.) If you use paper you
need to scan it so you can upload it to your trac. You will critique the design in terms of usability principles.
Your design will be evaluated according to this rubric.
You will develop a test plan that includes unit, component (class or collection of classes), and integration tests. You will use test-driven development; that is you will devise tests for your code before you implement, then use the tests to evaluate the implementation. You will also use regression testing; that is a suite of tests your code must pass every time you update the repository. Your test should include the following:
Once your test plan is finalized you should begin implementation. Tests should be developed in parallel with new code. In addition, you should implement your plan for any completed code that will be in your alpha release. You can do this over two weeks as you see fit.
You will plan and implement one or more prototypes, proofs of concept, or extensions to existing code every week. The choice of what to focus on should be based on risk analysis. You will document your goals at the start of each week an assess your results at the end. (This should be part of your meeting notes.) You should link executables along with README files (indentifying the purpose and instruction on running the executable) to your trac.
Your alpha release deliverable will include the game executable and installation/execution instructions. Note, your executable should not rely on any pre-installed software. (For example, if you are building in pygame you need to compile your source into an executable.) You will also give an in-class presentation and demo.
Documenting your design, tests, and code should be an ongoing process across Phase 2. When the alpha release is complete you should provide a wiki document that provides a roadmap to the various forms of documentation including:
Your wiki should include deliverables table that includes for each deliverable (as appropriate) its due date, possible point value, percentage grade distribution to team members, grade earned (to be filled in by our grutors), late days used, link to a separate wiki page that documents your progress/process on the deliverable, and a link to your actual submission.
Each team is entitled to four late days that can be applied to any phase 2 deadline except those involving in-class scheduled events (e.g. review packages or reviews). A late submission that is not redeemed with late days loses ten percent of its value for each day missed. Note that a late day is only good for one deliverable, subsequent delays require additional slip days. For example, if a prototype is one day late, and that delays the final report by a day, you need to use two late days in order to avoid penalties.You should apportion responsibility for each late day to team members. In the previous case, if one person was responsible for missing the prototype deadlines, both late days should be attributed to that person.