Project 3: Proposals

by Mike Gleicher on October 21, 2011

Due Wednesday, 11/2 before class.
Note: this deadline is important since you need to post your proposal early enough that other people can look at it.

Also, note that you’ll have to give a 3-5 minute “pitch” in class.

What is it?

Basically, you will come up for an idea for a game to build for the project in this class. These proposals will be presented publicly to class  and then teams will pick from the proposals. The game you propose might be built by your group, it might be built by another group, or it might not get built at all.

Think about the proposal this way: you are trying to sell your idea to your project team. You need to let them know what the idea is, convince them that it would be a good game (if it gets built), and give some idea that it will be possible to build it.

This assignment is to be done with an assigned partner. Note: you and your partner will not be on the same project team. This means that for every project that is built, there is a designer who is not part of the team who can check to make sure that the team stays true enough to the original design.

Note that there are two parts to this: (1) a written document and (2) the in-class pitch.

1. About the Game

You can basically propose any game you want. There are some Rules that you need to follow. But the key constraint is that it needs to be a game that can be built in the context of this project. For this reason, I strongly encourage you to review both the Rules, as well as the overall instructions for the project.

In your proposal, you will need to consider both the “design” aspects of the game (what is the game, what will make it fun), and (to some degree) the implementation aspects of the game (not the details, which will be left to the team, but a basic idea that shows why you think its feasible to build the game in the limited time and resources of the class project).

2. About the Proposal

The initial game design document must cover the following points:

Name
Your Game must have a descriptive name
Brief Description
A paragraph or two (tops) giving the basic idea
Detailed Description
A longer description, describing the gameplay, the look and feel of the game, …
Scalability Plan
A discussion of how the design can be “scaled” – what is the simplest possible version, what features could be added if there was enough time
Game Principles Discussion
A discussion of what game design principles should be employed in order to make sure the game is fun
Design Challenges
(closely related to the Game Principles discussion) What challenges face the team building the game in terms of making sure the game is fun? Especially in light of the scalability issue (that the team won’t have much time for implementation)
Technical Overview
A brief discussion of how you imagine this game being built. What challenges will the team overcome? Do you have ideas as to how the implementation should be done. We don’t need details here, just the basic ideas that explain why it should be practical to build it.
Technical Challenges
A brief discussion of what challenges will face the team that tries to build the game. This cuts both ways: the game must be sufficiently challenging, but not too challenging. Having contingencies to “hedge” against not being able to address the challenges is good (see “Scalability” above).

You don’t need to have too much detail – just enough to convince people. Also, in terms of grading, you need to show that you’ve thought through the issues.

3. Turning it in

Please send a PDF (preferred) or a word document (not preferred, because we’ll just convert it to PDF) to the instructor and the TA before class on Wednesday, 11/2. We will post these to the web shortly after class. The pitches will be posted in a place where only people with CS accounts can access it. (we have no way to restrict it just to the class).

In previous years, we required students to critique everyone else’s design. We’re skipping that part this year, because of the timing of Project 2. It’s unfortunate, since it was a valuable exercise. Hopefully, you will at least look at all of the designs so you’re ready to decide which one you want to build when you are assigned to a team.

4. Examples

Examples from the past are useful both for game ideas, as well as to see how people wrote stuff up. You’ll see good examples and not-so-good examples. (most of the game ideas are pretty good – too bad only a few get built).

Comments on this entry are closed.

{ 2 trackbacks }

Previous post:

Next post: