2 quest runtime projection and turn in authority
forgejo-actions edited this page 2026-07-13 19:05:50 +00:00

Quest Runtime Projection And Turn-In Authority

Quest runtime projection builds the quest snapshot a player sees and the server uses to accept, advance, complete, and reward quests. It connects authored quest catalogs with NPC affordances, gameplay conditions, objective progress, and authoritative turn-in.

Purpose

Use this page when markers are missing, a quest cannot be accepted, turn-in is blocked, follow-up quests do not appear, or a client and server disagree about quest readiness.

Quest Facts And Statuses

Quest state uses explicit status families: unavailable, available, in progress, ready for turn-in, completed, and rewarded. The projection keeps accepted ids, completed step ids, ready ids, reward-applied ids, journal entries, and map markers in one snapshot.

The shared world-domain quest state machine is the write model for those facts. Reconcile evaluates authored availability, active objectives, and branch conditions; Accept validates availability and records acceptance; Complete validates the terminal objective flow, commits the rewarded state, and unlocks follow-ups. Both preview and server code should consume its deterministic transition result instead of editing lifecycle id lists independently.

QuestStateMachineTransition reports ordered quest and objective changes. These deltas are suitable for diagnostics, UI animation, analytics, and tests without making those consumers owners of quest rules.

Objective And Step Synchronization

Objectives should project from shared gameplay condition state. Step progress, completed objective ids, and ready markers must be synchronized before emitting the snapshot. Do not let a UI-only marker imply that the server considers a quest ready.

Objective keys are scoped as quest::objective for top-level objectives and quest::step::objective for stepped quests. Objective phases are re-evaluated from authoritative facts, while completed step keys remain latched so a branched flow cannot move backward after advancing.

NPC Accept And Turn-In Rows

NPC service overlays can synthesize accept and turn-in options from quest projection. A row can be visible but disabled with a reason code when objectives are incomplete or the quest is not currently available.

Authoritative Multiplayer Snapshots

Online quest commands run through gameplay action authority. The server validates catalog state, actor state, current quest snapshot, and expected command idempotency before accepting or completing a quest.

The compact machine state is serialized inside character_gameplay_state.state. The new field uses a serde default, so existing character rows load without a SQL migration. A fresh login imports legacy snapshot facts when present, reconciles the persisted machine against the current catalog and authoritative inventory, and projects the first quest snapshot before realtime bootstrap.

Rewards, Follow-Ups, And Unlocks

Quest rewards can unlock state, grant currency or inventory, and expose follow-up quests. Reward application should route through the same economy and gameplay effect helpers used by other authority paths.

Completion is reduced before the economy transaction is saved, but the resulting gameplay state is committed with reward mutations in that same authoritative transaction. Failed reward application therefore cannot persist a completed/rewarded machine state, and repeated completion is rejected by the machine.

Debugging

Missing markers usually point to projection inputs. Blocked turn-ins usually point to objective conditions or stale snapshot state. Duplicate rewards point to idempotency and reward-applied ids. If only NPC options are wrong, inspect overlay projection before quest authority.