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 to complete in 3 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 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 rescind 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. 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.

Potential Inspiration

This year, we’ve removed demos from the course that students in previous years were required to implement. As a result, we’ve included videos of what these demos looked like to provide inspiration for what can be done using the physics/asset engine.

Note that none of these videos on their own would be enough work to count as a final game: for the videos of demos, students were given a week to complete them, and the game is expected to take 3.

Demo using the spring and drag force creators

Demo using the gravity force creator

Demo using button assets

Demo using physics and custom collision handlers

Staff demo that uses physics and custom collision handlers

Attaching images to bodies–this is actually the demo for project06 but we wanted to show you early since it’ll be released next week.

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.