In terms of structure, a Game Design Document typically includes the following sections:

• Title Page: Your game’s title communicates the gameplay and the style of the game

• Current status: In a few sentences, state the games current status i.e (prototype)

• Introduction: An overview of the game’s concept, target audience, and objectives.

• Links to detailed sections: From the main page, the reader must be able to easily find the detailed information they want.

• Tools: A description of tools needed for designer, artist, programmers to create the game.

• Elevator Pitch: A description of your game in 3/4 sentences.

• Gameplay: Detailed description of the game:

  1.  mechanics, 

  2. controls, 

  3. progression systems.

• Localisation: Description of the initial localisation plan: English-only, EFIGS or other

• Story and Characters: Narrative elements,

  1.  Game’s plot 

  2. setting

  3. characters 

  4. etc

• Audiovisual Elements: Description of the art style, audio assets, and visual references.

• Technical Specifications: Platform requirements, tools, and any specific technical considerations.

• UI/UX: User interface design

  1.  Menus

  2. Controls

  3. Overall user experience.

• Development Roadmap: 

  1. Milestones

  2. Timelines

  3. Plan for the game’s development.

• Levels and Environments: 

  1. Layouts

  2. Objectives

  3. Visual references for the game’s levels and environments.

• Keep the game documentation lightweight: The original game concept doesn’t always work out. You might have to scrap the game, or pivot in a different direction. Either way, keep the initial documentation to a minimum so you don't have to rewrite a multi-page document. Fit it on a single page and let it evolve from there.

• Write the GDD collaboratively: Unless you are an indie game developer working solo, involve your team in the process from the start. Make your GDD the central hub where your team members discover, discuss, and solve issues together.

• The GDD should evolve together with the project: A GDD is only useful when it's up-to-date. Choose a documentation tool that preserves a version history and let your design document evolve together with your game by updating it daily.

• Use visual aids: Don't let your readers drown in text. Many ideas can be much more clearly conveyed using graphs, flow charts, and concept art. Or turn your entire game design doc into a mind map and watch it grow as your game evolves.

• Keep it current: Any design document is only as good as it is current. Game designers are often referred to as living documents, in that they change as the game development progresses. While your design docs need to be complete enough to guide the implementation of the game,  do not treat them as a “design bible” that is written once and never changed. Doing so is the  fastest way to make your design

• Divide and Conquer: On a multi-disciplinary team, each designer may be assigned particular parts of the documentation to maintain and keep current.

• Where to document?: Studios oftentimes keep their design documentation in internal wikis for quick access and easy adaption. Sites such as Confluence or Nuclino are popular options for this. It can be kept in a written document but the websites are specially made and can connect to other project management software such as Jira or Miro.