The Importance of Documentation in Small Development Teams

Game Design Documents

Video game development is difficult on many levels. It takes an interdisciplinary-combined effort to make something functional and aesthetically pleasing. When working in small development teams the urge to just jump in and start making the game is very apparent. However, making a game with no plan can lead to a huge disaster. A small idea can become a huge task very quickly. This is why game design documents are a crucial part of developing a game even when working with a small team.

But we can just tell each other everything…

It is very easy for a small team of four or five developers to undermine the importance of documentation because they believe it is easier to just talk to each other instead of writing it on paper. Working in a small team can lead to this belief, however, small teams must understand that even in that situation things may be misinterpreted or completely misunderstood. Anyone who has played the Telephone Game can attest to this.

The first step in creating a video game is putting ideas on paper. Writing them on paper makes the idea feel official and concrete. It helps the team visualize the idea while also creating an agreement amongst the team.

Using Documents as a Plan

Game design documents can also function as an agreement or contract of what the team will begin to develop. Documents such as the Product and Sprint Backlogs, Asset & Development Plan, Asset Database, and Game Design Document serve as an initial plan for the game the team will start creating. The team must first create the game on paper with detailed documents to make sure everyone on the team understands what kind of game they are creating. When the team creates a plan, it helps keep ideas from becoming huge tasks that are out of scope for the project. Writing documents about your game is not a waste of time. It actually saves time in the end because everyone on the team has a clear vision and is on the same page at all times.

But what if we want to change the documents or plan?

Most of the documents are “living” documents. A living document is a document that the team is able to alter throughout the development process. It is easier to cut a feature before the team builds it and therefore, the documents help the team see what to cut in advance. However, the Game Design Document is an overarching document that contains everything in the game. This document is a reference that team members can use in case they have any questions regarding the game. This is also the reason why the Game Design Document must be detailed enough to answer any question that may pop up during development. Consequently, there must be a point in which the team decides to stop adding features in order to make sure that the plan does not keep expanding.

Personal Experience

In the case of Tokyo Tempest, my first mobile game project created at Southern Methodist University, my team consisted of an artist, two level designers, a programmer and myself (artist/team lead). Since it was a small team, we were in constant communication and could just look up and have a team member’s attention in seconds. Additionally, all the information we needed was on either the walls (our tasks on the scrum boards) or documents. I stress the importance of documents in small teams because a team can save a lot of time by having documents that the team actually uses. For instance, in Tokyo Tempest, we had robots that shot projectiles in different patterns. The level designers gave each of the three robots a name based on the patterns. When it came time for the programmer and artist to create and program the robots, there was never any confusion because the level designers clearly planned and wrote down all the details for each robot on the Game Design Document. The team members have easy access at all times to the answer they are looking for without having to interrupt another developer or waste time waiting for an answer until the next workday.

In contrast, I have also worked in another small team that used almost no documentation while creating a game. Although we were able to get our game Greenlit on Steam, the development process was rough. There were many times when developers were confused and did not know what to do next. The confusion and miscommunication happened because there was no plan. We did not have a clear vision of the game and at times just added features when we thought they were “cool”. This is a huge problem because it quickly becomes a snowball effect and these “cool” features prevent the team from completing the game on time. At that point, the team has to either cut features or delay the game to compensate for the time lost. In my case, we had to delay the game a couple of months in order to have a stable release.

Therefore, if the team plans, makes detailed documentation and continues updating the “living” documents, everyone on the team should always be on the same page. If a team member has a question, they can always look at the documents to find the answer. Since the answer is on the document, there is less of a chance for that team member to misunderstand the answer.

In Summary

I have had the experience of working in small 4-6 person teams that have both used almost no documentation and very detailed documentation. In my opinion, documentation is a critical part of the game development process. Having detailed documents, to which any of the developers can refer to, is very useful when discussing features and skills in the game even if you are a small development team.