Game Design Document anatomy part 2
Hello everyone, I want to share tips on writing GDD part 2. This part is optional, but if utilized properly, it can greatly help in managing the document's information. I will start with the "Version Update" section, which is positioned after/below the index page.
Function: is to display the changes that have been made in the latest and previous versions of the GDD.
Problem: let's consider that there are 5 documents for the GDD, from version 1 to 5. Each version has different updates and quantities. Now imagine if there is a new update, and both new and existing team members have to read everything from the beginning just to understand what has changed. It would be time-consuming, right?
Solution: this version update page aims to save time and expedite the development process by allowing individuals to simply look at the notes on which pages have changed without having to read everything from the beginning.
You can see an example of its usage in the image below:
The "Game Asset" page is equally important. Before starting a project, it is essential to standardize the naming of assets that are approved by all parties involved.
Function: each developer may have different experiences and standards when it comes to creating and naming assets. If there is no standardization, other team members may become confused due to the inconsistent formats. This can hinder the process of asset creation and implementation..
领英推荐
Example: let's consider two game artists assigned to create prop assets. One artist uses English while the other uses Indonesian. One writes "house" while the other writes "rumah." Without any clarification, it becomes unclear which version of the house asset it is or where the "house" asset should be placed. Now, imagine if there are thousands of assets and each one needs to be opened individually just to determine its purpose. It would consume an entire day's worth of time.
Solution: lies in establishing a standardized naming convention right from the beginning. By following this convention, the type, function, and placement of an asset can be understood without needing to open the file. This facilitates greater efficiency for all parties involved. For instance, if a developer needs a button asset for their game UI, they can immediately recognize from the code "btn_nor_play_1" that it is the original version of the normal state button. There is no need to open the file to confirm if it is the asset they are looking for.
You can see an example of its usage in the image below:
You need something ? let's chat :)
https://bit.ly/3rDV0TP