A flexible approach to design documents

I used to be a huge advocate for extensive, detailed design documents. I even made a comment in my NightFall Post-Mortem document about design docs:
If a developer has to ask you things about the mod other than your opinion of work, you haven’t done your job as a designer. A design doc should outline EVERYTHING a person needs to know when joining the team.
This sentiment tends to be echoed around alot of forums that I used to frequent, although perhaps not quite to that extent. At the time, I believed it was a sound theory – you’re not always around for people to ask you design questions, and hey, things should be written down so they’re formalized in some way.

However, with a few more projects under my belt, this is probably one of a few ‘Lessons Learned’ that I’d like to revisit. Traditionalists, universities and many others will mandate that you plan every single little detail for your game or mod, even down to firing rates for weapons, health for enemies and many other small things. This is a great lesson to teach to game design beginners, as it forces them to think about every aspect of the gameplay. All these values need to be set at some point in time, and its best that its been thought about before you come to setting the value in your code. But is documentation of every single one of these values really necessary?
Its no secret that design documents become outdated fairly quickly – or at least once you get past the first stages of developent, and especially when you get into testing and balance. All those small values you came up with for health and firing rates will generally be wrong once you start testing the balance of your game. Features get prototyped and tested, and end up being not as fun as you thought. Smaller features that weren’t specced out in your design will end up playing a larger part in your game than was anticipated. Design is dynamic and flexible, yet we enforce the use of design documents that are neither dynamic or flexible. Design documents just become another piece of documentation for someone to update whenever a feature changes. Or, even worse, it doesnt get updated and reflects the product incorrectly.

In my final year university project this year, we were provided with very little documentation or gameplay concepts from our client. This led us down a path of having to flesh things out as we were doing them simply so we could keep up with the course work and not ask too much of our client at once. I’m not trying to advocate making a game without a design document – this was something that was unavoidable for us. We did have an overall product vision, and a client who knew what they wanted. But the specifics of these ideas weren’t written anywhere, and a requirements spec was a document that was required for the subject. The upshot of these problems is that we approached the design of the product in a much more dynamic way. We took an agile approach to our development – listed the main features, a dependency chart, and defined milestones. It was fairly traditional agile methodology.
At the start of each of the milestones, we wrote the design documentation for the planned features. Not in one large document, but as individual design ‘spikes’, if you will. Every major feature had its own document with the plans relevant to that milestone, reference links, required art, UML diagrams if required, etc. At the end of each milestone, these spikes were filed away in our wiki, and new ones for the next major features were written. If a feature was being expanded upon, the previous spike document was simply linked to as a reference. Not only does this minimize the amount of modification required to one full design doc as the product evolves, but iterative documents referencing previous ones maintains a nice log on what changes througout development.

At the end of our third milestone for the year, this approach has worked extremely well for our team. We’ve written enough design material to formulate a full requirements specification to meet the subject requirements, been flexible for a challenging design and ended up with a product of the same quality if we had a full document to start with.
Of course, there are limitations to this approach. As I said before, it isn’t a mandate to scrap a vision document. Keeping a few-page document with the core features of your game up-to-date is important to keep yourself on target for where you want to go. Each company, team or individual will have their own thoughts on exactly how much should be documented, and having worked entirely in an informal environment, design elements that are seemingly small, or the sole responsibility of one individual tend to just get done and not documented.

One example of this is ‘the numbers game’ – or game balance. This is an area of development I’ve never been heavily involved in. In Age of Chivalry, it was the responsibility of one designer, who played the game the most and had the most contact with community. It was an approach that worked fairly well, but his changes were rarely documented and nothing that anyone else could comment on. The game was no worse off for it, it still played great and ended up being pretty well balanced after a few patches. But the process and reasoning behind the numbers that he came up with, the other developers had no knowledge of.
Whether this is something that is significant enough to document, and whether the ‘design spike’ approach would work for it, remains to be seen. But this process is something that has worked for our project team, and is an approach I’ll be trying out with future projects.

Leave a Reply