上QQ阅读APP看书，第一时间看更新

It leaves space for creativity and debate

A game development team is usually composed of some very talented professionals. Creating documentation that doesn't leave any space for these people to express themselves through their work most certainly means that the team's potential will remain unexpressed.

This means that if you're writing about game characters, for example, you should limit your work to what is needed from a designer. Details such as how the character is dressed, how she moves, which sounds/soundtrack accompany her, might not need a formal specification and can be left to the artist's interpretation (unless those details serve some purpose in terms of gameplay and need to be directed by the game design). Likewise, even if you are a highly technical game designer, and though you may be able to write code yourself, you don’t want to tell a game programmer how to implement the code for a specific feature.

The idea is to communicate the intention rather than the implementation. Don't tell other people on your team how to do their job! Everyone in the team should be able and free to tackle the development challenges in the way he or she thinks is the best. It is highly probable that the same GDD handed to two different professionals will end up with the same result achieved in very different ways.

It's a matter of mutual trust; everyone trusts that your documentation is the design of a compelling feature for the player, so you have to trust that the team is going to do its best to realize it. For the same reason, don't expect to write a GDD and then just hand it over to the team and move on to your next thing.

Someone could raise questions or issues with something you've written, and these concerns have to be addressed and will eventually require an iteration on the document, fixing what doesn’t work or accounting for new, cleverer solutions.

Even more probable, these problems might not arise until the actual development stage, meaning that they need prompt problem solving on the go. This is very much part of how game design works.

Sometimes, it might happen that the actual implementation diverged from what was written in the GDD. Never think of the GDD as some sort of dogmatic instruction manual on how to develop the game. If the actual implementation accomplishes the game vision or even does something better than the original design, it's the GDD that needs to be changed, not what’s been implemented!