Computer Science 121 - Project Phase 1

Project Phase 1 Deliverables

Project Description

1. Project Overview
2. Project Component Description
3. Grading
4. Rules and Submission

1. Introduction

During this semester you will design and develop an educational computer game for one of our clients:

1. Heidi Ellis and Greg Orr, Hillside Middle School in Kalamazoo, Michigan.
2. Leslie Wallace, Sycamore Middle School, Claremont, CA
3. Michelle Townsley, Rio del Valle Middle School, Oxnard, CA
4. Pantera Elementary School, Pomona, CA
5. Simons Middle School, Pomona, CA
6. Marshall Middle School, Pomona, CA

2. Description of Project Components

2.1 Management Plan

A Management Plan is a living document that describes your plans and progress over the course of the project. This document will reside on your trac page using a prescribed template. This document provides information on the team and links all work products you produce. In addition it links notes from your weekly meeting, which should at least address the following:

1. When and where the meeting took place and who was in attendance (you should explain any absences). Who was scribe for the meeting.
2. Postmortem on previous week:
   What went right and what went wrong during the week? Did you achieve the goals you had set out? If not, why? How good were your predictions on how long goals would take to achieve? What problems did you encounter? What can you do to avoid similar problems in the future?
3. Reassessment of goals:
   What are the remaining goals for the current phase? What are the major risks and how can you mitigate those risks? Are remaining goals prioritized, particularly with respect to risk? Are high priority goals well defined with concrete outcomes that can be achieved in less than 3 hours of work? (If not, you should clarify the goals.) How long will each high priority goal take to achieve?
4. Plan for the week:
   Which high priority goals "must" be achieved this week? Which ones "should" be achieved? Who is responsible for each goal? Are there dependencies between goals; i.e. goal A must be reached before goal B can be started. Each week you will write a blog entry to update the customer/users on your progress. Be sure to compose this in appropriate language (avoid technical details and jargon). You should also post any questions you have. (Some questions may not be appropriate for the blog; e.g. clarification on student aptitude. You should email these questions to the teacher but please cc the instructors as well.)

   Finally, each week you will determine the percentage contribution of each team member for each deliverable due that week. You should update the deliverables table accordingly.

   Your management plan will be graded as follows:
   • (20 pts) initial set up due at end of day 9/1
   • (20 pts) for each weekly update due at the end of the day 9/6, 9/13, and 9/20.
   (The 9/20 update should include a post mortem for the entire phase 1.)

   2.2 Competitive Analysis

   The objective of a competitive analysis is to identify competitors to your product and to identify their strengths and weaknesses. This analysis allows you to identify key design goals for your product. For this project, you will identify games that target similar objectives/audience to yours then analyze their effectiveness. Some questions you want to ask about each game are:

   1. What is fun about this game? What is not?
   2. Is the genre/interface/mechanics/difficulty particularly appropriate to the game's learning objectives? How successful is it in achieving its objectives? Why does it succeed? Why does it fail?
   3. Does the game appeal to all members of your audience or are there gender/cultural/game-experience biases?
   4. How appropriate is the game for classroom use? What technical/logistical requirements are imposed?
   Once you complete this study, you will construct a list of the 5-8 most important design objectives for your game. Rationalize your choices and discuss their relative importance. Describe how you would assess whether your game, when completed, meets each of these objectives.

   2.3 High concept

   The high concept document should be a 3-5 page pdf that describes your concept including the following key components:

   1. High Concept Statement: Working game title, team members, and a 100-200 word description of the game
   2. Features: Bulleted list of important features (prioritized)
   3. Competitive summary: Summary of your competitive analysis and positioning of your concept against this field
   4. Overview: Player motivation, genre, target customer, hardware platform options, suitability for learning objective, major risks, unique selling points, design goals, concept art
   5. Pedagogical strength: What the player will learn, why the game will be effective
   6. Other: Info you think is important
   Here is an example high concept for the game Death Wish. You can find others on the web by googling "High Concept Document." Note: These samples are not focused on educational games; it is important that you address the suitability of your concept for the learning objective.

We urge you to spend some time exploring game concepts before settling on one. For guidance we suggest you read about the Experimental Gameplay Project at CMU's Entertainment Technology Center.

2.4 Customer Requirements Elicitation

The customer requirements elicitation process involves preparation, a meeting with the clients, and a follow up report. The objective is the identify, clarify, and prioritize the customers' requirement. In preparation for this meeting you will prepare:

