About and methodology

The Game Mechanic Compendium is a research catalog. Its purpose is to describe game mechanics across media in a way that makes them comparable: the same closed vocabularies, the same fields, the same sourcing standard for every entry. It is not a design manual and does not rank mechanics.

What counts as an entry

Each entry describes one mechanic in its canonical form: the version most commonly recognised across media, usually the one in the provenance example. We code the mechanic, not any particular game that contains it. A game may add randomness, conflict, or hidden information that the mechanic itself does not require; those are noted under Variations, not in the structured properties. Narrow variants are folded into a parent entry's Variations section until they have enough independent literature and examples to stand alone.

Abilities

A separate abilities section catalogues ability archetypes: named effects that recur across games, such as a fireball, a blink, or a heal. Each is defined by its behaviour rather than its name and coded by function and delivery. Every example records what gates the ability in that game (a cooldown, mana, a spell slot, an ultimate meter, a consumable), because the same archetype is gated differently from game to game. Abilities link to the mechanics they exercise but carry no design properties or effect tags, and they are not part of the pattern figures. The vocabularies are in taxonomy.json.

Crafting

A third section, crafting, catalogues crafting archetypes: named operations on items that recur across games, such as assembling an item from a recipe, salvaging it for parts, rerolling its properties, or raising it a tier. Each is defined by its procedure rather than its name and coded by operation and outcome. Every example records what the operation requires in that game (materials, a station, a known recipe, a sacrificed item, a per-item budget), because the same operation has different requirements from game to game. Like the abilities, crafting archetypes link to the mechanics they run through, carry no design properties or effect tags, and are not part of the pattern figures.

Scaling

A fourth section, scaling, catalogues scaling archetypes: named ways in which capability grows, broadens, or is held level across play or across releases. Each is coded on one axis: vertical (capability grows in magnitude, as with per-level stat gains or rising item levels), horizontal (options grow while power stays roughly level, as with sidegrades or collected abilities), or normalizing (vertical differences are compressed or cancelled, as with level sync or enemies that scale to the player). Each also has one scope, the thing that scales: a character, an item, an ability, the world, or the game's content across releases. Every example records the basis the scaled value is keyed to in that game (character level, an attribute, item tier, a release, a zone's level), because the same archetype is keyed differently from game to game. Like the abilities and crafting, scaling archetypes link to the mechanics they run through, carry no design properties or effect tags, and are not part of the pattern figures.

Synergies

