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 so course staff are able to read and comment on it. The game can be anything that is feasible for a group of 3/4 to complete in 5 weeks.

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 (i.e. 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?)
• 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?)

If applicable:

• physics (how does your game incorporate the physics engine?)

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 five (1 = game cannot work without this, 5 = cool but not necessary).

You must have a minimum of five 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. As a rule of thumb, we expect each feature to take ~5-6 hours to implement, so if you think any features will take more/less time, adjust them accordingly.

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. We are not looking for a high page count, but we do expect a well thought out document. 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.