Actionable Documentation for a whole development team, covering a new boss design of Hades

For my final thesis I am designing a late-game boss for the game Hades by Supergiant Games, as well as creating the documentation for an entire development team with focus on tailoring the documents to the needs and requirements of the different departments involved in building said boss feature.



Findings on Documentation & Department specific Requirements

Research & References


My starting point for research was Liz England's part of the  Rules of the Game: Five Techniques from Quite Inventive Designers  GDC talk. More information on the specific topic of documentation for and requirements of different departments is very hard to find so most of my sources are existing Game Design Documents and their structure, Style Guides, Technical Design Documents, VFX Workflows, and the like. Basing my findings on the personal experience of people who have worked in the industry for years seemed like the right thing to do, and all I could do, after all.
Due to the lack of proper lists and wishes to the documentation from the departments directly, I had to analyze existing documents with the assumption that they fulfilled their purpose and were well received by whomever had to work with them.
I am comparing all of the documents and findings to my own experience from the semester projects, and my own personal taste and workflows as a designer. Even if there are department specific requirements for the documentation, every designer works slightly different and I do believe communicating your own ideas and concepts in the way that's most natural to you, yields the best results in the end.

In addition to comparing documents, I watched talks and read articles about documentation workflows, types of documentation and layouts, best practices, and must-haves don'ts. Especially insightful was the  GDC One-Page Designs  talk that I revisited, as there was an in-depth comparison of a Design Bible, which was common practice in the industry for a long time, a wiki, which I personally like to collect documentation, and the One Pager which is a great tool to communicate the entirety of a game or feature to the team and any stakeholders.
With every talk and article, I found more keywords to look up and research to get different opinions on them instead of trusting only one source and my gut.
Most lead to more general tips again that would need to be adapted to the different departments but with the base of actual department specific documentation, it didn't prove to be too difficult.
Most of the department specific documents were written by said departments, so I also needed to work out what was feasible and even necessary for me, acting as the feature designer, to put into the documentation from a design point of view.

With all of these sources and additional steps in mind, I then summarized the requirements for each department, along with some thoughts of what kind of document and layout would work, what kind of information needed to be there, sometimes more or less specific to my Feature Design.


High Concept

A high concept is meant to give every department and possibly more stake holders an overview of the whole feature / design. As short, neatly structured document does a really good job most of the time, but a visually appealing one pager not only grabs everyone's attention but also showcases the entire flow and interactions of the design like no other document can. A word-style document still runs the risk of people skipping over parts or entire sections because they think it does not concern them, which makes understanding the design as a whole very difficult and might lead to assumptions and misunderstandings.
Still, a short summary of the design in the form of a design bible that contains only the most important information of each department and a good vision statement or design pillars is much better than not having a high concept, that you can refer to to check the vision and goals of the design, at all.

FDD

The feature design document is similar to a whole game design document, but it takes one element of the game and focuses on describing it in great detail, instead of glossing over the most important parts in fear of having a game design document that is several hundred pages, in the end.
The document encompasses all feature design thoughts and discoveries to show the feature in its entirety. Using a more typical game bible structure works very well here. Any parts of the game that are referenced in one FDD but explained in another need to be marked and linked. that way FDDs can be written in a way that assumes the people reading it know how all other parts of the game work without having to explain them again and again, in each document.
A wiki works well for a compilation of FDDs and department specific documentation. A changelog in each FDD is also a good idea to really highlight why which design decisions were made and how they worked out.


Level Design

Level Designers need to know how what spatial requirements are needed for the feature. For that, defining how the attacks work, how the bosses move, how the Player needs to move, and how tense the game is supposed to feel at that point, is essential.
For the Echidna, there were different requirements for each phase, but none that said that the level design cannot adapt to the phases, so I specifically noted that in the document. If the level designers decide to make use of a changing level structure or not, is up to them.
In liaison to the narrative designers, the level designers also need to know any story, setting, and lore specific information as that can drastically alter the shapes and assets they can use in the level design. If the feature is set in a place that exists already, it needs to be in accordance to it.


Engineering

For the engineers, it makes more sense that they get the information of the boss design in smaller chunks, neatly divided into parts, rather than the whole flow of the different phases and attacks in its entirety.
That's necessary for the Feature / System Designers and Level Design as they need to understand the pacing and how the phases interlock and how the attack interact with each other, but that's not as interesting for the programmers.
They need to know the building blocks first and the structure second. The structure can change, it can adapt to how the building blocks look like in the end.
The engineer document has a simple structure - most important and universal information like actors and an image legend first, attacks second, and phases and their sequence of events last. The attack sections all have the same anatomy - the actor of the attack, everything that the designers need to be adjustable in the engine, and then a description of the attack with images and examples for easier understanding, and some notes at the end how the attack interacts with others.

Concept & 2D

The concept art determines what the final 3D model looks like so the concept artists need to know what visual requirements there are for the gameplay.
How exactly these shapes are designed visually doesn't matter, but the artists need to know how the Echidna is supposed to attack and move and what needs to be telegraphed and communicated visually. Then, it's their responsibility to work with the 3D, VFX artists, animators, and tech artists who need to get it into the engine.
The concept and 2D artists need to know what assets are essential for the feature, like character portraits, props, or effects that need to be concepted.

VFX

The VFX department needs to know which part of the design needs specific feedback, which parts need to be loud and highlighted, and which shouldn't distract from the main part. They need a list of interactions and which elements behave the same, similarly, or completely different, as well as which parts of the effects need to be adjusted somehow, similar to engineers putting public variables instead of hard-coding everything.
For example, two attacks might be the exact same, but the area of effect changes size according to damage dealt. The effect needs to be resizable or the VFX artist needs to make two effects that are almost the exact same.
Two attacks might be very similar with only the exception of one being blockable while the other one isn't. If the effect is supposed to show that, the VFX artist obviously needs to know.
So it's best to list the characteristics and specific properties of each element and how they interact with other elements so that the VFX department can develop effects that are visually clear and communicate consistently what is happening on screen.
This is essential for good player feedback so it's the responsibility of the game designer to define what is important for each element.

Sound

Sound also greatly contributes to player feedback and game feel. The sound departments needs the same content of game element description to work with.
I need to treat sound as a separate entity from engineering. The engineer document focuses on the attacks, phases, and game feel, and adding the separate sounds for each attack, telegraph, and dialogue, would clutter the document. That's why I write the sound document with the assumption that this department will either implement the sound alone or communicate with the engineers, animators, tech artists etc to make it work in the end.

→ VFX & Sound Document

From a Game Design view, VFX and sound are very similar and the differences seem so little that putting information for both departments in one document won't frustrate any of them too much.
For the Echidna, all I had to do was describe the phase and attack telegraphing.
Breaking it into parts that need similar effects, both sound and visual, instead of outlining the entire fight and how the phases interact, seemed most logical as the effects should be consistent and read similar for similar type and impact.
To have this information displayed neatly, a simple structure is enough. I personally chose a presentation, power-point style, but a structured paragraph for each attack / type works the same.


Narrative

Most of the narrative work lies within the department, not in the hands of gameplay designers. Details like the Echidna family tree and mentions of Typhon that are already in the game are good to know but ultimately the responsibility of the narrative designers.
If the design calls for specific characters or settings, or needs to be incorporated into the story or lore in a certain way, it needs to be written in the document for the narrative designers.
A story board mockup, a comic sketch, or a rough script, alongside those points of importance, work best to communicate the needed sequence of events to the department.