Introduction

This document describes what we expect from your game design document. You must write your design document in the README.md of your game repo as Adam and the TAs must be able to read and comment on it. The game can be anything that is feasible for a group of 3 to complete in 3 weeks, but it must make use of your physics engine in some way.

Organization of Your Design Document

The following is a list of the various pieces your game design document should have.

Section 0: Summary

This section should tell the reader what to expect in the future sections. In particular, it should contain at least:

• a working title for your game
• a list of your team members (and their roles if decided)
• a “concept statement” of your game (“your game in a tweet”)

Section 1: Gameplay

This section should address simple questions about how your game works:

• How does your game progress?
• What are the win and loss conditions?
• Are there levels?
• Are there points?

This section should also address:

• controls (keyboard? mouse? tongue?)
• physics (how does your game incorporate the physics engine?)
• game flow (what does the game look like from start to end for the player?)
• graphics (will you draw polygons? use sprites? make your own vector graphics?)

Section 2: Feature Set

This section should reduce your game to a set of individual features (remember iterative development?). Your team should assign these features to individual group members and assign each one a priority from one to four (1 = game cannot work without this, 4 = cool but not necessary).

To turn priorities into a grade at the end of the term, we will apply the following rules:

• If all priority 1 features are implemented, we guarantee a minimum grade of D on the team portion of the game.
• If all priority 2 features are implemented, we guarantee a minimum grade of C on the team portion of the game.
• If all priority 3 features are implemented, we guarantee a minimum grade of B on the team portion of the game.
• If all priority 4 features are implemented, we guarantee a minimum grade of A- on the team portion of the game.

If your group does not distribute work evenly, we recind all promises made above.

You must have a minimum of four features (one of each priority) per group member. Features will vary in difficulty, and we understand that, but nonetheless, we’re expecting at least that many total.

We have gathered together the following list of some example features you might choose to implement:

• make your own graphics or sprites
• add sound effects
• implement a scrolling environment
• implement a networked/multiplayer game
• implement 2D parallax (https://en.wikipedia.org/wiki/Parallax)
• implement an AI for an enemy
• implement speed-independent friction
• implement more accurate integration (current implementation uses a trapezoid sum)
• implement music

Section 3: Timeline

This section should assign every feature in the previous section to a particular group member and a particular week they will implement it.

Section 4: Disaster Recovery

This section should describe how each member plans to get back on track if they fall behind. Please take this section seriously.

Design Document Grading

The design document you are writing will, itself, be graded. If you are missing any of the sections or a section is clearly not thought through, you will get at best a C on the document. We are not looking for a high page count; it is possible to get an A on this document with no more than two pages of information (though, we expect the average design document to be longer). We are also not grading you on the design of your game (unless you choose this to be itself a feature); a poorly concieved game can still receive full credit.

Design documents that are obviously deliberately underscoped will receive a zero.