Use these project guidelines to determine the scope of your treatment.

1. Must use GameMaker for your game.
2. Must provide at least 2 minutes of continuous, unique gameplay.
3. Must offer at least 3 meaningful game choices.
4. All dialog must be original.
5. Must utilize at least 12 pieces of art.
6. At least 4 pieces of art must be original.
7. Must utilize at least one piece of music (need not be original).
8. Must utilize at least three sound effects (need not be original).
9. Must include a title screen and a credit screen.
10. Must include at least two global game options.
11. All non-original assets must be credited, either in the game itself or in the accompanying documentation.

Since design documentation is integral to every role in the game development process, it will benefit you greatly to better understand design documents. The purpose of this assignment is to familiarize you with reading and understanding design documents, to stimulate your thinking about how the various aspects of a design relate to each other, to exercise your ability to expand a small idea into a full design, and to improve upon your skills at writing documentation that is meant to be read (and understood) by other people.

As you develop your treatment, consider what you have learned about GameMaker so far, and how comfortable your team is with using it. You will actually be building the prototype you describe in your treatment, so be honest about your abilities and ruthlessly realistic about what you think you can do in just a few weeks!

You are not being graded on the majesty or ambition of your game in this assignment. You are being graded on the clarity and completeness of the presentation. Even a very simple game is okay as long as it is thoroughly described.

The format for your treatment will be an abbreviated format loosely based on the one in On Game Design (Rollings and Adams) (don't worry if you do not have this book, but you might borrow one to skim sometime). A notable exclusion is any sort of business documentation such as executive summary, market analysis and competition analysis. The intent is to keep the project focused on the development (Tech and Art) side, rather than the business side. The draft should be about 2,000 words long (longer, if needed), and must contain the following elements:

Team Info	The name of your team, along with he names and WPI logins of every member of your team.
Title	The title of your game. This may be changed later if you want.
One-Sentance Description	A one-sentence tagline should capture the essential 'promise' of your game, and get readers excited about playing it. Also, distilling a game concept down to a single sentence can help pin down what's at the core of the project.
Game Summary	The Game Summary should contain an attention-grabbing paragraph describing your game, along with a list of novel features that your game will have.
Game Overview	The Game Overview should contain the details relevant to the high-concept of the game, such as: the concept, the genre, player motivation, a list of novel features, the target platform, high-level design goals, notes on how the game will play, etc.
Game World/Setting	The Game World section should describe the setting and characters of your game. For a narrative style game, this means some backstory for the world, descriptions of the characters and their roles they will play, and descriptions of any other important artifacts in the game world. For a non-narrative game, such as a puzzle game, you will still have some playing field, and objects, interacting on that playing field in many different ways - the field, these objects and their interactions will need descriptions.
Gameplay Walkthrough	This section should include a walkthrough of what a typical gameplay session might be like. It must be illustrated with at least three game screen mockups. The mockups don't have to be beautiful -- pencil sketches are enough -- but they do need to show major UI elements and support your gameplay description.
Production Details	The production details should describe the duties of each team member, how they will accomplish the development of the prototype, and what the production timeline will look like. The working prototype will be due on Tuesday 10.11, so plan accordingly. For the purposes of IMGD 1001, everyone follows the same production cycle on the same timeline, so the main novel part is the description of what each team member will be responsibel for.

Along with the above sections, feel free to supplement your treatment with any of the following optional elements: mocked-up screenshots, concept sketches, sample level designs, backstory, character descriptions, game balance discussions, etc. You can download this example final treatment to get and idea of what these could look like.

Here are two Treatment Documents from former IMGD 1001 teams.

You will use the new Web-based "Turnin" facility to submit your work. Information about submitting can be found here:

http://web.cs.wpi.edu/~kfisler/turnin.html.

Choose one of your team members to submit the document.

Use your WPI user ID to login, and you should have been emailed a password.
The Turnin assignment ID is proj2.

The way you present the treatment is entirely up to you. You can just stand up and talk, use PowerPoint slides, make a game trailer, use pantomime or interpretive dance.

You can choose one member of your team to do the presentation, or split it up among two or more members. Arrange in advance which parts of the presentation will be given by each team member.

You can, if you wish, bring a laptop to class with your presentation materials already preloaded, and we will hook your machine into the projector. Or you can bring your materials on a USB key for installation on the podium computer. In any case, test your presentation materials in advance to make sure they work properly. Embarrassing things can happen when you don't rehearse.

These presentations are an important part of the class experience. Please take them seriously.

Grading Guidelines
Weight	100-90	89-80	79-70	69-60	59-
100% Names: 1% Title: 1% Tagline: 3% Summary: 10% Overview: 10% Setting: 20% Walkthrough: 20% Production: 20% Presentation: 15%	The treatment more than satisfies the length and content requirements of the project. All required elements (noted above) are present, complete and detailed. The document is well organized and highly readable. Additional graphical elements (logos, sketches) enhance the document. The in-class presentation is well-rehearsed, unusually clear, informative and/or entertaining.	The treatment satisfies the length and content requirements of the project. All required elements are present and complete. The document is well organized. The in-class presentation is rehearsed, clear and informative.	The treatment minimally satisfies the requirements of the project. All required elements are present, but incomplete or inadequate. The document is somewhat organized, but difficult to read in places. The in-class presentation is not fully rehearsed, somewhat unclear or perfunctory.	The treatment falls short of the length and content requirements in a few places. Some of the required elements are missing, or do not include meaningful information. The document is poorly organized and/or difficult to read. The in-class presentation is poorly rehearsed, unclear or perfunctory.	The treatment does not satisfy the length and content requirements. Required elements are missing or incomplete. The document is disorganized and difficult to read. The in-class presentation is unrehearsed or inarticulate.

For a presentation summary, you might check out the slides (PowerPoint, pdf) for this project.

The Doom Bible (pdf)- Design document for Id Software's classic First-Person Shooter. It is interesting to note the differences between this document and the final game.

Capture The Dude - an example of a design doc written by former DigiPen student Doug Quinn.

The book On Game Design, by Andrew Rollings and Ernest Adams (New Riders, 2003. ISBN: 1-5927-3001-9) has an example game treatment document.