In this essay, I will spend a few paragraphs on a subject I’ve become intimately familiar with as a player, a tabletop game master, and a videogame developer: quest systems in games. There are no universal solutions for the game team’s challenges as they develop their project. So, I won’t go into implementation specifics. Instead, I will offer some guidelines and lessons that I’ve found through my experience working on multiple AAA titles, indie projects, and even gamejams over the past 12 years.

1. Introduction
2. What A Quest System Does
   1. From A Technical Perspective
   2. From A Creative Perspective
      1. Diegetic Vs. Not (aside)
      2. Analogue Systems (aside)
3. What a Quest System Needs
   1. Consistent Rules
      1. Design Without Intent (aside)
   2. A Holistic View
   3. Technically Speaking
   4. Platform Perspective
   5. Shared API
4. The Lessons
   1. 1. The quest system’s structure shapes the designers’ ambitions.
   2. 2. The quest system is best conceived as a scripting framework that interacts with other systems.
   3. 3. Avoid incremental solutions to structural problems.

Introduction

A game’s quest system is the mechanism that carries the player from the beginning to the end of a game. Its name will differ between teams and projects, with some games calling it the “game mode”, the “mission system”, or the “gameplay manager”. Sometimes it’ll be the conjunction of several systems working together instead of an explicit, structured set of functions and variables. In either case, it’s the collection of the game’s states, its rules, and how it enforces them. Going through a dungeon, holding the line against intergalactic invaders, or stamping passports at a border crossing are all different gaming experiences. The rules of their games govern all of them, and a player’s actions will drive the game’s state one way or the other. These are the elements that a quest system manages. As a result, the quest system of those games shapes each one of those experiences, contextualizing them. It’s what makes gameplay have an emotional value for the player. 

This goes beyond simply listing the goals the game wants the player to accomplish; the quest system controls the state of the game in its entirety. It also may not be a distinct system of its own; it can be multiple systems separately from one another, accomplishing the same functions.

In addition to shaping the experience of playing a game, that structure shapes the ambitions of the designers who create content through that system. Designers will always seek to make the best game possible, and their tools will define the boundaries of what is possible. The tools designers have on hand define the starting point for their ambitions. That starting point, in turn, determines what the possible end-points for that ambition can be.

What A Quest System Does

As I said before, in this definition of a quest system, it’s the mechanism that manages the game’s state. It tracks the actions of the player(s) and reacts to them in whatever way the designers have prescribed. As such, the quest system is what gives the gameplay loop its structure — how the game starts, which of the player’s actions push the game to its next state, and how its rules are enforced. It is what makes the player’s actions matter in a mechanical sense. It’s what decides whether a player who manages to beat a challenge with their dying breath can move on to the next level, or be greeted by the game over screen.

During a game’s development, it also has another purpose, to shape the creativity of a game’s designers. Unlike a cutscene or combat system, the quest system’s influence reaches across to all the other creative disciplines because it’s the one system that responds and engages them all. This makes the development process of a game’s quest system particularly important. It’s a focal point for collaboration between designers and engineers due to its relationships with everything else. 

The development of a game’s quest system — the way that it hooks into new features, how it addresses common problems, and how flexible it is even as it’s being built — will be a major factor in what a team thinks they can accomplish.

Baldur’s Gate 3 provides a modern example of this interaction of multiple systems collaborating to deliver on the promise the game makes to provide deep, meaningful choices. We can see this in action when the game gates certain lines of dialogue behind the players’ attributes like class or species, by actions they have taken in the past, and even by who is in the party at the time. There we can see the game’s state is governing what choices the player can make and then triggering the consequences for those actions through its systems.

From A Technical Perspective

A game’s quest system is a state machine that can respond to events from other systems, uses the game’s rules to define the transition between its states, and responds to those changes by triggering events. It tracks values that designers have deemed as significant for the game’s experience and are connected to elements of the game world, which the game’s other systems manipulate. Those values are modified when the player takes certain actions or accomplishes goals in a way that one of the game’s other systems can detect. 

As an example, a game can track whether the player has arrived somewhere in the game world. That value can be tied to an invisible box placed in the world that broadcasts a message whenever the player enters it.

In this case, the game’s collision system sends a message that the quest system receives, and modifies a tracked value in response to it. As another example, a combat system could report that a particular entity has died, and the quest system could be tracking that specific entity or entities of its type and would advance a mission as a result. The response from the quest’s system to those changes could load a new level, trigger a line of dialogue, start a cinematic event, etc…

