---
id: social-cooperation
status: active
supersededBy: []
lang: en
title: Social relationships and shared play
description: >-
  Social mechanics connect participants’ different capabilities through care,
  trust, coordination and conflicting commitments.
intro: >-
  Social mechanics connect participants’ different capabilities through care,
  trust, coordination and conflicting commitments. 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: 7
  branches: 7
  variants: 28
url: 'https://gamemechanics.pro/en/mechanics/social-cooperation/'
markdownUrl: 'https://gamemechanics.pro/content/mechanics/en/social-cooperation.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.
---
# Social relationships and shared play

Social mechanics connect participants’ different capabilities through care, trust, coordination and conflicting commitments. 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. Caring for pets and dependent characters

<a id="t200"></a>
id: t200
canonicalId: social-cooperation--t200
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t200

Care tracks a dependent character's needs and turns observing its signals into choosing suitable actions.

#### Mechanic variants

<a id="t200-variants"></a>
- Signals distinguish hunger, fatigue and boredom. <a id="t200-v1"></a>
- Routines connect care to a stable schedule. <a id="t200-v2"></a>
- Preferences change the appropriate form of care. <a id="t200-v3"></a>
- Growing independence reduces mandatory supervision. <a id="t200-v4"></a>

Design example: A tired pet refuses to play, so a new toy cannot substitute for rest.

Prototype check: Test understandable refusal reasons and ending a session without unexpectedly penalizing the dependent character.

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

### 2. Asymmetric roles and abilities

<a id="t204"></a>
id: t204
canonicalId: social-cooperation--t204
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t204

Different roles receive distinct actions and information, making progress depend on another participant's contribution.

#### Mechanic variants

<a id="t204-variants"></a>
- Operators see maps while agents see obstacles. <a id="t204-v1"></a>
- A powerful role creates a route for a precise role. <a id="t204-v2"></a>
- Role swaps teach both viewpoints. <a id="t204-v3"></a>
- Independent subtasks occupy a waiting participant. <a id="t204-v4"></a>

Design example: A dispatcher changes bridges on a map while a pilot reports obstacles invisible to the dispatcher.

Prototype check: Test useful activity for both roles at every stage, including when one participant makes an error.

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

### 3. Rescue, support and shared responsibility

<a id="t206"></a>
id: t206
canonicalId: social-cooperation--t206
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t206

Support changes an ally's capabilities while rescue redistributes risk and time across the group.

#### Mechanic variants

<a id="t206-variants"></a>
- Reviving requires uninterrupted safe contact. <a id="t206-v1"></a>
- Covering fire opens a path to a downed ally. <a id="t206-v2"></a>
- Resource transfers change personal support reserves. <a id="t206-v3"></a>
- Evacuation limits speed and available actions. <a id="t206-v4"></a>

Design example: One participant carries an injured ally, another opens doors and a third distracts a pursuer.

Prototype check: Test useful participation or a timely return to play after an unsuccessful rescue.

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

### 4. Betrayal, coalitions and temporary alliances

<a id="t207"></a>
id: t207
canonicalId: social-cooperation--t207
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t207

Temporary alliances align interests until a condition changes, allowing participants to revise commitments for personal goals.

#### Mechanic variants

<a id="t207-variants"></a>
- Shared threats make cooperation advantageous. <a id="t207-v1"></a>
- Hidden goals create divergent interests. <a id="t207-v2"></a>
- Agreements limit when a participant may leave. <a id="t207-v3"></a>
- Reputation carries betrayal consequences forward. <a id="t207-v4"></a>

Design example: Rivals open a vault together and agree beforehand when unrestricted loot division begins.

Prototype check: Test that betrayal is known to be possible before play and that a betrayed player retains meaningful responses.

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

### 5. Social simulations and everyday life

<a id="t198"></a>
id: t198
canonicalId: social-cooperation--t198
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t198

Everyday-life simulation connects routines, needs, work and relationships while players choose the character's life priorities.

#### Mechanic variants

<a id="t198-variants"></a>
- Schedules limit compatible daily activities. <a id="t198-v1"></a>
- Work produces resources at a free-time cost. <a id="t198-v2"></a>
- Relationships change through shared history. <a id="t198-v3"></a>
- Homes reflect a chosen everyday lifestyle. <a id="t198-v4"></a>

Design example: A character visits a friend instead of working an extra shift and delays buying furniture.

Prototype check: Test viable routines with different priorities so one mandatory sequence does not eliminate choice.

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

### 6. Social deduction and hidden roles

<a id="t202"></a>
id: t202
canonicalId: social-cooperation--t202
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t202

Hidden roles give participants different knowledge and goals, while discussion compares statements with observed actions.

#### Mechanic variants

<a id="t202-variants"></a>
- Night phases conceal the source of an action. <a id="t202-v1"></a>
- Public votes commit the group to a hypothesis. <a id="t202-v2"></a>
- Private abilities provide testable information fragments. <a id="t202-v3"></a>
- Bluffs explain part of the observed evidence. <a id="t202-v4"></a>

Design example: A participant claims to have guarded a door while a public log places them elsewhere.

Prototype check: Test evidential grounds beyond random accusations and useful participation after elimination.

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

### 7. Party games, trivia and collective guessing

<a id="t208"></a>
id: t208
canonicalId: social-cooperation--t208
url: https://gamemechanics.pro/en/mechanics/social-cooperation/#t208

Short group rounds distribute answers, clues and scoring while supporting participants with different levels of familiarity.

#### Mechanic variants

<a id="t208-variants"></a>
- Trivia checks answers against an explicit solution source. <a id="t208-v1"></a>
- Guessing restricts the clue vocabulary. <a id="t208-v2"></a>
- Voting selects the most fitting proposal. <a id="t208-v3"></a>
- Team rounds combine separate knowledge fragments. <a id="t208-v4"></a>

Design example: A team assembles an answer from three clues, each visible to only one participant.

Prototype check: Test waiting time and participation without fast reading, especially for the final respondent.

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