Computer Science 121 - Project Phase II

Alpha design and implementation

1. Overview

In phase I you developed your game concept. In phase II 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.

  1. Summary of phase II deliverables
  2. Description of phase II deliverables
  3. Submission
  4. Grading

2. Summary of phase II deliverables

Major Deliverables Component Points
Management Weekly management updates 5 each
Architecture Inital architecture 15
Architectural design review package 5
Architectural design review 5
Revised architecture 5
UI Design Task Analysis 10
Initial UI 10
UI test 5
Final UI 5
Testing Test Plan 10
Test plan review package 5
Test plan review 5
Final test plan 5
Code Weekly Prototype/Code development 5 each
Alpha release Executable 10
Class presentation 5
Documentation 5


3. Description of phase II deliverables

3.1 Management

Management updates will continue through phase II as described here.

3.2 Architecture

A major component of phase II 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'll 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 the 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)
  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
Since this design will likely evolve over phase II, you will want to construct the document so that it is easy to change; i.e. as a hyperlinked wiki document. (I don't know of a good way to create easily editable online UML diagrams so those may have to be presented as pdfs.)


Your architecture will be evaluated by another team according to this rubric.



3.2.2 Architectural design review package

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 architectures including strengths, weakness, and a ratioanale for key decisions
  7. Where/how to access additional information (e.g. prototypes, proposal)


3.2.3 Architectural design review

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

Each team member will be assigned responsibility for some aspect of the architecture. You should come to the design review with an understanding of your portion, its strengths and weaknesses, be prepared to describe it at a high level to the other reviewers, and to lead a discussions about it. Through these discussion, the review team will agree on an assessment of the architecture, completing the architectural review rubric and issuing a set of recommendations. The recommendations will be organized into lists of "must do," "should do," and "should consider." Finally, the review team will decide if the architecture "passes," "passes subject to conditions," or "fails." In the case the review fails the architecture, the originating team must correct deficiencies in its design and undergo another review.

Individual members of the review teams will be evaluated on her/his preparation, contributions to the discussion, and role in assessing the architecture. The team will aso be evaluated on the quality of its recommendations. For more details, see the review rubric.



3.2.4 Revised architecture

You should respond to the shortcomings in your architecture raised in the review. In particular, you can address a recommendations by revising your architecture or giving a cogent argument as to why the recommendation should be ignored. You should summarize your revisions and arguments in a report that links (as appropriate) to updated design documents. Your final architecture will be evaluated according to this rubric. (This rubric is identical to the one used in the review except it has additional points about how you responded to problems raised in the review.)

3.3 UI Design

You will design the user interface 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.

3.3.1 Task analysis

You'll 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 to 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 task analysis will be evaluated according to the following rubric.


3.3.2 Initial UI Design/Test

You will develop a preliminary UI based on your task analysis and good UI design principles. You may use whatever technology you deem best, e.g. paper, electronic, but the design must be captured in some electronic form (e.g. photo) so it can be uploaded to your wiki. (You might consider this fast UI prototype tool: http://www.foreui.com/.) Your design will be evaluated according to this rubric.

You will test your UI design on your classmates and (hopefully) middle school students. You should devise a test protocol (based on the sample given in class) that reflects the priority established in your task analysis. It should take 20-25 minutes. (You should practice on your teammates before the in-class demonstration.)

During the test you'll work in interviewer/scribe pairs. Scribe notes should be uploaded to your trac.

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.

In addition, you'll do a smaller remote test of the UI on your (non-Sycamore) students by posting (at least) three images of your UI design in your weekly blog post. You'll also construct a survey that includes three questions that the students will answer. These questions should be somewhat open-ended and require about a paragraph to answer. (Don't ask simply yes-no questions.)

3.3.3 Revised UI

Your final design should address issues raised in the user tests. You should also critique your design and discuss its shortcoming. The design and critique will be evaluated according to this rubric.

3.4 Testing

You will develop a test plan, it will be reviewed by another team, and you'll 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.
In addition to your tests, your test plan should explain your protocol for Finally, your test plan should include critique of the weaknesses of your test plan and a rationalization of your choices.


3.4.2 Test plan review package

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)
You should read the following section before deciding how the review will be organized.

3.4.3 Test plan review

You will review another team's test plan design. Each team member will be assigned responsibility for some aspect of the test plan. You should come to the review with an understanding of your portion including its strengths and weaknesses, be prepared to describe it at a high level to the other reviewers, and to lead a discussions about it. Through these discussion, the review team will agree on an assessment of the 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, the review team will decide if the test plan "passes," "passes subject to conditions," or "fails." In the case the test plan fails, the originating team must correct deficiencies in its design and submit to another review.

Individual members of the review teams will be graded on her/his preparation, contributions to the discussion, and role in assessing the test plan. The team will also be evaluated on its recommendations.



3.4.4 Final test plan

You should respond to the shortcomings in your test plan raised in the review. In particular, you can address a recommendations by revising your test or giving a cogent argument as to why the recommendation should be ignored. You should summarize your revisions and arguments in a report that links (as appropriate) to updated test plan documents. Your final test plan will be evaluated according to this rubric. (This rubric is identical to the one used in the review except it has additional points about how you responded to problems raised in the 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.

Documenting your design, tests, and code should be an ongoing process across phase II. When the alpha release is complete you should provide a wiki document that provides a roadmap to the various forms of documentation including:

  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
Your executable and documentation will be evaluated by this rubric rubric. Your presentation will be graded by your peers and the faculty using this rubric.


4. Submissions

Deliverables are due at the start of class time on Tuesday unless otherwise specified. Be sure to read the guidelines for submitting prototypes/code. All other deliverables should be linked from your wiki as specified in the template. You should also specify the percentage contribution of each team member to the deliverable.

Each team is entitled to two late days that can be applied to any phase II deadline except those involving in-class scheduled events (e.g. Architecture Review Package) or work products that are subject to customer/user review (e.g. UI design blog entry). If there is any question about whether a deliverable can be turned in late, be sure to ask ahead of time. A late submission that is not redeemed with late days loses ten percent of its value for each day missed.

5. Grading

Your team will be assigned a letter grade for each work product; these grades will be normalized based on the point value of each work project in order to compute a team grade for Phase II. In addition, individual grades will be determined for each phase based on the team grade, the contribution percentages for the deliverables, your work logs, and peer evaluations. Note that in the case of unevenly sized teams, a team of size 5 is expected to produce a project with larger scope than a team of size 4! It is your job to choose an appropriate scope to your project.