Computer Science 121 - Project Phase 1

Concept Development

Spring 2010

Project Phase 1 Deliverables

Date Description Points
1-25 Competitive analysis 20
1-25 High concept 20
1-25 Management Plan 15
2-1 Customer Requirements Elicitation 20
2-1 Technology Assessment 20
2-8 Game Design Document (GDD) 40
2-15 Prototype 40
2-15 Proposal 20
2-17Post 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 a computer game concept for our clients, Greg Orr and Joshua Yavor, who teach 6th grade social science at Hillside Middle School in the Kalamazoo, Michigan. The class will be divided into teams of 4-5 students. In this 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 customer.

  1. Explain and use a variety of maps, globes and web based geography technology to study the world, including interregional, regional and local scales.
  2. Describe the importance of the natural environment in the development of agricultural settlements in different locations (e.g. available water for irrigation, adequate precipitation and suitable growing season).
  3. Explain the impact of the Agricultural Revolution (stable food supply, surplus, population growth, trade, division of labor, development of settlements).
  4. Describe ways the physical environment is modified by human activities, and how those actions are influenced by the values societies place on the Earth’s natural resources, physical features, and processes (e.g. changes in the tropical forest environments of Brazil, Peru and Costa Rica).
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 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 these objectives.

This report will be graded on:

2.2 High concept

This is a 3-5 pdf document 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.

This document 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.3 Management Plan

A Management Plan is a living document that describes your plans and progress over the course of the project. Your initial version is due 1-25.

The plan should include a goal breakdown, the dependency relationships between tasks, owners for each task, and deadlines. The plan should also specify times for weekly meetings to review progress, analyze risk, adapt your plans to deal with problems, and clarify current resposibilities (issue tickets). The wiki should link meeting notes that summarize discussions.

Your management plan will be graded on

Advice:

A good plan will ensure that all work is done before the due date, but allow people a reasonable amount of slack in when they have to do each particular task. An overly aggressive plan that people won't be able to achieve is no better than a realistic plan that misses deadlines.

Vague plans are easier to create initially but lead to problems if not clarified. You should always be explicit about near term milestone by describing concrete and measurable outcomes and clearly identifying responsibilities.

2.4 Customer Requirements Elicitation

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

The ~30 minute meeting with the client should be formatted as follows.
  1. Briefly introduce yourselves and the agenda
  2. Give your concept presentation
  3. Engage the customer in a discussion of his 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 him the opportunity to confirm our correct your impressions.
  6. Thank him for his participation.

Team roles:

From the detailed minutes (which should be checked in to 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 customer's 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 Game Design Document (GDD)

A Game Design Document -- or "Game Bible" -- describes all aspects of your game. In iterative game design, this is an evolving document that begins with the basics of your high concept and ends as a description of your final game. The objective at this point is to make concrete your vision of the game in a way that is understandable to all stakeholders.

You should decide on a format appropriate for your game but here are two sample templates you can use for guidance: Baldwin GDD and Taylor GDD. These samples do not explicitly mention bottom-up techniques like uses case, you will use them to clearly articulate at least 10 minutes of gameplay.

In this phase of the project your GDD should include the overarching themes, characters, gameplay mechanics, look and feel, major features, and important use cases. In addition you should elaborate at least 10 minutes of gameplay through use cases (or other means you deem appropriate). Finally, the GDD should be a hyperlinked document on your wiki page.

Your GDD will be graded as follows:

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

Your prototypes will be evaluated on the following:

2.8 Final Proposal

Your final proposal should summarize your prior work, the conclusions that work has led to, and a plan for moving forward.

  1. A brief description of your game and links to your GDD and prototypes
  2. A discussion of requirements, links to your eliciation report, and a rationale as to how your game will meet those requirements
  3. A discussion of feasibility including links to your technology assessment, a rationale for your choice of tools/technologies, and proposed roles for each team member.
  4. A proposed development plan that includes weekly milestones based on a risk analysis. Your weekly milestones will typically include proofs of concepts (to demonstrate a technical competency in order to resolve a risk) or a game prototype. Your development plan should articulare the features and capabilities of each game prototypes (at least the early ones).
Your proposal will be graded on

2.9 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 main wiki page should include a table of phase 1 milestones, the date they were completed, links to the associated deliverables, and an accounting of late days.

Each team is entitled to three late days. 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.