Embedded Files
In all my semester projects the documentation of the game design was one of my key tasks. It is the way to communicate and archive the ideas and rules for the game you and your team are making. As a tool for communication I write all my documentation documents with the reader in mind trying to make the information as easy accessible as possible. Below is a GDD of my second semester as an example of my documentation in my past student projects.
Tree of Dreams - GDD
Tree of Dreams - GDD
mockup of the behaviour of soil tiles
rules for the behaviour of soil tile sturctured in 3 phases
mockup for planting seeds
rules for the planting of seeds sturctured in 3 phases
Context
Context
Tree of Dreams was my second project at the S4G. I joined a team as a game designer after they had pitched the game. I took on a lot of responsibilities for my department, because my only other game designer colleague had to take significant time off during the semester. I put a heavy emphasis on developing a documentation system that fitted my team and was easy to find the relevant information for the reader without losing accuracy and detail. I created the GDD in Google Docs.
Structure
Structure
The first segment of my GDDs is of course a table of contents. Every entry is linked to the correlating heading.
The first game relevant information is the generell game info containing the vision, objective and the controls of the game. Also it has a small part for some technical information like platform and engine.
After that comes the description of all game features. They are sorted into themes. A theme is defined as a collection of features that have similar properties or belong to the same game object (e.g. the character of the player, enemies etc.)
A feature description is segmented in summary, goals, visualization, rules, variables and content, whereby the last two are not always needed.
The summary is the high concept for the feature. I summarized what the feature does with a couple of short sentences, but it doesn't contain the how.
The feature goals are the reasons why the feature is in the game. It is a list of short bullet points of the issues the feature tries to address.
The visualization should be a skribble, mockup or diagram of the functionality and/or the representation of the feature in the game world.
The rules are a detailed list of bullet points describing how the mechanics of the feature function. The rules are detailed in a list of 3 phases. Phase 1 are all necessary functionalities to have a proof of concept for the feature. Phase 2 contains everything that is necessary to have it ready for shipping. Phase 3 are all mechanics that are nice to have for the feature.
The variables are a list of all values that need to be easily accessible for the designer/ balancer.
The content is a list of all necessary assets needed to build the feature. This weren't all assets but the minimum amount of assets.
At the end of the GDD was a glossar containing all the game specific jargon used in the GDD with a description of the word in the context of the game. Whenever a game specific word is used, it is linked to the word in the glossar.
Learnings
Learnings
After getting feedback, I was amazed, how even rough sketches and simple mockups drastically improved the readability and the understanding of the GDD.
While goals aren't as helpful to programmers or artists, they help to share the intention of a feature design. Writing them down also helps to assess, if the feature works during the prototype process and if it is cuttable.
Also I learned that content should not be listed in the GDD. A clear separation from the mechanics and content makes the GDD more digestible for the readers. Nevertheless I think adding a link to the documents containing the content of the feature could be very helpful.
I had a very well kept glossar at the end of the GDD. This was really helpful, but I think having a separate google sheet table as glossar would be better. It would be easier to link other documents and if changes are necessary it is easier to do them in a centralized document.
A great structured GDD doesn't help the team if the team isn't informed, when changes are made. It is important to communicate changes in the documentation and make it as easy as possible for the team to find these changes in the documentation.
Lastly I learned that the documentation has to stay ahead of the development. Otherwise the design creates a very dangerous bottleneck, that makes the process for other departments very hard.
Page updated
Google Sites
Report abuse