Ordfoss

Quest.h header

#include <ew/core/Quest.h>

Namespace ew::core

Quest struct

struct ew::core::Quest

A named objective with states, and entries within it that have their own states.

The quest itself is a codex entity (entityId), so it carries a description, audience visibility, properties and validation like anything else in the world – and can be referenced, linked and found by search without any of that being rebuilt here. This record is the part the codex cannot express: the states, and the entries.

Studios advance quests from dialogue constantly. Modelling that as a raw integer is possible and is not how the domain thinks: an effect should read "set Rescue the Cartographer, entry 2, to complete", not "set q_2 to 3".

Members

ew::core::foundation::ContentId ew::core::branching::Quest::entityId

The codex entity this quest IS – its name, description, audience and properties.

By id, never by name, so renaming the quest in the codex does not orphan the effects that advance it. A quest whose entity has been deleted is reported as a dangling reference.

std::vector<QString> ew::core::branching::Quest::states

The states the quest as a whole can be in, in order; the first is where it starts.

ew::core::foundation::VariableId ew::core::branching::Quest::stateVariableId

The variable holding the quest's CURRENT state while the story runs. See QuestEntry::stateVariableId for why it is a variable.

std::vector<QuestEntry> ew::core::branching::Quest::entries

The objectives within it, in journal order.

bool operator==(const Quest &, const Quest &)=default

Quests compare equal when every field matches.

QuestEntry struct

struct ew::core::QuestEntry

One objective inside a quest – a line in the journal, with a state of its own.

Entries have their own states because a quest is not one switch. "Find the ledger" can be complete while "Confront the harbourmaster" is still active and "Pay the fine" was never offered, and a reader's journal shows all three. A quest modelled as a single value cannot say that, so studios end up with one variable per line and a naming convention nobody writes down.

Members

QString ew::core::branching::QuestEntry::text

What the reader is told this objective is – the journal line.

std::vector<QString> ew::core::branching::QuestEntry::states

The states this entry can be in, in the order an author listed them; the first is where it starts.

Per entry, not fixed. A fetch quest's entry is unassigned/active/complete; an investigation's might be unheard/suspected/proven/disproven. A closed vocabulary would send authors back to raw variables the first time their story did not fit it.

ew::core::foundation::VariableId ew::core::branching::QuestEntry::stateVariableId

The variable holding this entry's CURRENT state while the story runs.

A quest's state is story state, exactly like gold or hasKey: it changes as the reader plays, it has to be inspectable mid-playthrough, it has to export, and conditions have to be able to test it. Giving it a variable means all four already work rather than each being built again in quest-shaped form – and a condition reads ledgerFound = "complete", which is a sentence rather than a lookup table.

bool operator==(const QuestEntry &, const QuestEntry &)=default

Entries compare equal when every field matches.

Functions

int ew::core::branching::questEntryForStateVariable(const Quest &quest, ew::core::foundation::VariableId variableId)

The index of the entry in quest whose state variable is variableId, or -1 when none is.

const Quest * ew::core::branching::questForStateVariable(const std::vector< Quest > &quests, ew::core::foundation::VariableId variableId)

The quest in quests whose state variable is variableId, or nullptr when none is.

What lets a variable be shown, and an effect worded, in the story's own terms rather than as the machinery underneath: an inspector row reading q_rescue = "active" tells an author nothing they wrote.