Assignment — Game Design Document
GAME 1303 · Introduction to Game Design & Development
Due: Week 13 — Tuesday, November 17, 11:59 PM · Submit in Canvas · 10 points
What a GDD is
A game design document is the working record of what your game is. It exists so that you, a collaborator, or a producer can answer any question about the game without asking you.
It is a living document. Start it in Week 4, right after your One Sheet, and add to it every week as decisions get made. The Week 13 due date is when it gets graded, not when it gets written. A GDD written the night before is always obvious, because it describes intentions rather than the game that actually exists.
The grading standard is accuracy, not ambition. A short document that precisely describes a small finished game scores higher than a long one describing features that never got built.
Required sections
1. Overview
Your One Sheet content, updated to reflect what the game actually became. Title, hook, genre, platform, audience, core loop, art direction, key art.
If the game changed since Week 4 — most do — say so in a sentence. Changes are normal and cost you nothing. Pretending nothing changed costs you accuracy points.
2. Core mechanic
- The primary player verb, named in one sentence.
- The inputs that drive it, and on which devices.
- The tuning values that matter and what you settled on. Move speed 6.5, jump height 3.2 units, coyote time 0.12s.
- What you tried that didn't work, and why you changed it.
3. Rules and game states
- Win condition. Lose condition. What happens on each.
- The full state list — playing, paused, won, lost, and anything else.
- Restart and checkpoint behavior.
4. Levels
- A list of every level or scene in the shipped game.
- For each: its purpose, its length, and what it teaches or tests.
- Your level map images, embedded.
- Your difficulty curve, and how you produced it.
5. Interface
- Screen flow diagram: title → game → pause → win/lose → back.
- What's on the HUD and why each element earns its screen space.
- Your UI wireframes or final screenshots.
6. Art and audio
- Style reference and palette.
- Resolution, pixels-per-unit, or polycount and texture budget.
- Audio list: music tracks, and SFX by event.
7. Asset list
A table of every asset in the game — sprites, models, animations, sounds, fonts, UI elements. For each: name, type, status (done / in progress / cut), and source (you, a named third party with license, or AI-assisted).
This table is how the originality policy is checked. Anything unlisted is treated as uncredited.
8. Systems and helpers
- Which helper scripts you used, and which you modified.
- Any system you built yourself.
- Known bugs and things you'd fix with another week.
9. Scope and cuts
- What you planned in Week 2.
- What you cut, and when, and why.
- What you'd do next if the semester continued.
Honest cut lists score well. Cutting is the primary skill this course teaches.
10. Credits and disclosures
- Everyone who contributed anything.
- Every third-party asset with its license.
- AI disclosure: where generative AI was used — ideation, debugging, placeholder art, text — and what remained in the shipped build.
Format
- PDF, submitted to Canvas. Filename
lastname_gdd.pdf. - Length follows content. Most land between 8 and 20 pages. There is no minimum and no maximum.
- Images throughout. Maps, screenshots, wireframes, and reference. A GDD with no pictures is failing at its job.
- Numbered headings matching the section list above, so it can be navigated.
- A table of contents if it runs past about 10 pages.
Write it in whatever tool you like — Docs, Word, Notion, a markdown file — and export to PDF.
Rubric — 10 points
| Criterion | Pts | Met when |
|---|---|---|
| Completeness | 4 | All ten sections present with real content. 0.4 pts each. |
| Accuracy | 2 | The document describes the game that exists, including changes and cuts, rather than an aspirational version |
| Asset list | 2 | Every asset listed with type, status, and source; third-party items licensed and credited |
| Clarity and presentation | 1 | Navigable structure, embedded images, readable formatting |
| Credits and AI disclosure | 1 | Contributors, licenses, and AI use disclosed specifically |
Common failure modes
- Written in one sitting the night before. It reads as a plan, not a record, and the accuracy points go with it.
- No asset list, or a vague one. This is the most-missed two points in the assignment.
- Describes features that were cut as though they shipped. Move them to section 9 and you keep the points.
- No images. Costs presentation, and usually completeness too, since maps and wireframes live in those sections.
- "AI was not used" when placeholder art or debugging help came from a model. Disclosure costs nothing; an undisclosed use is an integrity violation.
Working method
Open the file in Week 4 with the ten headings and nothing under them. After every class, spend ten minutes filling in whatever you decided that day — the tuning value you settled on, the thing you cut, the asset you finished. By Week 13 the document writes itself, and it will be accurate, which is where six of the ten points live.