Thus, a quest system serves as an interchange for all the game’s other systems. It is also a system that executes sequenced events and logic, which implies some kind of scripting framework that designers could use to shape players’ gameplay.

However, during a game’s development phase, the quest system’s primary purpose is to allow designers to create the game’s rules with as much flexibility as possible. This is why commercially available game engines will have a distinct scripting language or toolset that’s separate from the game’s source code, operating a higher layer of abstraction. This is also the layer that quest systems most often operate at. That scripting framework is there to allow designers to create the game states, rules, and transitions that will shape the game’s experience.

Whether it’s included by the engine as default or not, that layer is where the game’s experience will take form. That layer should have hooks to different systems, and they will have to evolve throughout development. The client for this layer will be the designers, while the client for the game as a whole, will be the players. As engineers tackle the work of developing a quest system, they have to consider the experience of both.

From A Creative Perspective

The quest system is the thing that shapes the gameplay experience and contextualizes the player’s actions. It is what poses challenges and grants rewards to the player. It is also the system that decides whether the player succeeds or not. Because of that, it’s an important driver of a player’s emotional experience with a game. 

The reason why is that, for a game to have any structure at all, there must be a system that can track the player’s actions and respond to them. The quest system creates the flow that puts the player in a specific context governed by the game’s rules. And, as the player takes action,  it’s the system that makes changes to the game’s state, based on the player’s action. That flow is also the structure that drives a player to reach the next level, beat the high score, and affect the world of the game.

It’s important to keep in mind that the quest system can be a collection of different mechanisms working together. In some games, it’s a set of functions that are distributed across multiple features that act in concert with one another. In others, it is a standalone system that has a set of specialized functions to drive the player’s experience. In either case, its purpose will be the same, to make the player’s actions have consequences that matter.

Diegetic Vs. Not (aside)

A game’s quest system can be entirely diegetic, interacting with the player in ways that don’t step outside of the game’s boundaries. Games can guide players through more subtle means as well, without having any explicit elements like UI or dialogue that tell them what to do. Instead, designers can shape the world in such a way that players don’t realize they’re being led to their next goal.

Any MMO with a conventional quest log would be an example of a non-diegetic quest system. Journey and G.T.F.O. would be good examples of games that use a diegetic quest system to great effect, with their visual languages and themes. Note that UI itself can be diegetic as well, and the player’s scarf in Journey fulfills the same function as a player-level display.

Analogue Systems (aside)

In card games, dice games, etc., a game master or card dealer would carry out the functions of a quest system. Some games have a more structured way to do the same. Snakes and Ladders, Monopoly, Risk, and almost any other board game are examples where the quest system has a physical representation.  Designers operating in those spaces have a lot of the same concerns as videogame designers. 

Analog designers also define tracked values and game states, shaping gameplay experiences. In their case, they also have a separate concern; they have to take into account their player’s math skills and attention span. The players themselves, in those cases, are the “implementation” of the quest system. In those cases, the rules and meaningful values that apply have to adapt to the system enforcing them. A computer doesn’t tend to care if it’s tedious to calculate however long it takes for a large group of players to accomplish a complicated goal. On the other hand, a human can intuitively see how elements relate to one another without a specific rule.

What a Quest System Needs

Next, I’m going to offer you a perspective, and some guidelines, on what a quest system needs. This is not going to be a set of technical requirements or a rigid set of steps you should follow. Rather, I’m going to show some of the common patterns I’ve seen in projects I’ve worked on in the past, propose better patterns, and explain why they’re better. 

First off, this is the typical set of steps a team will follow as they’re developing a quest system:

1. The system’s structure will be defined.
2. An initial implementation of that structure will be built.
3. Content using that system will be created.
4. The system will be, to some degree, reworked.
5. Content will be revised, reworked, and maybe discarded.

This process can be intentional or improvised. It can be an engineer creating a new file and tossing some variables into it on a whim. Or, it can be the result of a long vetting process. Either way, these steps will typically happen. Steps 3 to 5 will continue to repeat until the team decides to stop, or they run out of time.

Whether the quest system is strictly defined as a stand-alone mechanism, or it’s a system that emerges from the interaction of several others, these steps will be largely the same.

A quest system that is implicitly sketched out in the way other systems interact has a lot of moving parts. If there is a problem with the overall experience of a game when the individual components are accomplishing the project’s goals, it’s harder to find the root of the problem, and harder still to solve it because it’s happening in a system that doesn’t exist on its own. Plenty of games, especially those offering simpler experiences, get away without having a purpose-built quest system. But, as a game’s complexity grows, the vague relationships between systems can become an increasingly difficult problem to solve. The first sign of trouble is a system, and it’s most often the UI system, constantly having to control the game flow. When the UI system is the system ending the game based on a value it’s supposed to display, consider the rules of the game you’re developing.

