CS 3 (Spring 2024) Game Design Document


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:

Section 1: Gameplay

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

This section should also address:

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 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:

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.