Game Design Document evolution

What is G.D.D.?

Many poetic metaphors describe the game design document: an architecture, a script, a sophisticated, detailed manual, and the anatomy of the project. A solid GDD satisfies a team’s need for:

• an integral vision of the final product
• understanding the detailed steps, the mechanics of how to reach the goal.

Here is your answer to the question of what is a game design document: a game design document sets the direction for the team. It helps to understand every team member’s task in this project while giving a detailed overview of the result.

“If anything, game development is even more of a team effort than making a movie, so for individuals to get credit for making a game is absolutely insane.” A high-quality GDD game design document is the best way to ensure a productive team can produce a truly great product.

Each of our games is built on a customer-oriented, adjustable, all-inclusive structure that guarantees its success from the start. So, what is a game design document?

A G.D.D. usually includes:

• Executive summary (game concept, genre, target audience, project scope, etc.)
• Gameplay (objectives, game progressions, in-game GUI, etc.)
• Mechanics (rules, combat, physics, etc.)
• Game elements (worldbuilding, story, characters, locations, level design, etc.)
• Assets (music, sound effects, 2D/3D models, etc.)

Here’s an example of a game design document created in Nuclino, a unified workspace where teams can bring all their knowledge, docs, and projects together:

Such platforms as Nuclino, Asana, Trello allows you to create long-form documents and organize them in a variety of visual ways. The nested list view is handy for organizing and collaborating on your game design documentation in real-time. The Kanban board view is great for prioritizing features and planning sprints. The mindmap-style graph allows you to visualize the links between different topics, levels, characters, and game assets like in a wiki.

Game Design Documentation 2022

Traditionally, GDDs have been detailed, 100+ page documents, which tried to explain every detail of the game upfront. As the game development process became more agile, the approach to documentation evolved as well. Realizing that overly lengthy and rigid GDDs are difficult to maintain and are hardly ever read, most studios have moved away from traditional design documentation.

Today, most game developers follow the agile approach to documentation. As Jim Highsmith, one of the 17 original signatories of the Agile Manifesto, said, “We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.”

So rather than doing away with game design documents all together, the documentation process can be adapted to support the creative, iterative, and collaborative process of game development.

The modern way of G.D.D.

4 rules of documentation

Documentation is “living” and needs to be collaboratively maintained by the whole team. To make the most of the time we invest in documentation, we follow a few simple rules:

1. Make sure it’s always “just barely good enough”(JBGE). Keep in mind that any document you create you will have to maintain later on. If the documentation is light, uncomplicated, and not too detailed, it will be easier to comprehend and update.
2. Write it “just in time” (JIT). Wait before documenting — it’s the best way to avoid accumulating false and outdated information. Produce documentation when it is needed, not before.
3. Keep it in one place and make it accessible. If documentation is only useful if it’s accessible. Store your product documentation in a place where you and your team members can easily find it.
4. Collaborate with your team. Maintaining documentation with the teams is a collaborative process, and every team member should be encouraged to contribute.

To make all of the above possible, a flexible, transparent, and easily accessible software documentation tool is needed. Unable to find a solution that would tick all the right boxes, a few years ago our team decided to scratch our own itch and build a better tool ourselves.

As a result, today we manage all documentation using Nuclino, Asana, Trello, or any other relative platforms, a unified workspace that serves as our internal wiki, sprint planning tool, and collaboration space — like a collective brain.

When to document

The iterative delivery of working software in Agile effectively replaces much (though not all) of the comprehensive upfront requirements documentation. The idea is to keep documentation as simple and lightweight as possible, especially during the early stages of the project. So at what point is it worth investing time in documentation?

A common agile practice is to defer the creation of all deliverable documentation as late as possible, creating the docs just before you need to actually deliver them. For example, system overviews and support documentation are best written towards the end of the software development life cycle (SDLC). Essentially, this approach is to wait until the information has been finalized before you capture it.

Another Agile documentation strategy is to document continuously. You write your deliverable documentation throughout the project, updating it as you update your code. This approach is in line with the Agile philosophy of always producing a solution that is potentially shippable.

