> For the complete documentation index, see [llms.txt](https://sdk.metamarket.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sdk.metamarket.tech/core-concepts/quests-and-progression.md).

# Quests and Progression

A quest is a goal with a lifecycle the engine runs for you. The same machinery covers a tutorial step, a daily challenge, a season pass tier, and an achievement, because all of them are the same shape underneath: accept the goal, make progress, claim the reward, complete.

## The lifecycle

```mermaid
flowchart LR
    A["available"] -->|accept| B["active"]
    B -->|progress| C["ready to claim"]
    C -->|claim| D["completed"]
```

A quest starts available to the player. Accepting it makes it active and takes a snapshot of the relevant state. As the player acts, the engine measures progress and, once the goal is met, marks the quest ready to claim. Claiming pays out the reward and finishes the quest. The game drives this by reporting actions and calling the lifecycle steps; it does not implement the state machine itself.

Progress is measured two ways, chosen per quest. A delta goal counts change since the quest was accepted, "earn 500 coins," using the snapshot taken at acceptance. An absolute goal checks a value directly, "reach level 10," regardless of where the player started. Achievements and progression tracks are usually absolute goals: they are quests that watch a stat cross a threshold, which is why a studio does not need a separate achievements system.

## Multi-step chains

A quest can hold several tasks, and how they unlock is configurable:

* **Staged.** Each task opens once the previous one is claimed, for a guided sequence like an onboarding chain or a tiered pass.
* **Sequential.** Tasks unlock one at a time in a fixed order, each claimed before the next begins.
* **Parallel.** All tasks are available at once, completed in any order.

Between them these cover the common structures, a linear tutorial, an all-at-once weekly card, a staged battle pass, without custom orchestration code per game.

## Recurring quests

A quest can renew instead of ending for good. Renewal happens on its own on a schedule, a daily set that refreshes at the day boundary, or on a trigger, a quest that re-arms when a specific action fires. Each repeat is a fresh instance, so a returning player finds the next day's quests already prepared without a background job cycling in the meantime. Timing is evaluated when the player next interacts, which is what lets an expired daily quiet down and a new one appear on the same visit.

## Addressing a quest

A game points at a specific quest by a stable address that survives renewal, so a client that bookmarked yesterday's daily quest still resolves to today's fresh instance at the same handle. The reference-level detail of that addressing, and the exact accept, evaluate, and claim calls, are in the [HTTP API](/evaluate-and-integrate/api-guide.md).