---
id: goals-feedback
status: active
supersededBy: []
lang: en
title: 'Goals, difficulty, learning and feedback'
description: >-
  Goals and feedback explain the value of an action, the causes of its result
  and ways to improve the next attempt.
intro: >-
  Goals and feedback explain the value of an action, the causes of its result
  and ways to improve the next attempt. 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: Game Accessibility Guidelines
    url: 'https://gameaccessibilityguidelines.com/'
    description: >-
      The guideline authors’ primary reference on motor, sensory and cognitive
      accessibility.
counts:
  families: 6
  branches: 6
  variants: 24
url: 'https://gamemechanics.pro/en/mechanics/goals-feedback/'
markdownUrl: 'https://gamemechanics.pro/content/mechanics/en/goals-feedback.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.
---
# Goals, difficulty, learning and feedback

Goals and feedback explain the value of an action, the causes of its result and ways to improve the next attempt. 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. Victory, defeat and alternative success conditions

<a id="t270"></a>
id: t270
canonicalId: goals-feedback--t270
url: https://gamemechanics.pro/en/mechanics/goals-feedback/#t270

Completion conditions define action value; alternative successes fulfill an objective through different constrained approaches.

#### Mechanic variants

<a id="t270-variants"></a>
- Primary objectives set mandatory completion criteria. <a id="t270-v1"></a>
- Alternatives replace combat with negotiation or bypass. <a id="t270-v2"></a>
- Draws have distinct results and consequences. <a id="t270-v3"></a>
- Failure preserves some useful world changes. <a id="t270-v4"></a>

Design example: A settlement can be defended through battle or by evacuating all residents in time.

Prototype check: Test simultaneous victory and defeat conditions with an explicit outcome priority.

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/)

### 2. Scores, combos, multipliers and records

<a id="t271"></a>
id: t271
canonicalId: goals-feedback--t271
url: https://gamemechanics.pro/en/mechanics/goals-feedback/#t271

Scores evaluate actions while combos and multipliers link rewards to sequence and consistent execution.

#### Mechanic variants

<a id="t271-variants"></a>
- Base points weight individual actions. <a id="t271-v1"></a>
- Combos require another success before a window closes. <a id="t271-v2"></a>
- Multipliers raise the value of keeping a streak. <a id="t271-v3"></a>
- Records preserve results under shared mode conditions. <a id="t271-v4"></a>

Design example: Varied tricks raise a multiplier while repeating one safe trick gradually loses value.

Prototype check: Test indefinite scoring without progress and agreement between displayed and final totals.

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/)

### 3. Completion time, speedrunning and route optimization

<a id="t272"></a>
id: t272
canonicalId: goals-feedback--t272
url: https://gamemechanics.pro/en/mechanics/goals-feedback/#t272

Timed completion turns routing, transitions and execution reliability into a shared duration-minimization problem.

#### Mechanic variants

<a id="t272-variants"></a>
- Splits identify local time losses. <a id="t272-v1"></a>
- Ghosts display a previous personal trajectory. <a id="t272-v2"></a>
- Routes trade speed against failure probability. <a id="t272-v3"></a>
- Categories constrain permitted completion techniques. <a id="t272-v4"></a>

Design example: A short jump saves seconds while a longer bypass provides a more reliable no-reset attempt.

Prototype check: Test timing across pauses, loading and frame-rate changes so compared runs share the same timing rules.

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/)

### 4. Feedback, game feel and state readability

<a id="t277"></a>
id: t277
canonicalId: goals-feedback--t277
url: https://gamemechanics.pro/en/mechanics/goals-feedback/#t277

Feedback makes state and action causality readable through coordinated visuals, sound, motion and tactile response.

#### Mechanic variants

<a id="t277-variants"></a>
- Anticipation shows an upcoming effect region. <a id="t277-v1"></a>
- Contact feedback confirms a successful action. <a id="t277-v2"></a>
- Distinct cues separate blocks from misses. <a id="t277-v3"></a>
- Settings reduce intensity without removing meaning. <a id="t277-v4"></a>

Design example: A blocked strike changes sound and weapon motion and remains readable without camera shake.

Prototype check: Disable decoration and audio separately; essential outcomes should remain identifiable through an available channel.

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/)

### 5. Diegetic interfaces and in-world instruments

<a id="t279"></a>
id: t279
canonicalId: goals-feedback--t279
url: https://gamemechanics.pro/en/mechanics/goals-feedback/#t279

In-world instruments display state and require character actions, making interface reading part of a spatial challenge.

#### Mechanic variants

<a id="t279-variants"></a>
- Object-mounted gauges require orienting the object. <a id="t279-v1"></a>
- Panels permit control only while nearby. <a id="t279-v2"></a>
- Instrument screens constrain the field of view. <a id="t279-v3"></a>
- Redundant cues preserve essential state access. <a id="t279-v4"></a>

Design example: Battery charge appears on a handheld instrument that must be raised instead of a weapon.

Prototype check: Test gauge readability at low resolution and alternatives when instrument placement hides essential information.

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/)

### 6. Inventories, maps and interfaces as play spaces

<a id="t278"></a>
id: t278
canonicalId: goals-feedback--t278
url: https://gamemechanics.pro/en/mechanics/goals-feedback/#t278

Interfaces become play spaces when placing, connecting or interpreting their elements directly changes a challenge's solution.

#### Mechanic variants

<a id="t278-variants"></a>
- Packing connects item shapes to storage space. <a id="t278-v1"></a>
- Maps permit rearranging connections between rooms. <a id="t278-v2"></a>
- Windows hide or reveal parts of a world. <a id="t278-v3"></a>
- Panels connect commands into executable sequences. <a id="t278-v4"></a>

Design example: A player rearranges map rooms and changes actual doorway connections in a dungeon.

Prototype check: Test visible links between interface operations and world changes, with undo before creating a dead end.

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/)

## Sources and examples

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

- [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/): The guideline authors’ primary reference on motor, sensory and cognitive accessibility.