My recommendation, based on my experience, and regardless of a project’s scope will always be:

1. Define the basic game rules first. 
   • What does winning and losing mean in the context of our gameplay mechanics?
   • When a player loses, where does the game flow take them? What is encouraging the player to try again?
   • What are the tracked values in this game flow?
2. Define how your game systems are going to interact with one another. 
   • How are you tracking the relevant values?
   • How will those systems trigger events?

Consistent Rules

The rules should be defined as early as possible so that they apply to as many mechanics and interactions as possible. They capture the core of the gameplay experience the project is aiming for. We should expect that those rules will evolve as the project develops, but it’s important to understand that there is a cost to such changes. Consider whether those changes will align the system and its rules closer to the project’s goals, and weigh that against the time you will need to make that change. 

A quest system works best when it supports a specific design with goals and rules that are well understood.  The first step towards that is to establish the expectations, affordances, and limitations of your design. Try to determine what is in scope and what isn’t. Having clear goals, while understanding that they can shift as the project goes on, will allow you to develop internally consistent rules.

For example, it may not matter how the adventuring party defeats a dragon at the heart of a dungeon. What matters is that the dragon is defeated. The quest system should not try to account for every single game mechanic if it doesn’t need to, it should only care about whatever supports the design’s gameplay goals. Designers can define what it means for the dragon to be defeated according to different systems, and their report to the quest system should be as good as any other.

A properly scoped design, with clear gameplay goals and rules to match, makes it so that the gameplay experience you’re creating feels complete. Armed with that, your quest system can be robust and flexible enough to allow designers to create a large variety of gameplay mechanics. A quest system that doesn’t have that internal consistency will make it harder to develop new gameplay mechanics, as well as iterate on existing ones. The game’s design should only care about the exact value change that will change the game’s state, dictating what the quest system cares about.

Design Without Intent (aside)

If you design a quest system in a vacuum, without a clear idea of what the gameplay experience it’s intended to support, two things can happen:

The quest system will end up shaping your design according to whatever structure the system has.

Or

The system will have to be reworked to fit the design that finally emerges from the development process.

This sets up an inherently confrontational relationship between the game’s design, its quest system, and everyone developing either one of them. This risk is especially high when the foundations of the system are the result of someone improvising them. Although neither of these outcomes is desirable, they’re not immediately catastrophic. It will, however, lead to false starts and reworks as the team finds its footing.

A Holistic View

The system that designers use to create the gameplay and narrative experiences of a game shapes that experience. In other words, if a designer is tasked to use a quest system to create content, and that system has a specific set of fields, like a block of text from an NPC, and not others, like a slot for an animation a large object that is part of the scenery should play, they will tend to create experiences that don’t have big animations but will feature a lot of expository dialogue. The takeaway from this is that the quest system will influence the kind of experience designers create by the fields it presents to them.

The quest system will be shaped by the initial requirements the design and engineering teams agree to. That is if there is an explicit effort to define technical specifications for it in the first place. Remember that the development process steps will happen, regardless of how involved they may be. The usual caveat about game development being an iterative process, and that nothing is set in stone until it’s too late to change it applies. That being said, having clear goals and design pillars when the quest system’s foundations are implemented, will give your team more time to hone in on what makes your game special.

Technically Speaking

On the subject of the purely technical needs of a quest system, as the previous examples show, it must be able to receive information from other game systems and respond by sending messages back, or to other systems.

This system interconnectivity is a crucial aspect of any game project, even if it doesn’t have an explicit quest system. Regardless of how it’s implemented, its interconnectivity is the main function of this system. The other aspects of it, such as player-facing UI (if any), serialization, sequencing, and state transitioning, are all secondary to guaranteeing that the quest system can work with, and through, the game’s other systems. The other crucial aspect of a quest system is its usability. As I had outlined before, game engines often have a scripting layer that designers have access to, where they will define the states, transitions, and responses of the quest system to changes to their selected tracked values.

All of these aspects also have to be placed in the context of ongoing development — the systems and features that exist at the start of the project won’t be the same as those that will exist at the end, and the quest system will need to be able to address all of them. The quest system itself will change. With that in mind, I must remind you that creating a quest system poses a unique set of questions for which there isn’t a universally correct answer.

