---
id: activity-simulators
status: active
supersededBy: []
lang: en
title: Activity and profession simulators
description: >-
  Activity simulators turn observation, operation sequences and limited tools
  into a testable work task.
intro: >-
  Activity simulators turn observation, operation sequences and limited tools
  into a testable work task. 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: 11
  branches: 11
  variants: 44
url: 'https://gamemechanics.pro/en/mechanics/activity-simulators/'
markdownUrl: 'https://gamemechanics.pro/content/mechanics/en/activity-simulators.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.
---
# Activity and profession simulators

Activity simulators turn observation, operation sequences and limited tools into a testable work task. 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. Farming, gardening and animal husbandry

<a id="t127"></a>
id: t127
canonicalId: activity-simulators--t127
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t127

Farming connects land preparation, growth cycles and animal care to a seasonal production plan.

#### Mechanic variants

<a id="t127-variants"></a>
- Sowing occupies a plot until crops mature. <a id="t127-v1"></a>
- Watering supports a chosen growth rate. <a id="t127-v2"></a>
- Soil changes suitability for different crops. <a id="t127-v3"></a>
- Animal care connects feed to useful output. <a id="t127-v4"></a>

Design example: A player reserves some land for feed to maintain animal production through winter.

Prototype check: Test simultaneous crop maturity and ending a session without mandatory immediate harvesting.

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

### 2. Cooking, recipes and kitchen work

<a id="t128"></a>
id: t128
canonicalId: activity-simulators--t128
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t128

Kitchens transform ingredients into orders through dependent steps, requiring aligned component readiness and workstation availability.

#### Mechanic variants

<a id="t128-variants"></a>
- Preparation reduces work after an order arrives. <a id="t128-v1"></a>
- Heating requires deciding when to stop. <a id="t128-v2"></a>
- Assembly combines components at suitable readiness. <a id="t128-v3"></a>
- Dirty stations create a cleaning task. <a id="t128-v4"></a>

Design example: Side dishes are prepared while a limited stove cooks the next order's main dish.

Prototype check: Test operation order and waiting-related quality loss with clear explanations for spoiled game dishes.

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

### 3. Fishing, hunting and harvesting trades

<a id="t129"></a>
id: t129
canonicalId: activity-simulators--t129
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t129

Harvesting trades combine site and tool choices with reading target behavior and timing resource collection.

#### Mechanic variants

<a id="t129-variants"></a>
- Bait selects a likely catch category. <a id="t129-v1"></a>
- Tension requires modulating the pulling force. <a id="t129-v2"></a>
- Tracks narrow the target search area. <a id="t129-v3"></a>
- Harvest limits preserve site recovery. <a id="t129-v4"></a>

Design example: An angler loosens the line during a surge and reels in during a brief pause in resistance.

Prototype check: Test distinct bite and overload signals, including an alternative to mandatory vibration feedback.

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

### 4. Cleaning, sorting and restoration

<a id="t131"></a>
id: t131
canonicalId: activity-simulators--t131
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t131

Restoration turns dirty or damaged objects into ordered states through suitable tools and work-area selection.

#### Mechanic variants

<a id="t131-variants"></a>
- Cleaning removes a specific contaminant type. <a id="t131-v1"></a>
- Sorting assigns objects to categories. <a id="t131-v2"></a>
- Removing a layer reveals a hidden surface. <a id="t131-v3"></a>
- Repair preserves desirable signs of aging. <a id="t131-v4"></a>

Design example: A restorer cleans a sign while preserving original paint and visible marks of the artist's work.

Prototype check: Test completion boundaries and remaining-work feedback to avoid hunting one invisible leftover pixel.

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

### 5. Construction, earthmoving and machinery

<a id="t132"></a>
id: t132
canonicalId: activity-simulators--t132
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t132

Machinery work coordinates vehicle placement, tools and material movement to achieve a target site shape.

#### Mechanic variants

<a id="t132-variants"></a>
- Buckets carry limited material volumes. <a id="t132-v1"></a>
- Supports constrain a machine's working region. <a id="t132-v2"></a>
- Markings define target height or contour. <a id="t132-v3"></a>
- Tool changes enable different operation types. <a id="t132-v4"></a>

Design example: An excavator removes soil in layers without blocking the truck's access route.

Prototype check: Test tool collisions and volume estimates with explicit simplifications for the game's machinery model.

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

### 6. Medicine, rescue and emergency services

