Workflow - Thesis & Design
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.
Introduction
Inspiration & Motivations
Comprehensible and actionable documentation is a huge and important part of Game Design. Communicating new features, their elements, and why they're designed like this (and then iterated), to the team and the developers who will actually work on realizing these designs can be just as crucial as the design itself. If you're working in a team you have to filter the relevant information for the people who work with you and present it in the best suitable way.
My main inspirations for this topic are my personal experience during the student projects where people rarely read a full GDD but might read shorter FDDs and documents with pretty pictures on every page, and a GDC talk by Liz England where she talks about writing documents that fit the department and even the individuals working with these papers in the end.
I'm interested in developing these workflows since I believe that making your ideas understandable is the responsibility of the speaker / writer even more than of the listener / reader. Misunderstandings don't just lie with the listener or their inattentiveness. It's up to the speaker to not only express what they mean in a clear and comprehensive way, but also to make this information as interesting and relevant to the listener as possible. That means cutting out unnecessary clutter and adjusting the way of presentation so that the listener can act on and work with the information given.
Additionally, I really enjoy working with people and their respective field of expertise. I strive to gain at least surface level knowledge of all parts of Game Development and projects, and, if I can't achieve that, I want to at least know how a team and its members work best and support them like that.
Still, my main focus, other than teamwork, is System Design and more specifically, Feature Design. I want to create features that fit perfectly into already existing Game Systems. That's why I want to design an extra feature for a game instead of just reverse engineering documentation for a finished one. Also, creating a new feature allows me more freedom in the documentation, as well as forcing me to think more broadly about what information is relevant for each person / department since I don't already know all the details of the finished element of said feature. I need to put more information in and really evaluate what is important for the person to know and what is just overwhelming clutter.
I've chosen to design a late-game boss for Hades by Supergiant Games. The Echidna can tie into the game both narratively and as a challenging opponent. The fight uses a variety of modified combat patterns known to the player from other enemies in the game, as well as a few new moves.
I'm using this mix of attack patterns since the Feature Design isn't the main part of my final paper for the S4G School for Games but builds the base for all my further documentation work.
Planning & Time Management
During the portfolio time, I decided on a topic and finally on a game. I had a hard time choosing between designing a boss for Metroid: Dread or Hades. In the end, I went with the one I felt I could write more documents for and have more flexibility in the design and didn't have to define every single move of the player for. Due to Hades' rogue-lite design and the fact that the player does not have a set move-set at a certain point in the game or even run, I chose that game.
I set up a rough timeline divided into the five weeks we had for the final thesis, giving myself time for
Research for combat and documentation,
the actual boss design,
the first feature design documentation,
the department specific documentation,
and the thesis on department specific documentation, as well as my workflow documentation.
I put all of that in a kanban board on the same miro board. Using an extra trello page would have worked as well but I like to have everything in one place so I don't simply forget about it and so that it's easier to change and add things without having to even open another tab to do so.
At first, only the points from my timeline were in the kanban board, but as time went on, I split them up into smaller part. As department research was part of my plan, I wasn't even able to make a fully detailed plan from the very beginning and instead gave me a lot of time for "Department Documentation" and broke it down later on.
Also, having all the different sections of my workflow documentation and thesis in the board at the end gave me not only a better overview of what still had to be done, but also motivation as I could check a box every time I finished a chapter, rather than one big box that could only be checked after several days of work.
Motivation, I struggled with a lot. i followed my time plan easily until I had the feature design done and mostly approved in a coaching that I asked for. At that point, I had started the Engineer document instead of the final FDD though. I weighed it equally and was actually glad as writing a document for a different department early on showed me some issues which I could easily fix.
I didn't find the motivation to make my messy miro board into a neat design documentation for the longest time. I had also planned to make a high concept early on, but the missing FDD threw me off as I couldn't tell which parts were important enough to make it into the high concept.
Overall, working alone on a theoretical feature with no way of testing it and very little feedback made it hard to make myself make design and documentation decisions.
As I was looking more into different types of documentation, I decided I might as well make a presentation-type documentation for the VFX department, made it for both VFX and sound, and with this small document, I got back into the flow of working, as it gave me a little taste of success after a long time of struggling and not finishing anything.
I decided to cut the QA document and meant to cut the high concept as well, but made a rough draft for the it instead, during a writing low, which I was quite happy with, for a first idea of it.
In the end, I started the FDD pretty late, but managed to get enough content for the narrative doc, concept & 2D one, and the level design document, all of which I had put at the end of my list of priorities.
Re-prioritizing helped a lot as it got me to focus on the most important parts again instead of stressing about all of them.
Research & References
Combat
After having a rough idea of what kind of fight i wanted to make, I looked for similarities and differences in the game I was making it for.
The Hydra is a big stationary boss and the Hydra and Hades both summon additional foes. I liked the way Charon summons shadow clouds that move through the level in a different way than the foes the Hydra and Hades call so I wanted to apply that to my summon attack as well - the Echidna summons her children that are already in the game and known to the player, but their behavior is altered for novelty, and also to make the fight more balanced.
Another reference goes along with my initial idea for the boss. In two of the four phases, the Snake moves similarly to Classic Snake. That's not only a good reference but also good for explanation and clarity sake.
In general, I designed the boss with Hades as an avoidance-based system in mind. Finding this term helped a lot with thinking about the bosses' move-set, player challenges, and to really understand Hades' combat design and design pillars, as well as design decisions concerning the attacks and pacing.
Another great reference were articles that spoke more generally about types of enemies, boss behavior, and player challenges.
Documentation
For research about different types of documents, I watched multiple GDCs, read articles about best practices, and looked at a lot of existing documentation as well, from high concepts, design bibles, to VFX guidelines and art bibles.
Taking rough but structured notes on a miro board helps me the most as I can dictate the structure of each topic and even source myself and memorize and understand it best.
Part I - Feature Design
Design Ideas & Phase Blockouts
rough idea with the image of the echidna i had in my head, the snake leaps were kind of the USP for me, and then magic use in the other phases. Summons cause she's known as the Mother of Monsters and her mate Typhon and his offspring even get mentioned briefly in the game.
I started with a rough outline of each phase with little regard to proper naming, just to get the first ideas out and to be able to iterate quickly. In the last row, I wrote down questions that needed to be answered by either me or left open for the other departments.
Phase Detailing & Design Decisions
From there on, I wrote down a more detailed description / idea of the attack. I quickly noticed I had to take a step back and describe the attack high level first. Analyzing how an attack works high level, how small design changes can make an entirely new attack that requires different interactions and player decisions brought me to the final attacks and gave me a more balanced and varied move-set for the boss.
A little bit of more clean up of the images to put them into the documentation where they are supported by more text and structure, which then looks like this:
I still consider this part of the feature design, even if it goes into documentation a lot. Having a design that is clear and structured also helps you as the designer see if anything is off or if it could work that way.
Some design details get apparent while writing (or thinking about) documents for other departments, for example how attacks interact with the environment.I thought I could either leave that out or up to the level designers but they also have to know which attacks get blocked by obstacles and which don't. Zagreus can hide from petrifying stones behind a pillar that blocks them but if a floor swipe goes right through that pillar, it might be in just the wrong spot for Zagreus to not get stuck there while trying to dash through the attack. Maybe not a pillar, but walls, or Styx pools and rivers.Erebus sounded like a good choice since lots of dashing is required in this boss fight and you don't take damage in the River of Blood, but you also cannot step on it so dashing might actually prove a problem. At least you can walk on the magma for a little bit.I still think it would be more frustrating to gradually lose small chunks of health to the magma just because you cannot change the length of your dash dynamically, but it's something to consider for level design. Something less organic in shape might work well, like the Soul Catcher mini boss room. The Echidna appears instead of the Hydra in Asphodel so the magma fields would also make sense but the fight is already very tense and filled with environmental attacks and changes. A stage that changes with the phases is also possible and not unheard of in Hades. In the end, this would be a collaboration with level designers, for now, I can just show fictional ones the design and requirements per phase.
The pacing of the entire "sequence" (boss fight) and the different "beats" (attacks), and "scenes" (phases), is really hard to design in its entirety without stringing the beats together in the engine to see how the scenes work in themselves and with each other.
I only defined the beats and which beats are in which sequence, but not how the beats follow one another, how often a beat occurs in a scene or which beats can follow each other or block one from happening next. I would have written that in the QA & Testing Goal document but defining specific questions that need to be answered during playtests at this stage of the feature design doesn't only seem hard to do but also quite unnecessary as so many questions will come up and be answered during prototyping and the first few iterations in engine. The sequence is designed, the content of the scenes is determined, and the individual beats are there, but some in-detail design decisions have to be made later. It would have felt too much like guess work to me, at this stage.
In the end, I did define the rough pacing of each beat and showcased how they could overlap and how that affects the pacing. It is very rough but still good to have in a first documentation, even if it needs to be overhauled later on. Seeing the scenes and the entire sequence in action can always prove or disprove any theories made beforehand, but that doesn't mean that making assumptions or plans before is any less useful. The scientific method applies to game design as well, after all.
Part II - Documentation Process
Initially, I wanted to start with the High Concept for all departments and the FDD, a cleaner and structured version of my brainstorming miro board with all the relevant information for this Feature Design.
Instead, I wrote the Engineer Document and it helped immensely. I got a different kind of view on what kind of information any documents about this boss fight need, how much I had to put myself in the shoes of the other departments (not too much, I'm still writing design documents, just for people with a different expertise), and it even showed me some design flaws or simply decisions I had to make that I hadn't thought about before. The engineer document is still very straight-forward so all I did to make it nice to look at was to make clean infographics, call-outs in the document itself, and tables with the most relevant technical information.
The High Concept is just a draft as it would take a lot of time to make it clean and visually sound, but the concept shows approximately how it would look like.
I'm writing the whole documentation in slite so any kind of formatting and page breaks are mostly out of my hands. It is meant to be viewed in slite and I personally really like the endless scroll as descriptions and images aren't broken apart by page breaks. If I were to print the documents, I would put more work into formatting to make sure it works as a physical product as well as it does digitally.
During the entire documentation process, I was constantly fixing phasing to prevent misunderstandings.
For example, I changed 'horizontally extending thin cone shaped waves' to 'horizontal thin cone shaped waves' as it fits better since the waves aren't extending over the course of the attack.
Part III - Thesis
As there were very few references and sources on documentation for different departments and maybe even cases of designers doing so, I was struggling to write a whole paper on my chosen topic. All findings seemed superficial and more like personal opinions than scientific facts. My notes for each department were short and not very exciting or even insightful. Still, that seemed to be enough - personal opinions are formed through personal experience so I felt confident in trusting engineers who had worked in the industry for years to talk about what they like to see in documentation made for them.
Style guides from concept artists, feature design documents from feature designers, and whole 300+ page game design documents with a good structure that were passed from veteran game designer to veteran game designer were indirect sources that I had to analyze and come to conclusions about department specific requirements myself. Again, I didn't find anything mind blowing or too complex, it actually enforced my initial thoughts and assumptions more than anything.
Getting away from trying to butt into every department and do too much of their work for them also helped a lot. I don't have to cite every time a character appeared in the game in my document for the narrative designers. I can trust that they keep tabs on this information. I don't have to make a rough level layout for the level designers, I only have to tell them how the attacks work and interact with objects, and they can take it from there.
This didn't only help for my documentation process, but also the thesis part. Findings for my documentation process and the thesis go hand in hand as I'm making documentation with the findings for the thesis in mind and I find things for the thesis while writing documents. I really noticed this when I was thinking about the requirements for the sound department and the VFX department. From a feature design view, they are very similar, almost identical. So I made a document called "Echidna Attack Sequence" that describes each attack and telegraph, all of which needed some sort of sound and visual effect at one point.
Summary and Learnings
Most importantly, to me and my ambitions, is the conscious discovery that while I am definitely writing documentation for other departments, I'm still writing them as a Feature Designer.
I am and always will be interested in a lot of parts of game development, but that doesn't mean I have to, or even should, do others' work for them. Not only would that be infuriating, I am also not the expert of these other departments and my over-designed documents might actually hinder better ideas and workflows that I couldn't even think of.
All I need to do it work out what is important from a Feature Design / my department's view, and communicate it to the other departments in a way that is clear, structured, and, best case scenario, fun to read. Or at least not completely exhausting and frustrating to try and understand.
Making documents fun to read and visually appealing takes a lot of time. I never claimed it to be feasible, but documenting a single feature as detailed as I have now, is not realistic during a running production. Especially in a game like Hades which was under tight time constraints during most of the production, due to it being in early access for most of it.
Documents don't actually contribute anything to the final game.
They're a communication tool, nothing more. The effort and time that goes into documentation must be carefully weighed against all other tasks at hand. They might safe a lot of time later on as they are a great defense against miscommunication and misunderstandings, but they also easily eat time as they get bigger and reworked again and again. It's a tricky balance and not always predictable.
Still, I believe it's always worth it to put a bit more effort into documentation. It makes more people read more of it. It makes baseline communication about a feature, or a whole game, much easier for the entire team. All Game Design Documents are living documents, they will be outdated before you know it, and yet, even having read a bit more of an old document than usual makes conversations about design changes so much easier as there is at least some kind of knowledge to compare new information to.
Additionally, I love to work with and for other people and not only to solve problems when they occur, but to try and prevent them altogether. It is not the sound department's task to understand a document written exclusively for programmers, it is my responsibility as the creator of a full feature to make it clear to everyone working on it. If we all have the time to iterate on all elements of the design until it is like the designers intended it to be, no problem, but iterations cost time, money, and nerves, so answering as many questions as possible before they are even asked is a success in my book (or document).