A fifth section, synergies, catalogues synergy archetypes: named ways in which two or more parts (items, abilities, cards, units, characters, or states) are worth more together than apart. Each is coded on one form, how the parts combine: threshold (a bonus switches on at a count of matching parts, as with set bonuses), cumulative (each matching part adds to the others' payoff, as with tribal lords),setup and payoff (one action leaves a state that a later one cashes in), combination (two specific parts yield a distinct effect, as with elemental reactions), conversion (one property is turned into another), or loop (parts trigger one another). Each also has one scope, where the parts sit: one build, a team, a board of cards or units, or the field. Every example records the links that connect the parts in that game (a shared tag, a set, a status, an element, a position, a trigger), because the same archetype is linked differently from game to game. Like the other archetype sections, synergies link to the mechanics they run through, carry no design properties or effect tags, and are not part of the pattern figures.

Weapons

A sixth section, weapons, catalogues weapon archetypes: named weapon behaviours, classes, rules, and properties that recur across games and belong to an item or an equipped attack rather than to a character's spell or skill. Each is coded on one delivery, how the weapon reaches its target: melee,thrown (the weapon itself travels, as with a returning axe), projectile (a missile with travel time),hitscan (resolved at once along a line), area (the effect is a radius, as with splash damage),placed (set down and set off later), or any delivery for rules and properties that apply to weapons of every kind. Each also has one kind: a behaviour found on many weapons, a class of weapon, arule governing all weapons, or a property printed on individual ones. Every example records what limits the weapon's use in that game (ammunition, a magazine, heat, charge time, durability, stamina, a cooldown, an action cost, or nothing), because the same archetype is limited differently from game to game. Like the other archetype sections, weapons link to the mechanics they run through, carry no design properties or effect tags, and are not part of the pattern figures.

Game systems

A seventh section, game systems, catalogues composite subsystems that recur across games, such as a day-night cycle, a nemesis system, or a wanted level. A system's identity is the interaction of three or more mechanics around state that persists, and no single one of those mechanics owns it; a system that one mechanic fully describes stays a mechanic. Each is coded on one domain, what the system simulates: the environment(time of day, weather, seasons, elements), inhabitants (non-player characters and creatures as agents),society (law, factions, territory), an economy (prices, production, demand), the avatar'sbody (needs, injury, exposure), or pacing (systems that meter encounters and intensity). Each also has one driver, what moves its state: a clock, player action, autonomous simulation, or anadaptive reading of the player's state. Every example records as its components the mechanics that game's version combines, because the same system is assembled differently from game to game; the mechanics every example names form the system's shared core. Because a system's defining part (the clock of hours, the escalating tiers of a pursuit, an enemy's memory of the player) is seldom a catalog mechanic, every example also records the system's own working parts there, from a vocabulary of twenty-nine, among them a world clock, a conditional spawn, escalation, a return to rest, a paid reset, drain, exposure, propagation, agent memory, a rank hierarchy, routines, agent needs, population change, demand, territory change, treatment, an intensity reading, and a forecast. Like the other archetype sections, game systems carry no design properties or effect tags and are not part of the pattern figures.

Categories

Every mechanic has exactly one primary category, chosen by asking which element, if removed, would make the mechanic cease to exist. Overlaps are recorded through parent, child, and related links and in the property notes field, so contested placements stay visible rather than being silently resolved. When two families both seem to apply, the questions below are asked in order and the first "yes" wins; the losing candidate is recorded in property notes. The order is a default, not a law: where an entry's category departs from it, the property notes say so and give the reason.

Design properties

Properties use short closed vocabularies with written coding guidelines, applied to the mechanic's own rules in isolation. For mechanics that wrap a whole game, such as cooperative play, team play, or tournament formats, the host game's randomness, decisions, and rules weight are not counted. Three properties are ordinal (agency, complexity, decision density) and are exported with integer ranks; the others are nominal. Randomness distinguishes input (resolved before the player decides) from output (resolved after), following common usage in the design literature.

Reliability of the codings

Codings that were re-done blind, by two coders working from copies with the value and every sentence about it removed, have their agreement recorded below. Where the coders agreed, their value stands; where they split, the earlier value stands and the other is recorded in the entry's property notes. Raw codings are in the repository under research_notes/.

Player-experience effects

Each entry carries two to six effect tags describing tendencies the mechanic produces in its canonical form. They include negative and structural effects and are not endorsements. Where an effect depends on parameters (hand size, number of players), the entry's Analysis notes say so.

Cognitive

Mastery

Perceived growth of player skill through repeated use of the mechanic.

Discovery

Pleasure of uncovering previously unknown content, rules, or state.

Planning

Satisfaction from constructing multi-step plans and seeing them resolve.

Inference

Reasoning from partial evidence to a conclusion about hidden state.

Engine satisfaction

Gratification from a built system producing escalating output.

Analysis paralysis

Decision slowdown caused by many comparable options with calculable consequences.

Spatial reasoning

Reasoning about position, adjacency, paths, and lines on a represented space.

Execution

Outcome depends on the player’s timing or physical precision rather than on which option is chosen.

Calculation

Outcome rewards exact enumeration of moves, counts, or odds within a bounded, fully specified space.

Recall

Outcome depends on retaining and retrieving state or sequences seen earlier in play.

Emotional

Tension

An outcome that matters is held unresolved over a span of play the mechanic itself creates, while the player keeps acting or must wait.

Flow

Absorbed, continuous engagement produced by well-matched challenge and feedback.

Ownership

Sense that an artefact (character, deck, map, story) is distinctively the player’s own.

Consequence weight

Heightened awareness that decisions are irreversible or costly.

Frustration risk

Propensity to produce feelings of unfairness or helplessness, typically from low-agency loss.

Sunk cost

Reluctance to abandon invested positions even when suboptimal.

Fear of missing out

Anxiety over opportunities others may take or windows that are closing.

Spectacle

Rare, amplified, or staged outcomes produce memorable peaks distinct from sustained uncertainty.

Compulsion

Habit-forming pull to return or repeat, produced by scheduled rewards or escalating counters rather than by decision quality.

Social

Bluffing

Incentive to misrepresent one’s state or intentions.

Negotiation

Incentive to bargain, promise, or form deals with other players.

Social deduction

Reading other players’ behaviour to infer hidden roles or intent.

Kingmaking

A player who cannot win can decide which other player does.

Teamwork

Coordination and shared problem-solving among players with a common goal.

Alpha player

One player directs the decisions of others in a shared-goal structure, reducing their effective agency.

Betrayal

Incentive or opportunity to break an alliance or shared goal for individual gain.

Contested fairness

Players are prone to dispute an outcome’s legitimacy because a human judgement or a deliberate asymmetry intervened in it.

Structural

Runaway leader

A leading position becomes self-reinforcing and hard to overturn.

Catch-up

Trailing players gain compensatory advantage.

Emergent narrative

Memorable stories arise from system interaction rather than authored content.

Replayability

Variation across plays that sustains interest.

Downtime

Periods where a player waits while others act.

Grind

Repetition required to make progress, with low per-repetition novelty.

Volatility

Outcomes swing substantially on single events.

Media and examples

Video

Digital games on any platform.

Tabletop RPG

Role-playing games with a facilitator or shared fiction, including solo journaling games.

Board & card

Board games, card games, dice games, and wargames, including app-assisted ones.

Physical

Sports, playground games, LARP, escape rooms, and dexterity games. Secondary: used for provenance and cross-medium comparison, never as an entry’s only medium.

Print

Printed puzzles and gamebooks: pencil puzzles, newspaper and magazine puzzle columns, and choose-your-path books. Secondary: used for provenance and cross-medium comparison, never as an entry’s only medium.

An entry lists a medium only when it gives at least one example in that medium. Entries carry three or more examples in chronological order, chosen to cover each listed medium where possible: one early or influential instance, one canonical instance, one recent instance, and one from a different medium. Each example note states how the mechanic manifests in that game rather than describing the game. Years are the first release of the edition cited; approximate dates are flagged. One example per entry may carry a Latest marker: a widely played game from 2020 or later that shows the canonical form, chosen so that different entries point to different games where possible. Where no such game exists, the marker falls on the most widely played one from 2015 or later.

Provenance and sources

Provenance records the earliest documented use we can cite, with a stated confidence level. Where origins are unknown or disputed we say so rather than guess. Every provenance claim and every structural definition is tied to a listed source. Verified entries have at least two sources, one of them not a wiki, and URLs are given only when they have been checked.

High

Earliest use is documented in a primary source or uncontested in the design literature.

Medium

A widely cited earliest use exists but earlier instances are plausible or the dating is loose.

Low

The named earliest use is the earliest documented instance found, but earlier instances are plausible or the evidence is thin, so it is not defended as an origin.

Unknown

No defensible earliest use; only a populariser or a period can be named.

Canonical reference works cited by key across entries:

• Katie Salen and Eric Zimmerman (2004). Rules of Play: Game Design Fundamentals.
• Jesse Schell (2008). The Art of Game Design: A Book of Lenses.
• Geoffrey Engelstein and Isaac Shalev (2019). Building Blocks of Tabletop Game Design: An Encyclopedia of Mechanisms.
• Raph Koster (2004). A Theory of Fun for Game Design.
• Tynan Sylvester (2013). Designing Games: A Guide to Engineering Experiences.
• Ernest Adams and Joris Dormans (2012). Game Mechanics: Advanced Game Design.
• Staffan Björk and Jussi Holopainen (2005). Patterns in Game Design.
• George Skaff Elias, Richard Garfield, and K. Robert Gutschera (2012). Characteristics of Games.
• Greg Costikyan (2013). Uncertainty in Games.
• Jon Peterson (2012). Playing at the World.
• Jon Peterson (2020). The Elusive Shift: How Role-Playing Games Forged Their Identity.
• Shannon Appelcline (2014). Designers & Dragons: A History of the Roleplaying Game Industry.
• Steve Swink (2009). Game Feel: A Game Designer’s Guide to Virtual Sensation.
• Henry Jenkins (2004). Game Design as Narrative Architecture.
• Jesper Juul (2007). Swap Adjacent Gems to Make Sets of Three: A History of Matching Tile Games.
• David Parlett (1999). The Oxford History of Board Games.
• David Parlett (1990). The Oxford Guide to Card Games.
• H. J. R. Murray (1952). A History of Board-Games Other Than Chess.
• Jesper Juul (2013). The Art of Failure: An Essay on the Pain of Playing Video Games.
• Sultan A. Alharthi, Olaa Alsaedi, Zachary O. Toups, Theresa Jean Tanenbaum, and Jessica Hammer (2018). Playing to Wait: A Taxonomy of Idle Games.
• James F. Dunnigan (1980). The Complete Wargames Handbook.
• Scott Rogers (2014). Level Up! The Guide to Great Video Game Design.
• Robin Hunicke, Marc LeBlanc, and Robert Zubek (2004). MDA: A Formal Approach to Game Design and Game Research.
• Tracy Fullerton (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.
• Jesper Juul (2005). Half-Real: Video Games between Real Rules and Fictional Worlds.
• Stewart Woods (2012). Eurogames: The Design, Culture and Play of Modern European Board Games.
• Sid Meier (2012). Interesting Decisions.
• Mark Brown (Game Maker’s Toolkit) (2020). The Two Types of Random in Game Design.
• BoardGameGeek community (2024). Board Game Mechanics.
• Wikipedia contributors (2024). Wikipedia.

Entry status

Draft

Skeleton or incomplete entry. Rendered with a banner and excluded from search.

Unverified

Complete entry whose sources or provenance have not yet been checked against primary material.

Verified

Complete entry with three or more examples; two or more sources, at least one not a wiki, including a book, paper, or rulebook with a locator; and provenance at high or medium confidence.

Status is display metadata, not a filter: all entries appear in the browse table, the graph, the timeline, and the data exports, with their status recorded. Drafts are excluded from full-text search.

Disagreement

Codings are judgment calls. Contributors who disagree with a coding should add their reasoning to the entry's property notes rather than change the value silently, so the record shows what was contested and why.

Data exports

All exports are regenerated on every build (schema version 20). Field meanings and every vocabulary are in codebook.json; mechanics.jsonvalidates against mechanics.schema.json. Full-text search on the home page can be narrowed by kind of entry (mechanic, ability, crafting, scaling, synergy, weapon, or game system), category, medium, and effect.

• mechanics.json: canonical nested export, one object per mechanic with references flattened to ids, integer ranks for the three ordinal properties, and every source with its publisher, URL, and access date.
• mechanics.csv: wide table, one row per mechanic; list fields joined with |.
• examples.csv: tidy table, one row per (mechanic, example).
• edges.csv: source,target,relation for network analysis.
• crosstabs.csv: every pairing of category and the eight properties, one row per cell, with expected count, Pearson residual, and bias-corrected Cramér's V for the pair.
• effect-pairs.csv: effect pairs carried by at least five of the same mechanics, with lift.
• property-effects.csv: property value and effect combinations carried by at least five mechanics, with shares and lift.
• sources.json: bibliography with cited-by lists.
• taxonomy.json: vocabularies with labels, descriptions, and value order.
• distances.csv: every pair of mechanics with its coding distance (properties differing, effect overlap).
• abilities.json, abilities.csv, and ability-examples.csv: the ability archetypes, one row per ability and one per (ability, example) with that game's gating.
• crafting.json, crafting.csv, and crafting-examples.csv: the crafting archetypes, one row per archetype and one per (archetype, example) with that game's requirements.
• scaling.json, scaling.csv, and scaling-examples.csv: the scaling archetypes, one row per archetype and one per (archetype, example) with that game's basis.
• synergies.json, synergies.csv, and synergy-examples.csv: the synergy archetypes, one row per archetype and one per (archetype, example) with that game's links.
• weapons.json, weapons.csv, and weapon-examples.csv: the weapon archetypes, one row per archetype and one per (archetype, example) with that game's limits.
• systems.json, systems.csv, and system-examples.csv: the game system archetypes, one row per archetype and one per (archetype, example) with the mechanics that game combines.
• citations.bib: one BibTeX record per entry; updates.xml: a feed of entries by last edit.

Licence and citation

The catalog's text, codings, and data exports are licensed underCreative Commons Attribution 4.0; the site's software is under the MIT licence. Cite the catalog as a whole from the repository's CITATION.cff, or an entry from the "Cite this entry" block on its page. Suggested attribution: Game Mechanic Compendium, James West Jr., CC BY 4.0.

Adding an entry

Copy docs/ENTRY_TEMPLATE.md to src/content/mechanics/<kebab-case-id>.md, fill the frontmatter against the vocabularies above, write the body under the standard headings, and runnpm run lint:content. The build rejects unknown vocabulary values, dangling references, and verified entries that fall short of the sourcing standard.