CS 121 -- Fall 2012

In Phase I you developed your game concept. In Phase 2 you will 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 a reasonable user interface. It is up to you to define your Alpha release then carry out its planning, design, construction, and testing. key points are: to promise less and deliver more and Alpha should focus on what will work.

2. Summary of Phase 2 deliverables
3. Description of Phase 2 deliverables
4. Submission
5. Grading

2. Summary of Phase 2 deliverables

3.1 Management

Management updates will continue through Phase 2 as described here.

3.2 Architecture

A major component of Phase 2 is the design and development of your software architecture. You will develop an architectural design, the design will be reviewed by another team, and then you will revise the design based on review recommendations. The core architecture should be implemented in the Alpha release.

3.2.1 Initial Architecture

Your architectural design is a (hyperlinked wiki) document that explains what your architecture does and how it does it. The design should include the following:

1. Use Cases the architecture will realize (these will typically be the "must have" Use Cases for your Alpha release)
2. Domain diagrams based on your Use Cases
3. Class diagrams identifying major responsibilities and collaborations for each class
4. Description of important models/algorithms/data structures and their parameters (e.g. scoring algorithms and simulation models). Also, describe any code that you might be reusing.
5. Sequence diagrams illustrating how the classes collaborate to realize the Use Cases
6. A critique of the design with respect to good design principles
7. A rationale for your choices

Your architecture will be reviewed by another team. You will prepare an architectural review package (a hyperlinked wiki document) that includes the following:

1. Table of contents
2. Introduction
3. Agenda for the review
4. Recommendation for how the review should be split up among four reviewers
5. A roadmap to the various architectural design documents (with links to the actual components) for each aspect of the review
6. A critique of the architecture including strengths, weakness, and a ratioanale for key decisions
7. Where/how to access additional information (e.g. prototypes, proposal)

You will review ANOTHER team's architectural design with the goal of answering the following questions:

• Will it be able to meet the project requirements?
• Does it satisfy good design principles?
• Is it feasible?

3.3 UI Design

During this phase, uou will design the user interface(UI) of your game (not the just the Alpha release) based on task analysis. You will user-test the design on your classmates and grutors, then revise the design based on test results. Hopefully we can test UIs with one of the schools.

3.3.1 Task analysis

You will perform a task analysis of your game. This should include:

1. The hierarchy of goals the player confronts in your game. Low-level goals will typically change across time so focus at the start of your game. See Will Wright 13:30-16:30 on user goals.)
2. Explain how the player comes to understand these goals.
3. For the 2 or 3 most important mid-level goals, describe a sequence of simple tasks the player can complete in order to achieve those goals.
4. For the simple tasks described in the previous step, explain the UI elements the player will use to achieve the tasks.

Your design/test/notes will be evaluated according to the following rubric. Rubrics will be completed by classmate observers during the in-class session. Rubrics will be completed by grutors/faculty during the testing on middle school students.

3.4 Testing

You will develop a test plan, it will be reviewed by another team, and you will revise it based on their recommendations.

3.4.1 Initial Test Plan

Your test plan should includes include a broad range of tests including the following:

1. For each non-trivial method, unit tests that, in particular, test boundary and error conditions.
2. For each component (class or module), identify the areas of high risk (where errors are likely or where they would be difficult to track) and develop component tests.
3. Identify areas of high risk cross-component functionality and devise appropriate integration tests.
4. Identify common game play paths and develop appropriate system tests for them.
5. Develop a regression test suite that is run before new code is to committed to the repository.

• Developing new tests as you develop new code
• Running regression tests
• Producing weekly test reports
• Tracking and fixing bugs

Your test plan will be reviewed by another team. You will prepare a test plan review package (hyperlinked wiki document) that includes

1. Table of contents
2. Introduction
3. Agenda for the review
4. Recommendation for how the review should be split up among four reviewers
5. A roadmap to the various test plan and design documents (with links to the actual components) for each aspect of the review
6. Your critique/rationalization
7. Where/how to access additional information (e.g. architectural design, use cases)

All teams (Reviewers) will review a single team's (Reviewed) test plan design. The Reviewed team will present their test plan and their presentation will be evaluated by the presentation rubric. Each Reviewer team member will be assigned responsibility for some aspect of the reviewed test plan. It is the responsbility of each Reviewer Team to divide up the reviewed test plan into the appropriate number of parts. Each Reviewer should come to the review with an understanding of their portion including its strengths and weaknesses, be prepared to describe it at a high level to the other reviewers, and to lead any discussions about it. Through these discussion, each Reviewed team will agree on an assessment of the reviewed test plan, completing the test plan review rubric and issuing a set of recommendations. The recommendations will be organized into lists of "must do," "should do," and "should consider." Finally, each Reviewer team will decide if the test plan "passes," "passes subject to conditions," or "fails." In the case the test plan fails, the Reviewed Team must correct deficiencies in its design and submit to another review.

3.3 Code/prototypes

Every week you will develop code; this code can be in the form of a prototype that is intended to be thrown away or a program that you will evolve into to your Alpha release. Details on the requirements for this code is given here. Important and non-trivial details about submitting code is given here.

3.4 Alpha Release

Your Alpha release deliverable will include the game executable and installation/execution instructions. Important: your executable submission should follow these guidelines. You will also give an in-class presentation and demo.

1. UML: use cases realized by the Alpha release; class, sequence and other diagrams that provide a snapshop of your architecture and how it works to realize your use cases
2. Tests: results of UI tests and proposed test plan as well as known bugs/issues report
3. Installation/users guide: what do I need to know to run/play your Alpha release
4. Coding conventions used

5. Grading

I am not going to rehash grading here. Check out: grading

4. Rules and Submissions

Deliverables are due as specified in the Calendar. Be sure to read the guidelines for submitting prototypes/code.

Your Trac should have a deliverables table that includes for each deliverable its due date, actual submissions date (you should fill this in), link to a separate wiki page that documents your progress/process on the deliverable (if needed), and links to your actual submissions.

Mike Erlinger