Computer Science 121 - Project Phase 1

Concept Development

Spring 2011

Project Phase 1 Deliverables

Date Description Points
  Management Plan 20
1-25 Competitive analysis 20
1-25 High concept 20
1-27 Customer Requirements Elicitation 20
2-1 Technology Assessment 20
2-1 Use Cases 20
2-1 Risk Analysis Report 20
2-8 Prototype 20
2-8 Proposal 35
2-10Post Mortem 5


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 our clients, Heidi Ellis, Greg Orr, and Joshua Yavor, who teach 6th and 7th grade social science and language arts at Hillside Middle School in Kalamazoo, Michigan. The class will be divided into teams of 3-5 students. In the first phase of the project, each team will develop an educational game concept targeted at one or more of the following student learning objectives, which were provided by our customers.

  1. Human geography: Explain how forces of conflict and cooperation among people influence the division of the Earth’s surface and its resources. Or, more concretely, choose one of the following:
    1. (G4.4.1) Identify factors that contribute to conflict and cooperation between and among cultural groups (control/use of natural resources, power, wealth, and cultural diversity).
    2. (G4.4.2) Describe the cultural class of First Peoples, French and English in Canada long ago and the establishment of Nunavut in 1999. Or, more generally explore the clash of migrating peoples with natives.
  2. Migration: Investigate the significance of migrations of peoples and the resulting benefits and challenges. Or, more concretely, choose one of the following:
    1. (G4.3.1) Identify places in the Western Hemisphere that have been modified to be suitable for settlement by describing the modifications that were necessary (e.g., Vancouver in Canada; irrigated agriculture; or clearing of forests for farmland). Or, more generally, describe ways the environment might be modified in order to support settlement.
    2. (G5.2.1) Describe the effects that a change in the physical environment could have on human activities and the choices people would have to make in adjusting to the change (e.g., drought in northern Mexico, disappearance of forest vegetation in the Amazon, natural hazards and disasters from volcanic eruptions in Central America and the Caribbean and earthquakes in Mexico City and Colombia)
  3. Geography: (G1.1.1) Explain and use a variety of maps, globes and web based geography technology to study the world, including interregional, regional and local scales.
  4. Economics: Describe patterns and networks of economic interdependence, including trade. Or, more concretely, choose one of the following:
    1. (G4.2.1) List and describe the advantages and disadvantages of different technologies used to move people, products, and ideas throughout the world (e.g., call centers in the Eastern Hemisphere that service the Western Hemisphere; the United States and Canada as hubs for the Internet; transport of people and perishable products; and the spread of individuals’ ideas as voice and image messages on electronic networks such as the Internet.)
    2. (E3.1.2) Diagram or map the movement of a consumer product from where it is manufactured to where it is sold to demonstrate the flow of materials, labor, and capital (e.g., global supply chain for computers, athletic shoes, and clothing). (Possibly includes effects of policy decisions.)
  5. History: Analyze classical civilizations and empires and their lasting impact on institutions, political thought, structures, technology and art forms that grew in India, China, the Mediterranean basin, Africa, and Southwest and Central Asia during this era. Or, more concretely, describe how trade integrated cultures and influenced the economy within empires (e.g., Assyrian and Persian trade networks or networks of Egypt and Nubia/Kush; or Phoenician and Greek networks.
  6. Government: Describe Civic Life, Politics, and Government and explain their relationships. Or, more concretely, (C1.1.1) Analyze competing ideas about the purposes government should serve in a democracy and in a dictatorship (e.g., protecting individual rights, promoting the common good, providing economic security, molding the character of citizens, or promoting a particular religion).

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. A secondary goal is to develop your abilities to intelligently plan a group endeavor, effectively manage it, and critically evaluate the completed effort.

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. For phase 1, the deliverables and deadlines have been specified for you so all you need do is document your process and product on your track wiki. You should include, at least, the following:

Your management plan will be graded on clarity and completeness

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.

This report will be graded on:

2.3 High concept

This deliverable involves is 3-5 page pdf document and a game box prototype. The high concept document 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.

In addition to the high concept document you must prototype the face and back of your game box. (This will be evaluated by Hillside Middle School students.)

This document/game box prototype will be graded on:

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:

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:

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.

This elicitation will be graded as follows

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. This report will be graded on the basis of:

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.). Your use cases will be graded on

2.7 Risk Analysis Report

Risk analysis will be a regular part of your project. In this particular deliverable, however, we ask you to identify the major risks to your project as it stands when your customer elicitation, technological assessment, and use cases are complete. Once identified you should prioritize them and take steps to mitigate them. Mitigation may involve producing prototypes, revising your vision of the game (use cases, etc.), extending your technology review, seeking clarification of issues from the customer, or simply indentifying a plan of attack and back up plan in the event your plan fails.

In addition you will send an email to the customers (cc z, mike, and your grutors) describing your biggest risk, explaining why you think it is your biggest risk, and describing your plans to mitigate it. Your explanation should be in terms a lay person can understand.

Your report should document your risk analaysis process and will be evaluated on

2.8 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 any lessons learned from its development.

Your prototypes will be evaluated on the following:

2.9 Proposal

This 8-10 page pdf document should describe your game, its requirements, and a preliminary plan for its development. Your proposal will be evaluated according to this rubric with points awarded as follows:

3.0 Postmortem

This project is a learning exercise, and one of the major ways we learn is by analyzing past mistakes. You will, as a team, review all aspects of this phase of the project then summarize that process into a post-mortem analysis report. It should specifically address each component of the phase.

You will be graded on the basis of:

3. Grading

This phase of the project is worth a total of 200 points. 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%). 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 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 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. 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.