Platform Perspective

The quest system should be conceived as independent, and capable of leveraging other systems while running the logic contained in individual quests. In other words, the quest system can be thought of as a platform on which quest “programs” run and it should be mapped out as such.

Conceiving the quest system as a platform leads us to define its functions not as end-points with rigid parameters and outputs, but as a library that refers to other systems as a fundamental part of its behavior. This also means that designers do their work specifically in quest scripts rather than having to write custom logic in arbitrary objects, thus centralizing and encapsulating their work into a single module and type of object. The benefit of this approach is that it reduces the complexity of other systems since quest-specific behavior doesn’t need to be injected into others to cover quest-specific needs. This approach makes iterating on, adding, and removing quests and objects they may use much simpler. For example, imagining that the quest system didn’t have this internalized scripting feature, let’s think our way through a typical scenario.

A quest that unlocks a door. If there is no scripting system, a designer may try to write custom logic for the specific door out in the world so it would check the state of that quest. This custom code would be linked to the door itself, and this kind of custom logic can very easily lead to unexpected behavior. This happens due to the strong coupling created by the relationship between it, the door, and the quest.

On the other hand, the quest system can be built to trigger an unlocking event, and, likewise the door can be built to respond to unlocking events, without creating a strongly coupled relationship. This way, removing a quest, or a door, and changing it to another kind of interactable object, won’t lead to surprise exceptions in unrelated game systems. As an added benefit, this generalized approach will also establish a de-facto standard operating procedure that’s easily understood, replicated, and maintained for the entire project.

Shared API

When we conceive of games as multiple systems operating in a shared context, with each system being responsible for a single feature or aspect of the game, the interaction between those systems must be formalized. The simplest and most intuitive way to address this is to create a function for each kind of interaction. However,  this approach will lead to problems in most projects.

Creating a door, and then writing a function in the quest system that specifically opens a door seems like a straightforward solution to doors in general. After all, common sense dictates that we should have a door to solve a door-shaped problem. This initial implementation isn’t a good solution because a door is an object with states and behaviors, and there will be plenty of other objects with the same basic characteristics, but with different details. However, since the door already exists and the project must move forward, the second interactable object will have “door-like” functions. This type of incremental development will become a burden as systems that were simple solutions to a single problem become more and more complex to fulfill similar needs. The first sign of trouble will be two distinct functions that accomplish the same kind of outcome are implemented separately. When that happens, think of how you can reorganize your systems so they have a single logic pathway to achieve both results.

Instead, we should define what amounts to an API for game objects and systems. We can define it by seeking out the lowest common denominator between those objects and the functions we want them to perform. In this case, we’re talking about an object with states and behaviors of its own, reacting to generic messages in a way those objects define for themselves.

The Lessons

This subject has a lot more depth to it, and some of its unexplored regions are hinted at here. There’s a lot, for example, to be said about diegetic quest systems,  and the unseen guiding hand of designers out there.

Let me boil down the lessons I want you to take away from all of this:

1. The quest system’s structure shapes the designers’ ambitions.

It takes a lot of effort to use tools in a way they’re not meant to be used. If you’ve defined your quest system before there is a clear idea of what your game’s goals are, then you’ll find that the system will do that for you. Even if there is no explicit quest system as I’ve described it, your team’s ambitions will fit into what they think they can accomplish. Make your systems as flexible and usable as possible. It’s an investment that always pays off.

2. The quest system is best conceived as a scripting framework that interacts with other systems.

The two phases that a quest system has, first as a tool to shape a game’s experience during development, and then as the interchange between all other systems during play, are both equally important. It’s better to build an explicit quest system for anything more than the most basic gameplay experiences. And when you do, don’t think of it as a system that has rigid functions of its own; think of it as a scripting framework that executes self-contained logic.

3. Avoid incremental solutions to structural problems.

The first solution you apply to a problem will likely be the solution that’s applied anywhere it could conceivably work. That first solution is your foundation. Phrases like “We can add to it later” or “it will work for now” are a sure sign of trouble to come. To be sure, a game’s systems will evolve. Make that evolution viable by building a modular, flexible structure rather than just solving the first problem as quickly as possible.

There is plenty of nuance and tightrope acts in game development. That is just as true here as anywhere else; none of these lessons should be taken as absolutes. Nevertheless, my purpose here was to shine a light on some of the hidden structures that are inherent to this kind of system and point out some of the traps in them.

My hope is that this leads to designers having more time to develop their ambitions in the games we’re all making and that engineers have more time to solve the “interesting” problems.