However, because the requirements are likely to evolve over the course of the project, it takes a considerable amount of time to keep the deliverable documentation up-to-date. From the Agile point of view, this is “traveling heavy”.

In practice, Agile commonly put off writing documentation until they have time to do so, in effect moving towards the document-late practice even if they initially decided to document continuously.

What to document

Examples of possible documents used in Agile documentation include case studies, diagrams, tables, and sitemaps. Here are some of the documents you might want to consider creating over the course of your project:

1. Product vision. It’s a description of the core essence of a product and a summary of the current cost estimates, predicted benefits, risks, staffing estimates, and scheduled milestones. Keep it short and to the point. Use bulleted lists.
2. Project overview. This is a summary of critical information relevant to the project, such as primary user contacts, technologies, and tools used to build the system, etc. Use it as a starting point for anyone new to the team and maintain it throughout development.
3. Design decisions. This is an overview of critical decisions related to design and architecture that the team made throughout the project. Document your design decisions throughout other artifacts, such as system overviews and source code.
4. Documentation related to operations. This usually includes information about the dependencies that your system is involved with, backup procedures, troubleshooting guidelines, etc. There is probably a standard format for this type of documentation in your operations department.
5. Requirements documents. It’s an overview of what the system does, including use cases, user stories, or essential user interface prototypes, etc. Aim to capture the requirements as executable specs.
6. Support documentation. This includes the training materials specific to support staff, trouble-shooting guides, etc. Like the operations department, the support team may have standard templates or examples that you can work from.
7. System documentation. Provide an overview of the system, including technical architecture, business architecture, and high-level requirements. It helps ensure that if the development team leaves, critical information is left behind.
8. User documentation. It includes reference manuals and support guides for the users. Keep it simple and easy to understand. the solution design is flawed if you need to extensively train your users on how to use it.

Initial planning

Ιt’s time to dive into the actual planning.

Keep in mind that whatever plan you come up with shouldn’t be immediately set in stone. Game design is a highly fluid process, and your plan needs to reflect that. A game development plan tends to be a living document that changes as you identify new requirements or tasks, finish things early or late, and learn more about what you’re building.

Game planning begins with the creation of a game design document, which will serve as a blueprint for your game throughout its development.

Here are the questions you need to answer to understand the core game concept:

• What is the core concept of the game? Can you describe it briefly?
• What kind of video game is this? Is it in 2D or 3D?
• What should it have as key features?
• What is the story’s plot? At what time and where does it take place?
• Which audience do we want to reach?
• Which platforms will be supported?

It may not always seem like it, but ideating and answering these basic questions is one of the hardest parts of the game development process. This information will serve as the backbone of your entire project.

Proofing your game concept

The next step is the proof of concept. At this stage, you need to determine whether the ideas you’ve generated are viable. In order to do that, answering the following questions can be helpful:

• What is our budget? How much do we expect it to cost to develop this game?
• Do we have the technological capabilities to build it?
• Which gaming engine will we use?
• Who will be on our team? Who will be responsible for what?
• What is our estimated development time frame?
• How will we monetize the game?

If you are a part of a big game development studio and are planning to build your game under the umbrella of a publisher, then thoroughly proofing your game concept becomes a vital step that needs to be completed early on. You will need to give your publisher a clear overview of what they can expect and get their approval.

On the other hand, if you are an indie game developer working without publisher oversight, you can usually afford more flexibility during this stage. A detailed proof of concept may still be required if you are relying on crowdfunding websites like Kickstarter.

Creating a task backlog

The next step is to determine the requirements of your game. Then, each requirement will need to be split into a list of supporting features. In turn, each feature will need to be further broken down into tasks for each department, including programming, art, animation, level design, sounds, and so on.

A good technique for capturing requirements from the perspective of the player is to write user stories. A user story usually takes the form of a short sentence, written in simple, informal language, for example:

• As a player, I want to launch the main menu so that I can start a new game.
• As a player, I want to change options so that I can tweak/update my play experience.
• As a player, I want to save my progress so that I can pick up where I left off later.

Conclusion

“We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.”