Lecture 7 - Game Design Document

# Lecture 7 - Game Design Document
### SET09121 - Games Engineering

<br /><br />
Babis Koniaris
<br />

School of Computing. Edinburgh Napier University

---

# Recommended Reading

Game Design Workshop. 4th Edition. Tracy Fullerton (2019).

- Read Chapter 14 on Game Design Documentation.
- Digital copies are available in the library.

![GameDesignWorkshopBook](assets/images/gdw_book.jpg)

---

# What is a Game Design Document?

---

# What is the Game Design Document?

- A Game Design Document (GDD) is the template for the game that is to be created.
- The GDD is the main reference when determining how things should be done when developing the game. 
- However, it is not a sacred document. 
    - It is a living, constantly changing document.
    - Updates are made as the development progresses.
- It can get quite large. 
    - Over 1,000 pages in some circumstances.
- Team size and document size leads to the use of online collaboration tool like a Wiki.

---

# Game Design Document Overview

- Overview and vision statement.
- Audience, platform, and marketing.
- Legal Analysis.
- Gameplay.
- Characters.
- Story.
- World.
- Media list.
- Technical specification.

---

# GDD Exercise

Research Design Documents! Use Google to search for game design documents. There are quite a few out there and some templates. 
You are unlikely to find modern AAA games due to the collaborative approach and NDA requirements.

---

# Contents

---

# Design History

- Design History.
    - GDD is a living document.
    - Updates to the document should be described at the beginning of the document.
    - Version history should be maintained.

![image](assets/images/version.png)

---

# Audience, Platform, and Marketing

- Market research must be undertaken to determine the likely return to the publisher.
    - Unit sales are the most important factor for a publisher.
    - The quality of the game comes second.
    - Catering for a small/niche market is unlikely to win over a publisher (although this depends on initial outlay).

---

# Audience, Platform, and Marketing (cont.)

- You need to define the target audience.
    - Who will buy the game?
    - What is the core demographic?
    - How large is the audience and how likely are they to buy?
- You also need to choose the target platform(s). 
    - What are the target platforms?
    - Why have these been chosen?
    - Ensure this matches with the target audience.
- You also need to define the hardware requirements.

---

# Legal Analysis

- Important that you ensure everything is covered from a legal point of view.
- Are there any legal or financial implications that come with the game production. 
    - Licence agreements.
    - Copyright considerations.
    - Engine/library terms and conditions.
- Typically, Intellectual Property (IP) will be with the publisher, not the studio. 
- Game engines typically require statements of use, are expensive, and may require a per unit sale cost (for big games). 
- Legal & IP agreements with your Team/Contractors also needs to be considered.

---

# Copyright Issues

- IP owners are very protective.
    - Game companies included.
- When creating your game consider: 
    - Where you sourced your content from.
    - If the content is very similar to existing content.
    - If the game is very similar to others on the market.
    - If you have given due credit to any external tools, libraries, etc.
- Paying homage to something is all well and good but can get you into trouble.

![image](assets/images/sonic_anim.gif)

---

# Gameplay

- The description of gameplay is initially one of the largest sections.
- The game designer puts most of their focus into this section at the start. 
- This section will focus on how the game plays. 
- The Formal Elements and systems view will be useful here. 
- Overview section: 
    - Description of the core functionality.
    - Good practice is to base this on a physical or digital prototype.
- Gameplay description section: 
    - A detailed description of how the game plays.
- Controls section: 
    - User interfaces.
    - Rules and procedures (including some from Formal Elements).
    - Scoring / winning conditions.

---

# Gameplay (cont.)

- Modes and other features. 
    - Single player, multiplayer, etc.
    - Other features that may affect gameplay.
- Levels. 
    - Designs for any levels for the game.
    - The more detailed the level descriptions the better.
- Flowchart. 
    - Flowchart is needed to map out the gameplay.
- Editor. 
    - Does the game require the development of an editor?
    - What are its features?

---

# Flowcharts

Flowcharts can help visualise the gameplay

![image](assets/images/flowchart.png)

---

# Characters

- Optional part of the design document but often important.
- Character work can be a long, iterative process. 
- Very important to increase engagement with the player. 
- Will include concept design and description.

![image](assets/images/game_characters.jpg)

---

# Contents - Character Types

- Playable characters. 
    - Can have a lot of work spent on them.
    - Generally very detailed - particularly in games where you see the character all the time.
- Non-playable characters. 
    - Treat these as objects in your game with properties and functionality.
    - Includes:
        - Monsters and enemies.
        - Friends and allies.
        - Neutral characters.
    - Think about which traits you want these characters to have.
    - Think about the behaviours these characters need.
    - AI is a core concern in this section.

---

# Story

- Another optional section of the GDD. 
- Can become very large for story driven games, like RPGs. 
- There has to be a link between the gameplay and story. 
    - Your story should unfold through the game.
- Important parts of the story: 
    - Synopsis.
    - Complete story.
    - Back story.
    - Narrative details.
    - Sub-plots.

---

# Game World

If required, a description of the game world should be detailed.
- Overview.
- Key locations.
- Travel.
- Map.
- Scale.
- Physical objects.
- Weather conditions.
- Day and night cycle.
- Time/era.
- Physics.
- Society/culture.

---

# Maps

Maps can be very helpful to get an overview of the gameworld.

![image](assets/images/game-world.png)

---

# Media List

- You will need a list of the assets that are required by the art and sound team. 
- Descriptions of these assets will need to be provided. 
- You should adopt some form of naming convention to make life easier. 
- Types of assets you may need to produce include: 
    - User interface assets.
    - Environmental assets.
    - Character-based assets.
    - Animations.
    - Music.
    - Sound effects.

---

# Technical Specification

- The most important section for the technical team.
- Can sometimes be a separate document. 
- Developed by the technical lead. 
- Can be quite large and detailed.

---

# Technical Specification (cont.)

- What are the technical challenges of the project?
    - Important for costing the project.
- Is any new technology required? 
- What are the major software development taks? 
- What are the risks involved in developing the game? 
    - And how do you mitigate these risks?
- What are the estimated resources required to deliver the game?

---

# Technical Specification (cont.)

- Development platform and tools.
    - e.g. Visual Studio, Unity.
- Delivery mechanism / distribution. 
    - Steam / Humble / Itch / Epic / GoG
- Game engine 
    - Technical specifications.
    - Design.
- Interface technical specification. 
- Controls technical specification. 
- Lighting models. 
- Rendering system. 
- Internet / network requirements. 
- System parameters. 
    - e.g. max players, connectivity, etc

---

# Maintenance

- Game Design Document (GDD) is not carved in stone. 
    - Living document.
    - Updates made as development progresses.
- GDD can also get quite large. 
    - Thousands of pages in some circumstances.
- Game development can have large teams. 
    - Over a thousand people in some circumstances.

![image](assets/images/script.jpg)

---

# Using Wikis and Repositories

- Some are using a wiki to coordinate and communicate between team members.
    - Allows multiple users to update.
    - Allows all users to access the most up to date documentation.
    - Software development uses these often too - see wikis on GitHub.
- Repository systems can also be used. 
    - Combine document maintenance with code maintenance.
    - Could also be storing assets.
- Tools provide a structured and managed approach to the development process. 
    - Collaboration.
    - Communication.

---

# Summary

---

# Summary

- Game Design Document is a very important piece of work to put together at the start of your development process.
    - Blueprint for your game.
    - Communication with the team.
- It is a living document, so keep it up to date.
    - Content and media lists especially.
- Use collaboration tools as much as possible.
    - Team communication.
    - Document control.