99 lines
5.6 KiB
Markdown
99 lines
5.6 KiB
Markdown
---
|
||
sidebar_position: 1
|
||
title: 'GD Team'
|
||
---
|
||
|
||
# GD Team
|
||
|
||
The Game Design (GD) team is responsible for crafting the game's mechanics, systems, interface, and overall user experience. Additionally, the GD team plays a crucial role in cross-department communication and maintaining up-to-date documentation of features and requirements. To enhance their effectiveness and align with industry standards, the GD team should adopt the following improvements:
|
||
|
||
## Implement a Proper GDD
|
||
|
||
In professional game development, the Game Design Document (GDD) is typically divided into multiple structured documents or sections, each tailored for different development phases and target users—such as developers, artists, UI/UX designers, and QA/QC testers.
|
||
|
||
To meet industry expectations, the GD team must evolve from producing only high-level overviews and wireframes to maintaining **complete, structured, and living GDDs**. These documents should follow proven formats used by established studios and large-scale projects.
|
||
|
||
### 📚 Reference GDD Sources
|
||
|
||
**Publicly Released GDDs**
|
||
|
||
These examples provide valuable insight into real-world GDD structures and expectations:
|
||
|
||
| Game / Studio | Preview Image | Link |
|
||
|----------------------------------------------|-----------------------------------------|----------------------------------------------------------------------|
|
||
| Grand Theft Auto (Race ‘n’ Chase) – Original GDD |  | [View PDF](https://www.gamedevs.org/uploads/grand-theft-auto.pdf) |
|
||
| Deus Ex – Annotated GDD |  | [View PDF](https://drive.google.com/file/d/0B2_-knUokw90RzIwUEJsU2pYdWs/view?resourcekey=0-dqmq9k501fBUBDoUEgv4Sw) |
|
||
| Dirty Bomb – Full Design Document |  | [View PDF](http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty_bomb-game_design_document.pdf) |
|
||
| PGSoft – Slot Game Information GDD |  | [View Site](https://www.pgsoft.com/download/) |
|
||
|
||
**Premium GDD Templates**
|
||
|
||
Templates available from platforms such as **Notion** and **Nuclino** offer modern, interactive, and highly customizable frameworks for building GDDs.
|
||
|
||
|
||
|
||
|
||
## Adopt Modern Tools for Game Design
|
||
|
||
Traditionally, GDDs have been managed using Word, PowerPoint, or even informal chats in Teams. These methods make it difficult to track changes, maintain consistency, or ensure accessibility for other departments.
|
||
|
||
To ensure clarity, maintainability, and team-wide collaboration, the GD team must adopt modern, industry-standard tools designed specifically for collaborative game development.
|
||
|
||
### ✅ Recommended Tools
|
||
|
||
| Tool | Purpose | Benefits |
|
||
|-------------------------------|----------------------------------|----------------------------------------------------------------------------------------------|
|
||
| **Notion** / **Confluence** | GDD Documentation | - Real-time collaboration<br></br>- Structured templates<br></br>- Version history<br></br>- Easy cross-referencing |
|
||
| **Miro** / **FigJam** | Flowcharts & UX Mapping | - Visualize game flow<br></br>- Brainstorm features<br></br>- Create interactive UI screens |
|
||
| **Figma** | UI/UX Wireframes | - Clickable prototypes<br></br>- Pixel-perfect layouts<br></br>- Seamless handoff to Art and Dev teams |
|
||
| **Game Engine Prototypes**<br></br>(e.g., Cocos Creator, Unity, Godot) | Gameplay Prototyping | - Test core mechanics early<br></br>- Validate design feasibility<br></br>- Enable shared playtesting |
|
||
|
||
## Organize the GDD with Change Log and Centralized Repository
|
||
|
||
To improve version tracking and ensure consistent document access, the GD team should maintain a structured GDD repository with an embedded **change log** and well-defined access management.
|
||
|
||
### ✅ Change Log Implementation
|
||
|
||
Each GDD should include a clear **change log** that documents:
|
||
- Date of change
|
||
- Editor name
|
||
- Summary of updates
|
||
- Reason for the change (e.g., meeting feedback, client revision)
|
||
|
||
This promotes transparency, reduces miscommunication, and establishes a reliable record of design decisions.
|
||
|
||
### 📁 Centralized Document Repository
|
||
|
||
A single source of truth should be used to host all GDD files. We recommend **Microsoft SharePoint** for its:
|
||
- Secure access and permission control
|
||
- Integrated version history and rollback features
|
||
- Compatibility with Microsoft Teams and Office
|
||
- Tagging, search, and commenting capabilities
|
||
|
||
|
||
|
||
### 🧭 Suggested Folder Structure
|
||
|
||
Organize the GDD repository with a consistent structure to support fast navigation and cross-functional access:
|
||
|
||
```
|
||
/ProjectName/
|
||
├── GDD/
|
||
│ ├── 00_Overview.md
|
||
│ ├── 01_Feature_Detail.md
|
||
│ ├── 02_UI_UX.md
|
||
│ ├── 03_Assets_List.xlsx
|
||
│ ├── ...
|
||
│ ├── 99_Changelog.md
|
||
├── References/
|
||
├── Meeting_Notes/
|
||
├── Archive/
|
||
```
|
||
|
||
By maintaining a well-organized repository and standardized documentation practices, the GD team will improve production efficiency, cross-department alignment, and product quality.
|
||
|
||
:::tip
|
||
[**Game Design Skills**](https://gamedesignskills.com/) is a valuable resource for expanding your design toolkit and learning from industry best practices.
|
||
:::
|
||
|