Journal Design Guidelines

This page covers the guidelines for designing a quest in the journal. For more guides on working with the journal, see the pages linked out in Introduction to the Journal.

Overview

The Journal IS	The Journal IS NOT
Your next objective.	An encyclopaedia.
A reminder of the key events that happened on a quest.	A list of every little secret, rumour, or easter egg.
	A record of absolutely everything that you did or found.
	A fallback for design holes in situations.

The information in the journal is:

• Known: The information was delivered clearly through dialogue, in a book, or in the environment.
• Factual: The information covers the who, where, what, when... What needs to be done and for whom?
• Relevant: The information actually helps the player progress the game.
• Reactive: The information reacts to a meaningful action that the player just did, including information they learned.

Synonyms & Definitions

We have steps, objectives, and quests in the journal.

• Quest: Steps and objectives, together, form a quest in the journal.
• Objective: What the player should do next.
• Step: What just happened or what the player just did. Thinking about it as a "step" helps thinking about concrete actions towards a goal.

For more detailed explanations, see Journal Structure Overview.

Designing Quests

Principles

The key principles to keep in mind when designing quests for the journal are as follows:

1. A quest starts with at least one call to action.
2. A quest progresses through meaningful actions.
3. A quest has at least one closure, and as such, it must have an end goal.
4. A quest is a complex situation that can’t be solved within a screen or a simple interaction.
5. Some quests may span across multiple situations.
6. Quests are shared across the party (unless it’s an Origin quest).

Finding the End Goal

What the quest is about is defined by its end goal. When creating a quest, the first thing you need to do is to ask yourself: "As a player, what is my end goal?" This will help you structure and narrow down the objectives, focus the steps, and decide if it really needs a quest after all. No clear end goal may indicate there’s no quest.

The quest’s title must be based on its end goal. Make sure that no matter when and how a quest starts, the end goal is clear for the player, otherwise the quest's purpose (and its title) may be confusing.

The quest may have multiple end goals, especially if the narrative presents a surprise and the quest develops in an unexpected way. In such cases, you may need to use subquests to support this properly.

Identical End Goals

There should never be two quests with the exact same end goal.

Even if the content of two quests is 99% identical, they need to have different end goals. Different end goals means different stakes, needs, and points of view, which in turn makes for different structures, objectives, and steps.

The following example portrays two quests that have almost identical content, but their call to actions and end goals are different:

There are two different quests concerned with finding Halsin. One demands that you find Halsin to find a solution for the tadpole in your brain. The other is to find him so that he can bring peace back to the Emerald Grove. The first closes when you learn about the tadpole solution. The other closes if the Emerald Grove is destroyed or if Halsin himself dies. About 90% of the two quests is identical, but they have different end goals.

Call to Action

The call to action is a problem for the player to solve. A classic example of an RPG call to action is an NPC asking for help. In the case of an explicit request, the player usually has the option to accept or refuse the quest. Accepting the quest adds it to the quest journal.

Some quests, however, start without the player accepting them. It depends on the context, region, NPCs, etc.

Types of Call to Action

• Accepting the quest explicitly
• Documents/notes
• Getting the heroic call to adventure
• Something personal
• Something unexpected or extraordinary

What Is Not a Call to Action?

• Entering a region
• Picking up an object
• Triggering a voice bark
• Entering combat

Quest Category

The following are the types of quest category:

• Main Quest: The main quest.
• Personal Quest: Quests for Origin-specific quests and global quests.
• Companions: Companion-specific quests.
• Locations: “Emerald Grove”, “Baldur’s Gate”, etc.

Designing Objectives

A quest always has at least two objectives:

• One for the call to action.
• One for closing when the end goal is reached.

Priority

Each objective has a priority and its value dictates which unlocked objective is considered active. Only a single objective can be active at a time – the one with the highest priority among the ones that are unlocked.

See Adding a Quest to a Situation for more information on objectives and their priorities.

Markers

If an objective guides the player to a specific known place, NPC, or item, you can add a map marker.

Markers are tied to objectives and are shown and cleared automatically. When an objective becomes active, all its markers will be displayed on the map. As soon as an objective with a marker is completed, its markers will be automatically cleared.

See Working with Map Markers for more information.

Completion Objectives

In all quests, the highest priority objective will be a completion objective. It holds all of the steps that close the quest, since after quest is closed, no new objective can be unlocked.

Completion objectives don't need any description because closing objectives aren't shown in the journal UI. The only text displayed for the player will be of the closing step it contains.

Designing Quest Steps

The quest is updated when its steps unlock. Without a quest step being unlocked, the quest should not start or close. A quest should update every time a meaningful event happens – one that progresses the current objective and/or the end goal of the quest.

Designing Subquests

Subquests are quests that have a parent quest they are related to. As a result, a subquest’s end goal should compliment, alter, or help reach its parent quest’s end goal.

Common Use Cases

Subquests are commonly used when a quest:

• Branches in different directions and/or offers contradicting objectives.
• Has a specific and/or optional chain of objectives.