Games GDD
Games GDD
 |
| GDD |
In this week's reading I learned about Game Design Documents. The objective of a game design document is to effectively communicate your design decisions to members of your team. The document is also in place to aid your memory throughout the creative process of game design. A lot of the time game designing can be time consuming, so the document is established to record any important decisions made by the design team. No two games should share the same game design document. It is uncommon that one template will fit all the requirements of your game.
How Can We Make One
What Should be In a GDD
The GDD should be simple enough to read though detailed about your game design and concept. Schubert (2007), who was at the time lead designer for Bioware Austin, gave a GDC talk in 2007 about how to create design documentation, some of the most relevant elements include:
Know your target. Have a clear vision and understanding of what you want to make. Insure your game is suitable and fits your target audience.
Keep it short. Keep it to the point and clear, the shorter they are, the easier it is to read, write, and maintain.
Prioritize the design. Divide your game in order of importance e.g have a functional game. Concentrate on core mechanics and visuals, and then expand.
Illustrate. Draw sketches of your plans that make it easier to structure and implement. Present what your game would look like? It is important to have a clear idea of the visuals before you begin creating.
Use user stories. Describing the game trough the player's vision (Similar to what we did in the game vision statement).
Invest in a good format. Take the time to structure your work so that it is easy to navigate.
Use a clear terminology. Don't over- complicate the document. Make sure language is concise and accessible.
Kill redundancy. Recycle your code- use variables, not hard code. Always refrence the new section on your page to have a clean document. Avoid copy and pasting sections.
Capture your reasoning. Why did you make the choices you made> What led to that thought proces
- Game Design Overview (Design) is usually a few pages and it provides a high level overview of the game. It is used to communicate the main creative vision of the game.
- Detailed Design Doc (Design) describes the games mechanics and interfaces. Helps designers remember details.
- Story Overview (Design) often external writers work on the game's narrative. Communicate settings, characters, and actions.
- Technical Design Doc (Engineering) contains the essential systems architecture underlying the game's code.
- Pipeline Overview (Engineering) keeps track of requirements and specifications (art, sounds or other files).
- Systems Limitations (Engineering) Engineers use this document to communicate the limitations of the game engine. If done correctly, this can save a team a lot of time later in development.
- Art Bible (Art) Should have a single consistent look and feel.
- Concept Art Overview (Art) Helps understand the vision for the game and keep the creative ideas aligned.
- Game Budget (Management) Budget estimate is always necessary to obtain funding for a project in the first place. This is usually a spreadsheet that lists all the work and the attached value.
- Project Schedule (Management) If scheduling is done correctly, overtime is minimized.
- Story Bible (Writing) Only necessary if the game features a story. It is good to keep a common document of the game narrative and annotate it as changes are proposed.
- Script (Writing) Any dialogue is recorded in this document and checked for correctness.
- Game Tutorial and Manual (Writing) Manuals are not necessary but is is always good to write down what the basic actions in the game are and how to best teach them to players
- Walkthroughs (Players) After releasing the game payer often codify their own strategies, and document Easter eggs and other parts of a game that they found particularly exciting.
Comments
Post a Comment