---
id: role-playing-systems
status: active
supersededBy: []
lang: en
title: Role-playing systems
description: >-
  Role-playing systems connect character identity, party composition, equipment
  and consequential choices.
intro: >-
  Role-playing systems connect character identity, party composition, equipment
  and consequential choices. 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: 9
  branches: 9
  variants: 36
url: 'https://gamemechanics.pro/en/mechanics/role-playing-systems/'
markdownUrl: 'https://gamemechanics.pro/content/mechanics/en/role-playing-systems.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.
---
# Role-playing systems

Role-playing systems connect character identity, party composition, equipment and consequential choices. 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. Character creation and attribute allocation

<a id="t049"></a>
id: t049
canonicalId: role-playing-systems--t049
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t049

Character creation allocates limited potential across abilities and establishes initial ways of solving problems.

#### Mechanic variants

<a id="t049-variants"></a>
- Attribute points require explicit tradeoffs. <a id="t049-v1"></a>
- Background changes initial character connections. <a id="t049-v2"></a>
- A drawback purchases an additional advantage. <a id="t049-v3"></a>
- Respecialization can revise an early choice. <a id="t049-v4"></a>

Design example: An archivist with weak combat skills gains library access and understands ancient warnings.

Prototype check: Test opening quests with extreme allocations, including a character without a combat specialization.

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

### 2. Classes, specializations and role switching

<a id="t050"></a>
id: t050
canonicalId: role-playing-systems--t050
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t050

A class defines available actions, specialization changes emphasis and role switching changes responsibilities.

#### Mechanic variants

<a id="t050-variants"></a>
- A fixed class maintains a strong identity. <a id="t050-v1"></a>
- A subclass changes how its resource is spent. <a id="t050-v2"></a>
- Out-of-combat switching enables preparation. <a id="t050-v3"></a>
- A hybrid trades specialization for flexibility. <a id="t050-v4"></a>

Design example: A healer prepares barriers instead of restoring health after damage before an expedition.

Prototype check: Test whether specialization changes action order rather than only numerical efficiency of the same loop.

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

### 3. Builds and ability synergies

<a id="t051"></a>
id: t051
canonicalId: role-playing-systems--t051
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t051

A build connects abilities, resources and triggers into a repeatable sequence of mutually reinforcing actions.

#### Mechanic variants

<a id="t051-variants"></a>
- A trigger turns defense into an attack source. <a id="t051-v1"></a>
- A stat threshold unlocks an additional effect. <a id="t051-v2"></a>
- Conversion changes the type of an input resource. <a id="t051-v3"></a>
- An anti-synergy prevents combined amplification. <a id="t051-v4"></a>

Design example: A parry grants frost charge that the next strike spends to create a slowing zone.

Prototype check: Test closed resource loops so combinations do not accidentally provide infinitely repeated free actions.

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

### 4. Party roles and team composition

<a id="t052"></a>
id: t052
canonicalId: role-playing-systems--t052
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t052

Party composition distributes functions among characters and determines mutual support in combat and exploration.

#### Mechanic variants

<a id="t052-variants"></a>
- Roles cover weaknesses of other party members. <a id="t052-v1"></a>
- Reserves change the roster between encounters. <a id="t052-v2"></a>
- A combination requires two coordinated actions. <a id="t052-v3"></a>
- A generalist covers for an absent specialist. <a id="t052-v4"></a>

Design example: A scout marks traps, a defender holds a passage and an engineer opens a side route.

Prototype check: Remove one specialist and test alternative solutions when the party composition is not mandatory.

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

### 5. Equipment, affixes and item sets

<a id="t053"></a>
id: t053
canonicalId: role-playing-systems--t053
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t053

Equipment changes character properties, while affixes and sets connect item selection to actual behavior.

#### Mechanic variants

<a id="t053-variants"></a>
- An affix grows stronger under a stated condition. <a id="t053-v1"></a>
- A set changes a rule after enough pieces are worn. <a id="t053-v2"></a>
- Weight limits combinations of heavy equipment. <a id="t053-v3"></a>
- Replacing a property preserves a valuable item base. <a id="t053-v4"></a>

Design example: Light boots improve attacks after dodging, but the full set rules out a heavy shield.

Prototype check: Test item comparisons: players should see a bonus trigger and the cost of replacing equipment.

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

### 6. Status effects, elements and resistances

<a id="t054"></a>
id: t054
canonicalId: role-playing-systems--t054
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t054

A status temporarily changes action rules, an element connects interactions and resistance limits their effects.

#### Mechanic variants

<a id="t054-variants"></a>
- Buildup brings an effect toward a threshold. <a id="t054-v1"></a>
- Dispelling removes a chosen status condition. <a id="t054-v2"></a>
- An elemental reaction creates another effect. <a id="t054-v3"></a>
- Diminishing duration limits repeated crowd control. <a id="t054-v4"></a>

Design example: Wet armor conducts a discharge between targets, while insulating footwear breaks the chain.

Prototype check: Test elemental application order and immunity feedback, including reapplying an already active status.

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

### 7. Learning skills through use

<a id="t055"></a>
id: t055
canonicalId: role-playing-systems--t055
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t055

A skill improves through relevant use, letting players practice while also addressing a current objective.

#### Mechanic variants

<a id="t055-variants"></a>
- A successful action grants skill experience. <a id="t055-v1"></a>
- A novel situation gives more than rote repetition. <a id="t055-v2"></a>
- A mentor unlocks the next development ceiling. <a id="t055-v3"></a>
- Practice transfers to related abilities. <a id="t055-v4"></a>

Design example: Opening new lock types improves the craft more than repeatedly reopening one easy box.

Prototype check: Test whether meaningless safe repetition outperforms applying the skill to its intended challenges.

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

### 8. Reputation, factions and alignment

<a id="t057"></a>
id: t057
canonicalId: role-playing-systems--t057
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t057

Reputation stores how communities view the character's actions and changes access to services, quests and support.

#### Mechanic variants

<a id="t057-variants"></a>
- Factions evaluate the same action differently. <a id="t057-v1"></a>
- Witnesses determine how information spreads. <a id="t057-v2"></a>
- Forgiveness requires repairing specific harm. <a id="t057-v3"></a>
- Local recognition differs from worldwide fame. <a id="t057-v4"></a>

Design example: Rescuing a smuggler opens a secret pier but harms relations with the harbor watch.

Prototype check: Test whether actions visibly explain faction reactions, especially when rumors spread after a delay.

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

### 9. Quests, contracts and consequences

<a id="t058"></a>
id: t058
canonicalId: role-playing-systems--t058
url: https://gamemechanics.pro/en/mechanics/role-playing-systems/#t058

A quest defines a commitment and completion conditions, while consequences preserve differences between solutions.

#### Mechanic variants

<a id="t058-variants"></a>
- Alternatives allow completing an objective without combat. <a id="t058-v1"></a>
- A deadline changes the situation after a delay. <a id="t058-v2"></a>
- Conflicting jobs force a commitment choice. <a id="t058-v3"></a>
- Consequences change the world after payment. <a id="t058-v4"></a>

Design example: Medicine can reach the paying client or be given to a sick village encountered on the route.

Prototype check: Test quest completion after an important NPC dies and when the required item is obtained before acceptance.

- [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.