> For the complete documentation index, see [llms.txt](https://help.craftsmanplus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.craftsmanplus.com/play/settings/progression.md).

# Progression

Progression is the system that turns your playable into dynamic experience. It tracks numbers (score, health, moves, or anything else you define) and reacts when those numbers hit the thresholds you set. Win screens, lose states, milestone rewards, and level gates are all built with progression.

The system has two building blocks, managed in two tabs:

* **Variables** are named numeric values that your playable tracks, like Score or Health. See [Variables](/play/settings/progression/variables.md).
* **Triggers** watch a variable and fire an action when it meets a condition, like starting the win scene when Score reaches 100. See [Triggers](/play/settings/progression/triggers.md).

Between the two sits the [**Update Progression**](/play/general/actions/update-progression.md) action, which changes a variable's value whenever it fires. Attach it to a tap, a scene event, or any other interaction, and you've connected player behavior to your game logic.

### How the Pieces Fit Together

A typical progression flow looks like this:

1. A player interacts with a layer that has an **Update Progression** action, or plays a game layer that updates its own variables.
2. A **variable** changes value.
3. A **trigger** watching that variable sees its condition met and fires its action, such as starting the next scene or opening a URL.

Components like the [Progress Bar](/play/layers/components/progress-bar.md) and [Progress Text](/play/layers/components/progress-text.md) can track any variable to display it to the player, so your progression is visible as well as functional.

### The Progression Section

You'll find the Progression section in the project settings properties panel. It contains the **Triggers** and **Variables** tabs, and a **+** button in the header that adds to whichever tab you're viewing.

Every new project starts with one variable, **Variable 1**, starting at 0. Rename it, repurpose it, or remove it, and add as many of your own as you need. Projects created before custom variables were introduced may also have **Score**, **Moves**, and **Health**. These are ordinary variables, so you can rename or remove them too.

### Game Progression

Game Mechanic layers have their own **Progression** section in the properties panel, with the same Triggers and Variables tabs and a few guardrails:

* Triggers can only watch the game's own counters: **Score**, and **Moves** or **Health** in the games that have them. Project variables don't appear in the selector.
* The Variables tab lists the values that control the game's scoring, like **Starting Score** and **Score Per Match**. You can edit each value, but you can't add, remove, or rename them.
* A game never ends on its own. Add a trigger for every outcome, like starting the end card when Score reaches 100.

This keeps each game's internal logic self-contained while giving you the same trigger system to react to it. Each mechanic's variables and what they control are covered in that mechanic's page under [Game Mechanics](/play/layers/game-mechanics.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.craftsmanplus.com/play/settings/progression.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.