What is in a Quest Design Document? This is the question of the day to which I found no satisfying answer when asking our friend, the internet. Thus there will be a little synthesis of existing resources and own thoughts, as always on this blog.
The second part will apply the results to my current Witcher quest design. I hope that this will centralize my ideas and enable me to provide others with something compact to review and give feedback on.
Purpose of Documentation
What is the purpose of documentation? A good design document serves as a concretization/implementation of the designers thoughts and serves as a basis for the concretization/implementation in the real world. It is a halt in between the mind and the final shape. That is why documentation is the place where a lot of preproduction may happen: It is usually more costly to do things right away in the intended medium instead of trying ideas on paper, with post-its, in digital documents, as a prototype, etc.
The second purpose is nearer to the original meaning of the word: Documentation is meant to provide the informations necessary to understand how its target works. Documentation thus at times also summarizes and abstracts.
The last major purpose I'll mention here is communication and coordination: Documentation serves as a hub for synchronization of thoughts between different members in a development team.
I have been thinking about and creating a quest design document structure with these thoughts in mind.
Quest Design Documents
A game usually has a game design document (GDD) of some kind, the software (which is of no interest here) has internal documentation in form of comments in the code base. Between the two there are things like level design documents (LDD), story bibles and character sheets. These are all artifacts that are not related to the code, but more detailed descriptions of elements that are in the GDD. They serve as places for selected developers/designers to work with and as a drill-down option for people starting from the GDD. Of that kind the quest design document (QDD) shall be, too.
As with all documentation, it's structure should be easily accessible and close to the structure of its target. Luckily enough, we already do have some understanding of what and where a quest is in the context of game development. Furthermore, I draw from a LDD that I made, interviews with quest designers at CD Projekt RED and a Gamasutra article on mission design. It will be adapted for quests as they can be found in games like The Witcher, The Elder Scrolls, Mass Effect etc. These are the informations that guided me most:
- it is similar to a screenplay, containing gameplay sections next to scenes
- it contains a chapter on playstyles
- it contains a chapter on themes/inspirations
- a quest can branch
- audio/visuals usually won't need a detailed description here
- the most central unit of a quest is the event - goals and locations are related and important
- pacing is important
And here is the QDD structure I thought of:
3 Backstory
You can see here that there's one major part describing the quest itself as it is meant to appear in the game and then there are some meta informations: overviews, highlightings of important aspects, entry points for other departments and progress tracking. Sections can be used to structure bigger quests and to handle branching quests. A single scene is a cutscene or a dialogue between two characters where occasionally choices are presented to the player. A gameplay section is anything that is not a scene and "in-game". To both three relevant questions cristallized while I thought about the informations to store in such a node.
The "What is?" question should be answered with descriptions of the current context: setting, characters nearby, atmosphere, gameplay options, player goals and some such. The "What happens?" question is probably most important, it refers to the changes that are caused by the game or the player: Environment changes, dialogue decisions, attacking a NPC, walking a path, ... "What motivates?" refers to the driving function of quests, they are meant to keep the player engaged in order to allow him to experience the game. Here oneay write about triggers, involvement, landmarks or guiding.
Enjoy the template I made for such a quest design document.
Further Reading / Inspiration
- The Questing Beast: A Q&A with RED Quest Designers Pawel Sasko and Mateusz Tomaszkiewicz Link
- Designing quests for The Witcher and Cyberpunk 2077 Link
- Creating a narrative focused mission design document: A Last of Us example Link
- A Level Design Document I made (Link1) and its inspirations Link2 and Link3
A "Witcher" Quest - Part 6: Quest Design Document
There is not much to say here, since I basically just followed my own instructions that I gave in the above texts and in the template. Here is the result. The most notable difference is probably the exact notation of the event/goal chain:
As you might notice, I dumped the Gameplay/Scene regular headers and incorporated them into the screenplay. I oriented in screenplays used in film, but didn't follow the exact formats often used there. Normal text like the one close to the bottom of the image is meta-information: It talks about goals, mood, the player and story construction. I also marked quets log updates, decisions and unfinished dialogue in a special way.
Ideas for Feedback
- What seems superfluous?
- Will it contain everything necessary for understanding (if I continue like this)?
- Is it easy to read/comprehend?
Conclusion
I've got a good feeling about creating such a document. The advantages noted above and my results of work confirm me. I would like to finish the QDD for "Wudmager" but I don't know yet how to connect such work with further posts here. We'll see.
Until then, have a good time!
No comments:
Post a Comment