Most small young teams have the same problems. Normal processes are not built, the simplest planning is missing, the concept is shaky and not fully worked out, and the documentation is just creative ideas piled up in a heap.
As a result, the development time is delayed, the player’s path is not built up and the game is simply not fun to play. Money is flowing away faster than planned, and the results are noticeably lower than expected.
To avoid all these problems, it is necessary to follow the universal rule of PPD – Processes, Planning, Documentation. Establish processes, plan development, keep track of your documentation. Good processes and documentation do not guarantee you success, but they make it much easier to make a good game and bring it to release.
The game design document plays an important role in this, because the game itself is created based on it. This article will help you avoid mistakes when writing a game design document, and if you want a detailed guide on how to write a game design document, visit this website.
How Best to Write GDD and What Problems will it Solve?
The main problem of most novice game designers, especially in young teams, is the desire to write everything in one document. Don’t do that.
A game design document is a collection of different small documents. Each document describes a fully defined mechanic or feature of the game and nothing else.
For the convenience of documentation, we advise you to write an introductory document, which will be a text version of the concept, which is expanded and describes the concept of a mechanic with links to the GDD.
Another important point – GDD discuss everything, but always 1 person edits.
- This will solve the chaos problem. Documents will remain in the same style
- This allows you to centrally track documentation changes
- Don’t create endless discussions, settle for one optimal solution
Update the GDD if, as a result of the development, the details of some mechanics have changed, and be sure to notify the team about this.
Where is the Best Place to Write Documentation?
Confluence is the best way to write documentation, but it’s paid and the commenting system is worse than Google Docs. An alternative option is Google Docs, they are free. You will have to completely do the structure of the documentation yourself, but Google Docs has an excellent commenting system.
Do not Forget About the Terms of Reference
Terms of reference (TOR) are also an important part of the GDD, in addition to the game logic, they describe in as much detail as possible all tasks for the game content – visual assets, animations, sounds, music, and so on.
The terms of reference will allow you to:
- Estimate the resources needed
- Plan production
- Calculate budget
TOR is often corrected during production, this is normal.
Remember Consistency
It is better to design UX (user experience) after the mechanic’s approval. First, write a User Story, a flowchart document that describes the player’s path through the game’s interfaces. It will help not only to estimate the volume of interfaces, but also to roughly estimate the architecture of the product.
After the approved User Story, make simple layouts without design, mockups. This will simplify the work of not only programmers, but also UI designers.
Reminder for GDD for a Game Designer
1. The designer writes the documentation not for himself, but for the team;
2. Don’t write everything in one document. Split GDD into different documents, with different features;
3. Maintain a catalog of documentation with links and a brief description of the documents;
4. Keep track of the structure of all documentation and within documents;
5. Description:
a. It is a reflection of the designer’s mindset;
b. Facilitates the perception of a large amount of information, spend time on it;
6. Visual references are your allies. Use pictures and even videos to show what you want to get;
7. Write and simplify. The less water in the text, the:
1. Your idea will be clearer;
2. Faster will be reported to the team;
8. Strive for unambiguous wording. If something can be misunderstood, it will be misunderstood;
9. The specific values of the parameters in the text leave the impression that this is an immutable constant. Note where the parameter is changeable;
10. Re-read the documentation 1-2 days after writing. It’s hard to see problems with a blurry look;
11. Keep track of the names of documents and files
12. Communicate with the team
a. Get feedback from them. It will help make your documentation better;
b. Listen to their ideas. Anyone on the team can offer great things for a project;
- Correct your documentation, keep it up to date;
- Don’t judge your documentation by size (number of documents, pages). In a six-page document there may be solid “water”, and the programmer will have enough description for three;
We hope this article will help you succeed in your work. Thanks for reading to the end.
The mobile game development process is very interesting, so go to Whimsygames now and check it out.