• A 3-5 slide presentation of your concept.
• A list of open-ended questions about the educational goals, classroom environment, student capabilities and interests, how the game will fit into the curriculum, etc. The point of these questions is to reveal requirements that you have not forseen.
• A list of requirements you've determined ahead of time (e.g. your prioritized design objectives from the competitive analysis) and any questions you need to clarify/validate them.
The ~30 minute meeting with the clients should be formatted as follows.
1. Briefly introduce yourselves and the agenda
2. Give your concept presentation
3. Engage the customers in a discussion of their needs starting with your open-ended questions.
4. Follow up on interesting points raised in the open-ended questions, pose your questions on previously identified requirements, and discuss priorities.
5. Present a summary of the key messages you have gotten and give them the opportunity to confirm or correct your impressions.
6. Thank them for their participation.

Team roles:

• Moderator: Leads the meeting, discussions, etc.
• Scribe: Takes notes
• Others:
  The moderator and scribe will typically be too busy to actually think about what is being said in real time. Other team members should
  • Distill long discussions into punch-lines for the summary.
  • Keep track of points that need further clarification.
  • Check off comments that relate to previously identified requirements, and maintain a list of requirements that still require validation.
  • Watch the clock, help the moderator keep to the agenda, and make sure that nothing is missed.

From the detailed minutes (which should be checked into subversion) the scribe should prepare a summary report that synthesizes the information gathered. The report should include:

1. When and where the session took place and who attended.
2. Interesting information gained during the open-ended information gathering.
3. Clear statements of significant new requirements that were suggested, along with an assessment of how important each is and why.
4. Significant input on previously gathered requirements, affirming, refuting, changing, and/or prioritizing them.
5. Any other useful results gained from the meeting.

2.5 Technology Assessment

It is important that the concept you develop satisfy the customers' needs. It is equally important that the proposed game be feasible as a semester-long project. To address feasibility you must identify the tools and technologies you will use to develop the game. The Technology Assessment is the first step in this process. You will research a range of options from building your game entirely from scratch to developing a mod of an existing game. In the process you must evaluate whether each approach is suitable for your game concept and for your teams' knowledge and skills. Finally you will prioritize the approaches, identifying those that are promising and those that are not. For those that are promising you will identify the key risks and a plan of how those risks could be mitigated. Your analysis and conclusions will be documented in an Technological Assessment Report.

2.6 Use Cases

Your high concept provides a quick look at your proposed game. Use cases (and/or storyboards, etc.) allow you to provide more detail. You should identify all major use cases for your game and elaborate the ones you deem most important. Through the uses cases (and optional storyboards) you will describe the major features you'll support as well as concrete details about gameplay (at least 10 minutes). Your use cases should identify the underlying models you'll use (e.g. physical models, scoring, etc.).

2.7 Prototype

You will develop one or more prototypes to satisfy two main goals:

1. Make concrete your vision of the game for the customer (and yourselves)
2. Resolve key risks (primarily technological)
You may achieve these goals with a single prototype or you may choose to create a few smaller prototypes, each focusing on a specific goal. For each prototype you should provide a brief write up explaining the objectives of the prototype, instructions for running it, and the lessons you learned from its development.

2.8 Proposal

You will produce an 8-10 page pdf document that describes

• Background and problem (learning objective)
• Requirements analysis (prioritized functional and non-functional)
• Game design
• Development plan (technology and risk assessment)
Note, the proposal should summarize material from previous work products; e.g. tech assessment, customer elicitation report. You should, however, take this opportunity to correct any defects identified by the grutors when grading these materials.

This proposal will be evaluated according to this rubric.

2.9 Game treatment

You will produce a 2 page pdf document that describes your game for the middle school students. This document is the first opportunity you have to describe your game to them and you should be sure it is understandable and exciting. The middle school students will provide feedback that you can use to help shape your game.

3. Grading

This phase of the project is worth a total of 500 points. Rubrics for each work project are provided here. For each component, the team will assign a percentage to each team member based on their contributions to the component (the percentages should, of course, add up to 100%). These percentages should be posted to the deliverables table. Grades for each team member will be based on a contribution weighted average of earned points for the components. The resulting score will be normalized based on team size and overall scope of project. It is expected that a team of size 5 will produce a project with larger scope than a team of size 4! It is your job to choose an appropriate scope to your project.

4. Rules and Submissions

Your trac should include deliverables table that includes for each deliverable its due date, actual submissions date (you should fill this in), total point value, percentage grade distribution to team members (you should fill this in), link to a separate wiki page that documents your progress/process on the deliverable (if needed), and a link to your actual submission.

Each team is entitled to two late days that can be applied to any phase 1 deadline except those involving in-class scheduled events (e.g. Customer Elicitation). A late submission that is not redeemed with late days loses ten percent of its value for each day missed.