CS 121 -- Fall 2012

Phase 1 - Concept Development

1. Project Overview

During this semester you will be part of a team that will design and develop an educational computer game for one of our clients:

Leslie Wallace, Sycamore Middle School, Claremont, CA
Michelle Townsley, Rio del Valle Middle School, Oxnard, CA
Robyn Herbig, Chiefess Kamakahelei Middle School, Hawaii
Nikki Chiba, Chiefess Kamakahelei Middle School, Hawaii
The class will be divided into project teams of ~4 students. In the first phase of the CS 121 project, each team will develop an educational game concept targeted at one or more student learning objectives that were provided by our clients, the teachers. The primary goal of this phase is to give you real experience with the development of a product concept; the gathering, organizing, and prioritizing of requirements; and the development of a proposal for a software product. Secondary goals include developing your abilities to intelligently plan a group endeavor, effectively manage it, and critically evaluate the completed effort. Phase 1: Concept Development Deliverables

Date Due Description Points

See Management Plan and Documentation 5, weekly

Customer Communication 5, weekly

Calendar Competitive Analysis 10

for High Concept 10

Specific Customer Requirements Elicitation 10

Due Technology Assessment 10

Dates Game Treatment 10

Use Cases 10

Prototype 20

Proposal 20

Total 150

The remainder of the document is organized as follows:

3. Project Component Descriptions & Deliverables
4. Grading
5. Rules and Submission

3. Description of Phase 1 Components and Deliverables

Date Due	Description	Points
See	Management Plan and Documentation	5, weekly
	Customer Communication	5, weekly
Calendar	Competitive Analysis	10
for	High Concept	10
Specific	Customer Requirements Elicitation	10
Due	Technology Assessment	10
Dates	Game Treatment	10
	Use Cases	10
	Prototype	20
	Proposal	20
Total		150

3.1 Management Plan Document

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. For details on what we mean by a management plan see Management Plan. This document provides information on the team and links all work products you produce. Your management plan will be graded using a Management Plan Rubric. (The final phase 1 management plan update should include a post mortem for the entire Phase 1.)

Communication with your customer is imperative in developing software. Each team will set up a blog with their teacher. This blog will be updated at least bi-weekly. The idea is to keep the teacher informed. In a perfect world, the teacher would respond to each blog post, but alas that does not happen in practice. But, it is important that you communicate weekly to your customer!!

3.2 Competitive Analysis Document

The objective of a competitive analysis is to identify competitors to your product and to identify their strengths and weaknesses. This analysis helps you to identify key design goals for your product. For this project your competitors are games that target similar objectives/audience to yours. You need to analyze the effectiveness of these games. Games Network is the collection of games produced and finalized from previous semesters. Manga High is a commercial K12 game developer.

Some questions you might 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 construct a list (5-8) of the 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 reside on your Trac and will be graded using the Competitive Analysis Rubric.

3.3 High Concept Document

The term high concept is meant to convey something more formal than a back of the envelope idea, but less formal than a fully developed game concept. It is meant to convey to your customer your first response to their requirements, i.e., a response to a particular learning objective. It is important to note that your customer is NOT coming with an idea, but only an educational requirement. Your concept may (most likely) will change after talking to your client, but the process of developing the concept will assist the formulation of questions that you need to ask when determining the requirements. It is done so quickly because the elicitation happens so quickly, and the semester is so short. The high concept document should be a 3-5 page document (pdf) that describes your concept including the following key components:

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

Here is an example high concept for the game Death Wish and Danger! Danger! Demon Dorthy . You can find others on the web by googling "High Concept Document." Note: Most of these samples are not focused on educational games; it is important that you address the suitability of your game 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.

Your High Concept Document will reside on your Trac and will be graded using the High Concept Rubric.

3.4 Customer Requirements Elicitation

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

A 3-5 slide presentation of your concept.
A list of open-ended questions about the educational goals, classroom environment (e.g., computers), 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 foreseen, or were not available in the school overview.
A list of requirements you have determined ahead of time (e.g., your prioritized design objectives from the competitive analysis) and any questions you need to clarify/validate them.

3.4.1 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.2 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.

Your Elicitation Report will reside on your Trac and will be graded using the Elicitation Rubric.

3.5 Game treatment

Your other users are the middle school students. You will produce a 2 page (pdf) document that describes your game for the middle school students. The language should be appropriate for middle school students, and should use correct grammar and spelling. This document is the first opportunity you have to describe your game to the students and you should be sure it is understandable and exciting, e.g., colorful concept art. The middle school students will provide feedback as follows:

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

Your Game Treatment will reside on your Trac and will be graded using the Game Treatment Rubric.

3.6 Technology Assessment

It is important that the game 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 be familiar with the tools and technologies you will use to develop the game. We have provided some limitations in tool choices, but there is still much for you to know and evaluate. 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 modification 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 identifying your choices and identify the key risks associated with your game and your tools. Your analysis and conclusions will be documented in an Technological Assessment Report.

Your Technology Assessment will reside on your Trac and will be graded using the Technology Assessment Rubric.

3.7 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 Use Cases (and optional storyboards) you will describe the major features you will 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 reside on your Trac and will be graded using the Use Cases 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 provide a brief write up explaining such concepts as: the objectives of the prototype, instructions for running the prototype, and the lessons you learned from its development. The prototype is where you can test your ideas and evaluate risks. For each prototype you should prepare a report as described here.. Basically, this report summarizes who, what, why, where, as far as a prototype. The report should be easily accessible on your Trac. The focus of the prototype is your choice. It is meant to answer your questions. While PyGame is the obvious implementation choice, you may decide to do something different, e.g., a particular physics engine.

Your Prototype Report and your prototype will reside on your Trac and will be graded using the Prototype Rubric.

3.9 Proposal

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

Abstract
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. We will do two evaluations. On the first due date, each team will evaluate another team's proposal. You may use this evaluation to make changes for the final proposal which is due on the second due date. This final proposal will be graded using this rubric. and you will forward the final proposal to your customer.

4. Grading

I am not going to rehash grading here. Check out: grading.

5. Rules and Submissions

Your Trac should have a deliverables table that includes for each deliverable its due date, actual submissions date (you should fill this in), a link to a separate wiki page that documents your progress/process on the deliverable (if needed), and links to your actual submissions.

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.

Mike Erlinger

Last Modified Tuesday, 09-Oct-2012 13:43:42 PDT