Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Game Design Document - Game Structure

Discussion in 'Game Design' started by Krazune, Nov 18, 2015.

  1. Krazune

    Krazune

    Joined:
    Nov 17, 2015
    Posts:
    8
    Hello everyone.

    I am writing my first game design document but I’m having some trouble choosing the best way to describe the mechanics and structure of the game. I can think about all the details and how things should work with each other, but I don't know how I should express those ideas on the document. I try to explain every element but if the structure is too complex I don't know how to organize it, so I would like to know how you explain the mechanics of the game (how do you, actually, represent the structure/hierarchy on the document and describe each element in-game).

    Thanks in advance.

    PS: I'm using Word - in case someone has some specific hints/tricks that i can use to organize things in a better way.
     
  2. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    Shorter is generally better. If you don't have a 1-2 page treatment document, stop and write that first. It'll help you focus the content and cut to the core.

    Then consider liberal use of storyboards -- a picture being worth a thousand words and all.
     
    theANMATOR2b and Kellyrayj like this.
  3. Kellyrayj

    Kellyrayj

    Joined:
    Aug 29, 2011
    Posts:
    936
    I do screenshots from other games. And real short quips likes. "I enjoy this mechanic from game "A" and I'd use it similarly here, but I'd like to do this with it"

    I do most of my projects solo though, so my game design docs are always half baked with notes and thoughts that I think I'd only be able to follow. If you are in a similar situation, don't let the game design doc be the thing that stops you from making what you want to make.
     
  4. goonter

    goonter

    Joined:
    Aug 31, 2015
    Posts:
    89
    It's common to organize docs like this by feature, which often is the same as the underlying system. So your description of the feature would be the user-facing portion: how the users interacts with it, what the UI looks like (wireframes or sketches), what it does, the design goals (like to provide medium term goals for the player, or to punish the player for dying too often, etc). Then your description of the system would be the underlying mechanics, like the math for drop rates, when the feature becomes available, how it interacts with other systems, requirements and constraints, and generally how it is intended to work "under the hood".

    In addition to that, if you need to do time estimates or budgeting, you could have a technical design section where you (or your engineer) outline what needs to be implemented to get the feature to work, and an asset list where you outline what art assets are required for the feature.
     
    theANMATOR2b likes this.
  5. goonter

    goonter

    Joined:
    Aug 31, 2015
    Posts:
    89
    Also, to give some examples, features are things like: crafting, item upgrading, skill points/tree, leveling, fishing, combat, vehicles, random level generation, leaderboards, etc. Some are parts of your game that could be removed and the core gameplay still remains, and some will be part of the core game. You should be able to separate them in your mind. For example, Angry Birds has the core features: physics driven destruction, projectile launching, levels. And additional features: projectile types, destructible material types, level packs, star system, cutscenes, whatever else they've added :)
     
    theANMATOR2b likes this.
  6. tedthebug

    tedthebug

    Joined:
    May 6, 2015
    Posts:
    2,570
    Mind maps can also be useful as each bubble has the core info & then all the linking lines show (visually) how they all connect without needing lots & lots of extra words to explain all the linkages.
     
    goonter likes this.
  7. jamesyoung79

    jamesyoung79

    Joined:
    Aug 22, 2012
    Posts:
    5
    I would suggest using google docs over word. This will allow you the freedom to access it anywhere you have an internet connection. Google docs is also great for collaboration. Also, a game design document should have a counterpart a Technical document. The technical document is where you go into more detail, for example: in the design document under art you mention animated sprites for enemies. In the technical document you specify png file format and individual sprites are 32x32 and how the sprites are positioned on the sprite sheet. It is also good to keep in mind the design document is a living document that should always reflect the current state of the game.

    Some good links for videos on design documents:



    Some example design documents:

    Marble Madness GDD

    Tower Defense GDD digipen
    Another good GDD example
    GDD template example
     
    theANMATOR2b likes this.
  8. Krazune

    Krazune

    Joined:
    Nov 17, 2015
    Posts:
    8
    Now I'm trying to keep it simple, but still write all the details needed to create each element (I'll try to keep the generic description and the technical description in the same document), and it seems to be working with a new document structure I'm using. I might end up switching to Google Docs, but since this is the first one and it's only me working on it, I'll finish it on Word.

    Thanks everyone for the help!
     
  9. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    I recommend keeping technical specs separate from game design specs. Putting technical restrictions (since that's what they end up being) in your game design documentation will restrict your creativity. Notice that the Marble Madness GDD stands the test of time; it doesn't specify pixel amounts etc., and it has plenty of storyboard-style drawings.
     
    jamesyoung79 and Kellyrayj like this.
  10. Master-Frog

    Master-Frog

    Joined:
    Jun 22, 2015
    Posts:
    2,302
    If you know what game you are trying to make, it should be as simple as describing it. If you're having a hard time describing it, maybe you don't know exactly what you're trying to make?

    GDD is not a necessary step in making your game btw. For a team, sure. But as an individual it is nothing but a fuzzy, incomplete pseudo spec sheet for a game that is sort of like the game you will end up actually making.
     
    Last edited: Nov 19, 2015
    GarBenjamin and Kiwasi like this.