<a id="t133"></a>
id: t133
canonicalId: activity-simulators--t133
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t133

A game rescue procedure requires identifying a state, choosing limited equipment and acting according to the result.

#### Mechanic variants

<a id="t133-variants"></a>
- Assessment reveals available game information. <a id="t133-v1"></a>
- Priorities allocate a limited team. <a id="t133-v2"></a>
- Procedures have explicit prerequisites and completion. <a id="t133-v3"></a>
- Handoffs preserve information for the next participant. <a id="t133-v4"></a>

Design example: Rescuers in a fictional accident first establish access to a casualty and then arrange transport.

Prototype check: Test step dependencies within stated game rules; do not treat the model as validation of real rescue competence.

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

### 7. Technical incident investigation

<a id="t134"></a>
id: t134
canonicalId: activity-simulators--t134
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t134

Technical investigation compares logs, symptoms and component states to distinguish root causes from subsequent failures.

#### Mechanic variants

<a id="t134-variants"></a>
- Logs constrain the possible event sequence. <a id="t134-v1"></a>
- Measurements test individual component states. <a id="t134-v2"></a>
- Isolation eliminates a competing cause. <a id="t134-v3"></a>
- Restarting tests whether a hypothesis reproduces. <a id="t134-v4"></a>

Design example: A stopped pump proves to be a consequence of lost power rather than the cause of pressure loss.

Prototype check: Test alternative explanations for a symptom and confirmation through an independent observation.

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

### 8. Document checks, inspections and control

<a id="t135"></a>
id: t135
canonicalId: activity-simulators--t135
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t135

Inspection compares submitted information with current in-game requirements to permit entry, seek clarification or refuse.

#### Mechanic variants

<a id="t135-variants"></a>
- Fields are checked against explicit entry rules. <a id="t135-v1"></a>
- Mismatches connect two submitted documents. <a id="t135-v2"></a>
- Instruction changes affect later decisions. <a id="t135-v3"></a>
- Exceptions require separate confirmation. <a id="t135-v4"></a>

Design example: A permit is current but the name on the order differs from the holder's name.

Prototype check: Test date-boundary decisions and the application order of several simultaneously active instructions.

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

### 9. Delivery, dispatching and customer service

<a id="t136"></a>
id: t136
canonicalId: activity-simulators--t136
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t136

Delivery connects address order to capacity, deadlines and order condition, turning routing into a service problem.

#### Mechanic variants

<a id="t136-variants"></a>
- Receiving windows constrain arrival times. <a id="t136-v1"></a>
- Cargo requires compatible transport. <a id="t136-v2"></a>
- Combining orders saves distance but adds waiting. <a id="t136-v3"></a>
- Returns require newly available cargo capacity. <a id="t136-v4"></a>

Design example: Chilled cargo must arrive first even though another address is geographically closer.

Prototype check: Test loading and handoff across a full route, including recipient refusal and game-defined cargo damage.

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

### 10. Scientific experiments and instruments

<a id="t137"></a>
id: t137
canonicalId: activity-simulators--t137
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t137

An experiment changes a selected variable, measures results and compares them with expectations while preserving test conditions.

#### Mechanic variants

<a id="t137-variants"></a>
- Controls keep other conditions unchanged. <a id="t137-v1"></a>
- Instruments have stated precision and range. <a id="t137-v2"></a>
- Repetition separates stable links from chance outcomes. <a id="t137-v3"></a>
- Protocols preserve settings and observations. <a id="t137-v4"></a>

Design example: A player changes one reagent and compares two identically configured fictional sensors.

Prototype check: Test reproducing an experiment from its log and distinguishing an assumption from an observed game result.

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

### 11. Business, office and bureaucracy simulators

<a id="t138"></a>
id: t138
canonicalId: activity-simulators--t138
url: https://gamemechanics.pro/en/mechanics/activity-simulators/#t138

Office tasks move documents and requests through limited authority, approvals and deadlines to expose organizational dependencies.

#### Mechanic variants

<a id="t138-variants"></a>
- Approval routes impose a required sequence. <a id="t138-v1"></a>
- Authority permits a specific decision type. <a id="t138-v2"></a>
- Templates speed up repeated processing. <a id="t138-v3"></a>
- Revision requests create another work cycle. <a id="t138-v4"></a>

Design example: A purchase needs a manager's signature before the manager leaves for a meeting.

Prototype check: Test whether a stalled document has a visible cause and a solution beyond trying every employee.

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