Computer Science 121 - Project Phase I

Concept Development

1. Overview

In the first phase of the project, each team will develop an educational game concept targeted at one or more student learning objectives provided by our clients. The primary goal of this phase of the project is to give you real experience with the development of a concept, the gathering, organizing and prioritizing of requirements, and the development of a proposal for a software product.

The remainder of this document is organized as follows

Summary of phase I deliverables
Description of phase I deliverables
Submissions
Grading

2. Summary of phase I deliverables

Description	Points
Management updates	5 weekly
Competitive analysis	10
High concept	10
Customer requirements elicitation	10
Game treatment	5
Use cases	10
Technology assessment	10
Prototype	15
Proposal	15

3. Description of phase I deliverables

3.1 Management updates

Management updates are required througout the project and are described in a separate document found here.

3.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:

What is fun about this game? What is not?
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?
Does the game appeal to all members of your audience or are there gender/cultural/game-experience biases?
How appropriate is the game for classroom use? What technical/logistical requirements are imposed?

Once you complete this study, you will formulate a prioritized 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.

Your competitive analysis will be evaluated according to the following rubric.

3.3 High concept document

You will develop a game concept to pitch to your client. (Your concept may change after talking to your client, but the process of developing the concept will help you formulate questions you need to ask them in order to determine the project requirements.) The high concept document should be a 3-5 page pdf that describes your concept (or concepts if you have more than one) including the following key components:

High Concept Statement: Working game title, team members, and a 100-200 word description of the game
Features: Bulleted list of important features (prioritized)
Competitive summary: Summary of your competitive analysis and positioning of your concept against this field (In addition to summarizing the results of your competitive analysis you should provide a link to that document.)
Overview: Player motivation, genre, target customer, hardware platform options, suitability for learning objective, major risks, unique selling points, design goals, concept art
Pedagogical strength: What the player will learn, why the game will be effective
Other: Info you think is important

Your high concept will be evaluated according to the following rubric.

3.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. You will be evaluated according to this rubric.

3.4.1 Customer requirements elicitation preparation

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 answered in order to clarify/validate them.

3.4.2 Customer requirements elicitation meeting

The ~30 minute meeting with the clients should be formatted as follows.

Briefly introduce yourselves and the agenda
Give your concept presentation
Engage the customers in a discussion of their needs starting with your open-ended questions.
Follow up on interesting points raised in the open-ended questions, pose your questions on previously identified requirements, and discuss priorities.
Present a summary of the key messages you have gotten and give them the opportunity to confirm or correct your impressions.
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.

3.4.3 Customer requirements elicitation report

From the detailed minutes, the scribe should prepare a summary report that synthesizes the information gathered. The report should include:

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

3.5 Game treatment

The next group you want to get feedback from on your game concept is your users. You will produce a 2 page pdf document that describes your game. The language should be appropriately targeted for middle school students. It should provide a clear description of the game. Needless to say, it should use correct grammar/spelling. It should be fun and exciting (use some colorful concept art). The students will provide feedback as follows:

Do you want to play this game?
What looks like the best thing about it?
What is one question you have for the designers?
What is one suggestion you have for the designers?

Your treatment will be evaluated according to this rubric.

3.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, prioritize them, 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 any underlying models you'll use (e.g. physical models, scoring, etc.).

Your use cases will be evaluated according to the following rubric.

3.7 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. Your report will be evaluated using the following rubric.

3.8 Prototype

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

Make concrete your vision of the game for the customer (and yourselves)
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 prepare a prototype report as described here.

Your rubric will be evaluated according to the following rubric.

3.9 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.

4. Submissions

Deliverables are due at the start of class time on Tuesday unless otherwise specified. You should link deliverables to your wiki where 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 1 deadline except those involving in-class scheduled events (e.g. Customer Elicitation) or work products that are subject to customer/user review (e.g. game treatment). 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 I. 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, larger teams are expected to produce a project with larger scope than smaller teams! It is your job to choose an appropriate scope to your project.