Interactive Media & Game Development
Worcester Polytechnic Institute

IMGD


IMGD 1001: The Game Development Process
Project 2: Game Inception and Design

Due date: Monday, September 10th, by 10:00am


Objective: This is the second project in a series of related projects that you will be doing over the course of this term. The end-goal of these projects is to expose you to the overall process of game development by introducing you to the facets of design, content creation, programming, and testing. As an outcome, you and a small team of peers will be creating a working video game prototype. This project focuses on documentation and the decisions that must be made early in the game development process. Grading for this project will be somewhat flexible based on the emphasis of your treatment (see the Grading section for details).

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.

Motivation: All games begin with an inspired idea. The idea may come as a sequel to a previous game, a license to make a game from a film, or even an original game concept. But an idea alone is not a design for a game. The idea must be elaborated upon to the point where the various team members can begin their work. No matter what role you play as a developer, your tasks will be shaped by the design. Programmers will need to make good on the promised features. Artists will need to bring the various characters and places to life. Designers will need to put the world together in a way that is entertaining. Testers will need to verify and test the resulting experience, and communicate shortcomings back to the rest of the team.

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.


Details: For this project, you work in your teams that were formed this week. Each team will be responsible for writing a Game Treatment document of at least 2,000 words. The treatment should be for a game of your own design in the genre of your choice. The purposes are to think about design decisions, to develop your ideas to a good level of detail, and to express those ideas clearly in writing.

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.


What to Submit: Your document should be be submitted electronically via turnin.
When you are ready to submit, zip the document up into a single archive file. Name the file TeamName_proj2.zip.

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.


In-Class Presentation: Your team will present a 2-3 minute summary of your treatment to the class on Monday, September 10.

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.


Academic
Honesty:
Remember the policy on Academic Honesty: You may discuss the project with others, but you are to do your own work. The official WPI statement for Academic Honesty can be accessed HERE.

Grading: All team members will receive the same grade for this assignment.
Later assignments will ask team members to rate team member performance.

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.


Resources:

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.



Back to course page.