Skip to content

Latest commit

 

History

History
144 lines (93 loc) · 3.77 KB

File metadata and controls

144 lines (93 loc) · 3.77 KB

Game Design Document

Game Name

Genre

Game Elements

game elements are basic activities the player will be doing for fun

Player

the number of players that can play the game at once

Technical Specs

Technical Form

basically there are 2D graphics and 3D graphics

View

camera view from which the player will experience the game

Platform

iOS, android, Mac, PC

Language

C#, C++, Rust, gdscript

Device

pc, mobile, console

Game Play

use the game play section to create a sescriptive paragraph about how the game is played. You want the use for imagine they are actually playing the game. Try not to use generic (i.e. broad, non-descriptive) terms when writing about the game paly. For example, few readers want to hear statements such as, "enemy..1 will have more hit points than enemy..2." Instead, it's better to make statements like, "The Lazarus Fighter has more armour than the Apollo Fighter."

Game Play Outline

this outline will vary depending on the type of game.

  • Opening the game application
  • Game options
  • Story synopsis
  • Modes
  • Game elements
  • Game Levels
  • Player's controls
  • Winning
  • Losing
  • End
  • Why is all this fun?

Key Features

key features are a list of game elements that are attractive to the player

Design Document

This document describes how GameObjects behave, how they're controlled and their properties. This is often referred to as the "mechanics" of the game. This documentation is primarily concerned with the game itself. This part of the document is meant to be modular, meaning you could have several different Game Design Documents attached to the Concept Document.

Design Guidelines

This is an important statement about any creative restrictions that need to be considered and includes brief statements about the general (i.e. overall) goal of the design.

Game Design Definitions

This section established the definition of the game play. Definitions should include how a player wins, loses, transitions between levels, and the main focus of the gameplay.

Game Flowchart

The game flowchart provides a visual of how the different game elements and their properties interact. Game flowcharts should represent Objects, Properties, and Actions present in the game. Each of these items should have a number reference to where they exist within the game mechanics document.

  • Menu
  • Synopsis
  • Game Play
  • Player Control
  • Game Over (Winning and losing)

Player Definition

  • Use this section for quich descriptions that define the player

  • Use the Player Properties section (below) to define the properties for each player. Player Properties can be affected by the player's action or interaction with other game elements. Define the properties and how they affect the player's current game.

  • Use the Player Rewards section to make a list of all objects that affect the player in a positive way. Define these objects by describing what affect they cause and how the player can use the object.

    Player Definitions

    A suggested list may include

    • Health
    • Weapons
    • Actions

Player Properties

Each property should mention a feeback as a result of the property changing

Player Rewards

Make a list of all objects that affect the player in a positive way (e.g. health replenished)

User Interface (UI)

This is where you'll inclide a description of the user's control of the game. Think about which buttons on a device would be best suited for the game. Consider what the worst layout is, then ask yourself if your UI is still playable. A visual representation can be added where you relate the physical controls to the actions in the game. When designing the UI, it may be valuable to research quality control and user interace (UI) design information.