A Constantly Rewritten Bible
The GDD, or Game Design Document, is a strange object. Over the course of a project, a good GDD will achieve almost religious status for a team. It will serve as a single point of reference for all team members - an oracle of answers and a bed-rock of certainty when Production is in full swing with features are being implemented, broken, repaired, revised, ripped out, re-specc’d and retconned at break-neck speed. Though nothing is certain, a good GDD can provide clarity and focus, and serve as a rallying point for confused or burned-out team members to collect their thoughts. If a project begins to come adrift, reference to the GDD can help a Producer re-establish their goals and get the project back on course. All of this is doubly true in fully or semi-remote teams, where documentation is king, and a poor GDD can introduce legions of problems.
A GDD can be substandard in one of a number of ways. It might be too scant on detail, lacking the essential information a team member needs in order to get support and guidance on the asset/feature they are creating. This often happens when the lead Producer is overstretched, and they replace the GDD with their own self. “Just ask me if you need more info” sounds like a good idea in principle, but makes it inevitable that problems of communication will arise. Even if the Producer might communicate information flawlessly, it does not guarantee the team member will receive equally accurately! There is less change of miscommunication or misinterpretation if the idea is written in black and white.
The same is also true of an unstructured GDD. If a team member has to wade through pages of information they might miss something important, or not realise it was relevant. In poorly organised GDDs, or ones that have become over-stuffed with content, - perhaps functioning simultaneously as the GDD, the Art Bible, Lore Repository and Production notebook all in one - there is a high chance that features or assets will be incorrectly created. It is important to ensure the GDD communicates clearly, concisely, and only contains relevant information.
A Game Design Document that is based on ambitions, rather than concrete deliverables, is useless to team members. A GDD that is out of date is arguably even worse, as it introduces a version of the feature into the consciousness of the team members, but a wrong version, that will have to be corrected later. This engenders a great deal of ill-will from the team. As as far as they are concerned have done exactly what was asked and then it appears the Producer has capriciously changed their mind. An out of date GDD presents considerable risk into the budget of a project, and may even affect it's viability as a whole.
Therefore, it is vital to keep the GDD up to date, and to treat it as both a vital reference and a living document. The team should feel confident using it as a reference, but also be aware that it exists in a constant state of flux. Tracking where changes have occurred, and having a method for communicating those changes to the team members for whom they are relevant, is one of the key aspects of a Production role. This might be done through an email, or an update posted on a shared wiki, or simply a notification in the group Slack channel. Depending on the project, it might not even be necessary to proactively communicate that there have been changes, but any team member consulting the GDD should have complete confidence that the information they looked up in the GDD yesterday is still reflected in there today, though there may have been amendments or adjustments. A Producer should never attempt to use the GDD as an offensive weapon to trick or bamboozle a team member regarding a feature. A team member should never access the GDD only to discover that the outline of the feature they were working on has been removed or rewritten without their knowledge. The GDD should be a point for building consensus and establishing common knowledge, and when one is well-written, properly structured and proactively maintained, team members will come to rely on it to guide their work. A Producer should, and will, be judged by the quality of the GDDs they produce.
