Name Of Starting Game Design Document

• Blog
• Forums
• Answers
• Evangelists
• User Groups
• Beta Program
• Advisory Panel

Search Unity

Unity ID

A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate in the Unity community.

• Forums

• Menu

1. 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. 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.

3. 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. 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.

5. 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

6. 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.

7. 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

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. 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.

10. 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

Name Of Starting Game Design Document

Source: https://forum.unity.com/threads/game-design-document-game-structure.368733/

Posted by: bevilacquathisitted.blogspot.com

Share this post