IMGD 1001: The Game Development Process
Project 6: Complete and Present Prototype

Due dates:


Background

In previous assignments, your team has created a treatment, selected assets and implemented basic objects for a game.

Now it's time to bring it all together, do the necessary balancing and tweaking, and complete a prototype that demonstrates the potential of your design.


Objectives

This final assignment has five objectives:

  1. Complete your prototype
  2. Provide a status report
  3. Document your prototype
  4. Submit your prototype and documentation
  5. Present your prototype in class

1. Complete your prototype

The final form that your prototype takes will be highly dependent on your original design, but in all cases the prototype must be playable.

As the purpose of your prototype is to give people an impression of how your game will play, you should construct enough gameplay or levels to show off the objects and interactions that show off the core gameplay. Use as many or as few levels as it takes to represent the gameplay experience you wish to achieve. For example, a strategy game might only require the use of one battlefield to get the point across, whereas a puzzle game might require a sequence of three or four challenges.

Your prototype will be evaluated based on how well you integrate the artwork and game objects you created for Project 4 and Project 5 to meet the artistic vision you expounded in Project 3.

Other requirements

In addition to these example levels, your prototype must also include the following elements:

The exact configuration of these features is up to you, as there are many valid ways of organizing them. For instance, some games display a splash screen of credits at start, followed by the title screen, then options; Other games might have the title screen at the start, leading straight into the game, with options accessible in-game and credits displayed at exit.

2. Provide a status report

Put together a quick, no-frills status report on your project.

The report should include (in the following order):

Arrange in advance which team member(s) will give the presentation.

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, thoroughly test your presentation materials in advance to make sure they work properly.

Total presentation time should not exceed 5 minutes. Please plan your presentation accordingly.

3. Document your prototype

Create a document with the following required elements:

  1. The name of your team, along with the names and WPI logins of every member of your team.
  2. The title of your game.
  3. A short description of your game. This can be taken from your Game Treatment if it still applies.
  4. A list of major game features.
  5. Instructions for playing your game. These can be the same as the ones you include in-game in the prototype.
  6. A brief (200-350 word) description that specifically relates your prototype implementation back to your original game treatment. Discuss how the core game goals are, in fact, demonstrated by the prototype, or how they are not (and why not). If there were significant deviations from the original treatment, this should be called out, with brief reasons provided.
  7. A separate image of your project (200x150), suitable for a representation for a Web page. This can be a screenshot, or logo or some other catchy graphic. With this image, please include a short (about 100 words) description to accompany your picture.
  8. (Optional) Feel free to include additional production sketches or game artwork as desired. Title-screen artwork and/or a team logo might be good additions.

4. Submit your prototype and documentation

When your project and documentation are ready, zip them together into a single archive file. Name the file:

teamname.zip

where "teamname" is the name of your project team.

Use TurnIn to submit your work.

If TurnIn does not work, email your file to one or both of the class teaching assistants, Paulo de Barros (pgb) or Jia Wang (wangjia).

If email fails, post your file on a public web site and email the URL to me (bmoriarty) and both teaching assistants.

5. Present your prototype in class

Each project team will present their prototype in class.

Presentations should begin with an introduction of the team and members, then provide a high concept of the game, including a quick summary of the major features and core ideas.

Most of the time should then be spent on demonstrating the prototype itself.

Every member of your team should talk. 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, thoroughly test your prototype and presentation materials in advance to make sure they work properly. Embarrassing things can happen when you don't rehearse.

Total presentation time should not exceed 7 minutes. Please plan your presentations accordingly.


Grading

All team members will share the same grade.

NOTE: You will be graded on the version of your project submitted online by the due date, not on the version you present in class.

100-90. The prototype more than satisfies the content requirements of the project. It plays smoothly, clearly implements the stated vision of the team, contains all of the required features described above, and displays special effort in polish and presentation. The status report is well organized, professional and provides the required information. The documentation contains all required information, clearly explaining how the prototype operates and how it satisfies the gameplay goals described in the treatment. The group presentation is well-organized, well-rehearsed and introduces the team and prototype in a fun, professional manner.

89-80. The prototype satisfies the content requirements of the project. The status report covers the required material in a rehearsed, organized manner. It operates correctly and contains all the required features. The documentation contains all required information. The group presentation introduces the team and prototype in an organized, clear manner.

79-70. The prototype minimally satisfies the content requirements of the project. It operates correctly, and has all required features, but may be awkward or difficult to use. The status report may be somewhat disorganized and/or under-rehearsed. Required material is present but marginally covered. The documentation is present, but may be incomplete, or lack specificity about how the prototype meets its goals. The group presentation may be somewhat disorganized.

69-60. The prototype falls short of the content requirements of the project in a few places. The prototype operates, but may be difficult to use or understand, or some of the required features may be only partially implemented or hard to access. The status report may be significantly disorganized and/or under-rehearsed. Some of the required elements may be missing. The documentation is present but somewhat disorganized, or fails to explain how the prototype meets its goals. The group presentation may be significantly disorganized.

59-0. The prototype does not satisfy the content requirements of the project. The prototype may be non-functional or missing, not operate reliably, or required features may be absent. The status is seriously disorganized, with little or no rehearsal. Required material is missing and/or poorly covered. The documentation is missing, incomplete or hard to understand. The group presentation is seriously disorganized.


Back to course page.