Due dates:

• Game Idea Friday, March 16, by 11:59pm
• Game Plan Friday, March 23, by 11:59pm
• Web Page Tuesday, April 10, by 11:59pm
• First Playable Thursday, April 19, by 11:59pm
• Final Game Friday, April 27, by 11:59pm

The end goal of this project is to build a working game with one or more technical components. As the focus of the course is on the technical aspects of game development, the game does not necessarily have to look good or even have innovative game design, but it should be a (good) playable game and exhibit one or more technical characteristics as determined in the plan.

You will work in groups of 3 for this project.

Game Idea

The Game Idea is a brief document with the overall idea behind your game. Expect to write about 1 page. The game idea document should include:

• The Development Team. Include the names and email address of team members. Note, this project must be done in groups! Groups of 2 or 3 people. A group of 4 is too big. A group of 1 is too small.
• Working Game Name. The name for the game. This can change before the final game.
• Overview. The overview should contain the details relevant to the high-concept of the game, such as: the concept, the genre, list of novel features. Include a one-sentence description describing your game. Specifically distilling a game concept down to a single sentence can help pin down what's at the core of the project.
• Technical focus. The technical game aspects that will be the concentration of the development efforts. It should include at least one and probably no more than two areas of technical focus. Examples include: Artificial Intelligence, Networking, Physics, and Graphics. The technical focus will be refined in the Game Plan.

Game Plan

The Game Plan provides more details on the how the game will be built. This is a somewhat longer document, so expect to write 2-3 pages, with sections such as:

• The Game Name and the Development Team, same as in the Game Idea.
• Game summary. This should be an attention-grabbing paragraph describing your game, providing a high-level view of the game play, game genre, and novel features. The summary should also highlight the technical focus.
• Implementation. This will provide details on the implementation, including:
  • Programming languages and platforms.
  • Frameworks, libraries or game engines to be used.
  • Previous work or downloaded code to be used.
  • Art (art, music, story, sound) assets, created or copied, with appropriate credits provided for copied assets.
  Most importantly, this section should describe the area of:
  • Technical focus, for example AI, Networking, or Physics, providing specifics on the focus.
• Roles. Team members will assume distinct roles during implementation. There should at least be:
  • Leader - calls meetings, checks progress according to schedule. Adjust schedule accordingly.
  • Scribe - takes notes during meetings, maintains Web pages and other documentation (note, does not have to write everything, but coordinates writing). There should be a "to do" list after each meeting.
  The roles should switch at least once during the term! (ie- everyone is leader and everyone is a scribe).

• Schedule. The development schedule should include milestones with dates and distribution of tasks to team members (all team members must do something technical). Use the schedule for your planning - refer to the schedule each meeting!

The Game Plan document will be updated and turned in with your Final Playable.

Web Page

You will create a Web page for your game, designed to show it off. This should be a front-end to the game, suitable for a portfolio. Included aspects will likely include:

• Picture(s) of the game, including custom artwork or screenshots (or both).
• Text with game description information.
• About information, including team names, contact information, version information, etc.
• Download information (with appropriate install or run instructions).

The Web page can have multiple sections or multiple pages. Likely candidates include sections of: Main/Home, Development Team and Credits, Instructions, and Download.

The Web pages can also have links that are internally useful to your development team, such as the timeline, or hotlinks, etc. These should be removed for the final project.

First Playable

The first playable game prototype will:

• Allow a player to interact with the game (ie- experience core gameplay).
• Have completed the technical components that are the focus of the game, minus final testing (ie- there still may be some modest bugs).

The First Playable will be shown to the class in a presentation. This will be a brief (5 minute) walkthrough of the game. If running it is difficult, for whatever reason, include screenshots or a "canned' movie.

For turnin, include:

• The executable. The source code is no required at this point (source code will be needed for the final playable).
• README. Briefly indicate technical features complete, and technical features yet remaining. Also include instructions on how to run first the game.

Final Playable

The final game should:

• Have all of the required features of the design implemented.
• Be tested thoroughly to eliminate any critical gameplay flaws and bugs.
• May still contain a certain amount of placeholder assets.
• Should exhibit at least one level designed and tested.

Note, while called "final" this release is, in effect, more similar to the traditional "Alpha" release of a computer game (with the exception that the game should have at least one, balanced and tested game level).

The Final Playable will be shown to the class in a presentation and will be played by class members during the game fest.

For turnin, include:

• The "executable" (as appropriate for your implementation.
• The source code, including all libraries and art assets necessary to build your project.
• An updated version of your Game Plan with your game. The updates are any changes to the original plan reflecting what you actually did do.
• Your Web page(s), saved as a complete HTML pages. The easiest way to do this is probably to zip/tar up your Web page tree (be sure to include all images, etc) and include that in your submission.

You are free to implement your game in your choice of language (C, C++, Java...) using your choice of graphics libraries (OpenGL, DirectX, Ogre, Lightweight Java Game Library...) or game engines (Torque, C4, Game Maker, Golden T Game Engine, ...). Consider using a language you are familiar with or feel you can pick up with relative ease (you don't want to spend too much of your development effort fighting with the language). Consider using a game engine or libraries that take care of the technical parts of the game that are not the focus of your implementation.

Using your own prior work is allowed, but must be carefully documented. If you start with a previously developed game or even previously developed idea, the initial state (ie- what is implemented) needs to be clearly provided. Similarly, any code used from previous classes or development efforts must be noted with details.

The focus on the game (and the course) is on the technical aspects of game development. So, don't spend too much time on the art. You are encouraged to borrow art assets (music, sound effects, models, textures, sprites, tiles) from freely available sources. Do note any artistic restrictions in art assets you use, especially if you intend on using your game as part of a portfolio.

All assignments are to be submitted electronically via turnin by 11:59pm on the day the assignment is due. Turnin of code should include all the support files to allow it to be built, along with detailed instructions on platform, libraries, etc.

You will need to upload the files you are turning in to your CCC account on one of the CCC machines (ccc1 to ccc10). While logged into a CCC machine, you will need to enter the directory where these files are stored and execute the following:

  /cs/bin/turnin submit <course> <assignment> <file1> <file2> ...

where in our case, <course> is imgd400, <assignment> is project4a (or project4b or project4c or ...), and <file1>, etc. are the files to be turned in. So for example, you might enter:

  /cs/bin/turnin submit imgd4000 project4a Idea.doc 

Following this, you should verify that your files have been entered into turnin by executing the following command:

  /cs/bin/turnin verify imgd4000 project4a

Return to the 4000 Home Page

Send all project questions to the TA mailing list (imgd4000-ta at cs.wpi.edu).