Overview

The GDD for our project is managed primarily by Nathaniel, but each of us help contribute to sections of it that are appropriate to our role in the team. For me, that's helping out with the mechanics and goals & objectives sections of the GDD. I also helped with formatting by settting up the table of contents and chapter format.

Technical Description / Explanation 

Setting up the GDD's formatting wasn't too difficult. For the table of contents, I made a list for each of the main 'chapters' or sections, then added sublists to each that included the sub-sections within each section, similar to how a table of contents in a D&D source book is laid out. Following that, I set up an example for how each section should look (relatively), and began work on the sections I was asked to help with. For my sections, I tried to keep it brief and flexible (since these are just descriptions of what I will work on rather than what I have worked on). Once I move into production, I will update these descriptions to better reflect the current status of the project.

The main way in which our team worked together to develop the GDD was through discussing the formatting and working on each of our individual sections to lessen the workload of Nathaniel. For my section, I first read over what we had already discussed for the game's mechanics in both our meeting logs, messages on teams, and our group presentation. I then wrote down everything that I was confident would be included in the game. To further develop it, I will continue to update the mechanics section as new features are added and depreciated features are removed.

The main standout features of our GDD is the table of contents at its start that neatly organises GDD information into chapters and sub-chapters. We decided to make a table of contents to allow us to better search the GDD (especially as it grows throughout development) and find information without having to search each section of the document.

GDD Trans Dim Railway.docx 

Reflection

I believe our GDD is sufficient established for consistent work throughout the project. Having our formatting established early means that everyone is on-board and understands how it should look, and makes the GDD look organised from day one. If I were to improve upon it further, I would probably reformat the table of contents slightly visually, but aside from that I would keep everything else the same. There isn't much to be improved upon outside of adding more content in each section.

I will use the GDD as a resource to reflect the changes we make to the game's premise and mechanics throughout production. Additionally, it might be useful as a way of explaining different aspects of the game to industry and to help justify changes we've made to the game. The main takeaway that I got from helping to make the GDD is that clear documentation is helpful in outlining issues that might arise from more convoluted / complex game mechanics.