---
id: progression-rewards
status: active
supersededBy: []
lang: en
title: 'Progression, rewards and retention'
description: >-
  Progression changes player options and goals; rewards should explain new
  decisions and preserve useful stopping points.
intro: >-
  Progression changes player options and goals; rewards should explain new
  decisions and preserve useful stopping points. Each overview separates player
  actions, state changes and alternative rules. Examples are hypothetical design
  scenarios, not claims about a named game. A prototype check states an
  observable question for the next iteration. Existing detailed references
  remain separately linked from the direction map.
updatedAt: '2026-10-21'
sources:
  - title: 'Robert Nystrom: State'
    url: >-
      https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown
    description: >-
      The author’s original discussion of states and transitions; rule
      implementation context, not evidence for every editorial variant.
counts:
  families: 6
  branches: 6
  variants: 24
url: 'https://gamemechanics.pro/en/mechanics/progression-rewards/'
markdownUrl: 'https://gamemechanics.pro/content/mechanics/en/progression-rewards.md'
license: CC-BY-4.0
codeLicense: MIT
attribution: gamemechanics.pro contributors
provenance: >-
  Original bilingual editorial overviews authored for gamemechanics.pro on
  2026-10-20 and reviewed on 2026-10-21. Scenarios are hypothetical design
  examples; prototype checks describe work to perform, not completed playtests.
  Primary sources support the stated techniques and implementation context, not
  every proposed variant.
---
# Progression, rewards and retention

Progression changes player options and goals; rewards should explain new decisions and preserve useful stopping points. Each overview separates player actions, state changes and alternative rules. Examples are hypothetical design scenarios, not claims about a named game. A prototype check states an observable question for the next iteration. Existing detailed references remain separately linked from the direction map.

## Mechanics and variants

<a id="mechanics"></a>

### 1. Unlocking abilities and expanding available actions

<a id="t240"></a>
id: t240
canonicalId: progression-rewards--t240
url: https://gamemechanics.pro/en/mechanics/progression-rewards/#t240

Unlocking an ability expands legal actions and allows previously inaccessible challenges to be reconsidered.

#### Mechanic variants

<a id="t240-variants"></a>
- A new verb enables another type of interaction. <a id="t240-v1"></a>
- An upgrade removes an existing action constraint. <a id="t240-v2"></a>
- Knowledge reveals an already available capability. <a id="t240-v3"></a>
- Shared access transfers an unlock to other characters. <a id="t240-v4"></a>

Design example: Carrying electrical charge opens a door and also enables rerouting a power network.

Prototype check: Test whether an unlock enables at least two different applications understandable from the ability's rule.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown)

### 2. Collections, albums and set completion

<a id="t241"></a>
id: t241
canonicalId: progression-rewards--t241
url: https://gamemechanics.pro/en/mechanics/progression-rewards/#t241

A collection turns separate findings into a visible set whose missing entries guide further searches.

#### Mechanic variants

<a id="t241-variants"></a>
- Silhouettes suggest the shape of a missing entry. <a id="t241-v1"></a>
- Categories connect items through a shared feature. <a id="t241-v2"></a>
- Trading turns duplicates into a path toward gaps. <a id="t241-v3"></a>
- Discovery history preserves location and circumstances. <a id="t241-v4"></a>

Design example: A plant album's empty mountain category suggests exploring at a different altitude.

Prototype check: Test the final collection entries: completion should have a clearer path than endless blind repetition.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown)

### 3. Achievements, challenges and mastery

<a id="t242"></a>
id: t242
canonicalId: progression-rewards--t242
url: https://gamemechanics.pro/en/mechanics/progression-rewards/#t242

A challenge sets a separate mastery criterion and recognizes execution beyond ordinary objective completion.

#### Mechanic variants

<a id="t242-variants"></a>
- Medals distinguish levels of execution quality. <a id="t242-v1"></a>
- Restrictions remove a familiar powerful tool. <a id="t242-v2"></a>
- Records preserve the best result of an attempt. <a id="t242-v3"></a>
- Streaks test consistent execution without mistakes. <a id="t242-v4"></a>

Design example: A level allows an ordinary route, while a separate medal requires avoiding stationary platforms.

Prototype check: Test immediate feedback for a broken challenge rule and retrying without unnecessary waiting.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown)

### 4. Loot, rarity and reward distribution

<a id="t243"></a>
id: t243
canonicalId: progression-rewards--t243
url: https://gamemechanics.pro/en/mechanics/progression-rewards/#t243

A loot system distributes rewards through conditions and probabilities, connecting uncertainty to a clear search direction.

#### Mechanic variants

<a id="t243-variants"></a>
- Loot tables connect sources to possible rewards. <a id="t243-v1"></a>
- Weights alter an item's relative frequency. <a id="t243-v2"></a>
- Guarantees limit unsuccessful attempts. <a id="t243-v3"></a>
- Duplicate protection narrows an unfinished collection. <a id="t243-v4"></a>

Design example: A station can drop a needed module, while ten tokens allow obtaining it directly.

Prototype check: Test long failure streaks and guarantee clarity; do not present an average wait as a promised completion time.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown)

### 5. Idle, incremental and offline progress

<a id="t244"></a>
id: t244
canonicalId: progression-rewards--t244
url: https://gamemechanics.pro/en/mechanics/progression-rewards/#t244

Accumulation continues with limited player attention while upgrades periodically change the production structure.

#### Mechanic variants

<a id="t244-variants"></a>
- Automatic production replaces repeated manual input. <a id="t244-v1"></a>
- Storage caps limit accumulated output. <a id="t244-v2"></a>
- Offline simulation accounts for an elapsed interval. <a id="t244-v3"></a>
- Bottlenecks change the best next purchase. <a id="t244-v4"></a>

Design example: A workshop runs unattended until storage fills and calls for a new allocation of goods.

Prototype check: Test clock changes and repeated loads so one interval is not rewarded twice or converted into negative income.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown)

### 6. Prestige, resets and renewed progression

<a id="t245"></a>
id: t245
canonicalId: progression-rewards--t245
url: https://gamemechanics.pro/en/mechanics/progression-rewards/#t245

A voluntary reset trades some current progression for persistent changes to the next development cycle.

#### Mechanic variants

<a id="t245-variants"></a>
- Multipliers shorten already mastered growth stages. <a id="t245-v1"></a>
- New branches open another development route. <a id="t245-v2"></a>
- Partial resets preserve a chosen project. <a id="t245-v3"></a>
- Diminishing gains change the best restart timing. <a id="t245-v4"></a>

Design example: Restarting a factory removes machines but preserves a blueprint for combining operations.

Prototype check: Show losses and retained progress before confirmation; test for new decisions beyond waiting through another cycle.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown)

## Sources and examples

Sources support particular techniques or methodology, not every family variant. Design examples and mechanic combinations are illustrative.

- [Robert Nystrom: State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown): The author’s original discussion of states and transitions; rule implementation context, not evidence for every editorial variant.