Living Narrative Engine #2

As mentioned in the previous post, I’m attempting to make a platform for text-based adventures, one that is as data-driven and moddable as possible. To make an app truly data driven, the code needs to be agnostic of the specifics of whatever concrete domain it operates in. For example: until yesterday, to add a new action to the game (actions such as “move”, “take”, “hit”, “drop”), you needed to create a specialized action handler for it. Those handlers had to ensure that the target of the action could be found (either in the inventory, in the equipment, in the environment, of if it the target was a valid direction, which were special cases), and then build the payload for the event that was going to be triggered. Well, thanks to the indefatigable help of Gemini 2.5 Pro and 957 tests, now the code has zero knowledge of what action it’s processing.

The entirety of a specific action’s definition looks like this now:

{
  "$schema": "../schemas/action-definition.schema.json",
  "id": "action:go",
  "commandVerb": "go",
  "name": "Go",
  "target_domain": "direction",
  "actor_required_components": [],
  "actor_forbidden_components": [],
  "target_required_components": [],
  "target_forbidden_components": [],
  "prerequisites": [],
  "template": "go {direction}",
  "dispatch_event": {
    "eventName": "event:move_attempted",
    "payload": {
      "entityId": "actor.id",
      "direction": "resolved.direction",
      "previousLocationId": "context.currentLocation.id",
      "connectionEntityId": "resolved.connection.id",
      "targetLocationId": "resolved.connection.targetLocationId",
      "blockerEntityId": "resolved.connection.blockerEntityId"
    }
  }
}

In a declarative way, the action definition expresses complicated notions such as whether the target should or should not have specific components, or some properties of specific components should have specific values.

The most complex part is the payload. For that, a small scripting language had to be invented. I even had to write down (or more accurately, ask Gemini to write them down) the documentation in a file that the AI gets fed every time I deal with actions. A small excerpt of the docs:

## 3. Payload Source Mapping Conventions

The string values provided for keys within the `dispatch_event.payload` object define where the data for that payload field should come from. The Action Executor (the system component responsible for processing successful actions and dispatching events) is responsible for:


-Parsing these mapping strings.
-Retrieving the corresponding data from the runtime `ActionContext` (which includes the actor entity, resolved target/direction, current location, parsed command, etc.).
-Handling potential `null` or `undefined` values gracefully (e.g., by omitting the field from the final payload or explicitly setting it to `null`).
-Performing necessary type conversions, especially for `literal.*` mappings.

The following mapping string formats are defined:

## 3.1 Actor-Related Data

`actor.id`

Source: `context.playerEntity.id`
Description: The unique ID of the entity performing the action.
Type: String or Number (depending on entity ID type)

`actor.name`


Source: `getDisplayName(context.playerEntity)`
Description: The display name of the acting entity.
Type: String


`actor.component.<ComponentName>.<property>`

Source: `context.playerEntity.getComponent(ComponentName)?.<property>`
Description: Retrieves the value of `<property>` from the specified `<ComponentName>` attached to the acting entity.
Example: `actor.component.StatsComponent.strength`
Type: Varies based on the component property type.
Executor Note: Must handle cases where the component is not present on the actor or the specified property does not exist on the component. Should resolve to `null` or `undefined` in such cases.


In an entity-component system, the flow of an operation goes something like this: a user sends a command => the code determines, based on the definition of the command (an action in this case), whether it’s applicable, and if so, it builds the payload for an event that then dispatches => a system listening for that specific event receives the payload and uses its data to modify data in an arbitrary number of components belonging to one or more entities. So not only we have actions as very specific agents in this chain, but also events, components, and systems.

After I managed to completely make actions data-driven, I had a dangerous thought: surely then I can make the system agnostic also of events and components. Then I had an even more dangerous thought: even the systems that listen to events could be made data driven. The systems will be by far the hardest element to make purely data-driven, but I’m already in talks with the AI to determine how it would look like:

{
  "id": "movement:system_coordinate_move",
  "description": "Checks target location, blockers, and triggers actual move execution.",
  "subscriptions": [
    {
      "eventName": "event:move_attempted",
      "actions": [
        {
          "operation_type": "query_data",
          "id": "checkTargetLocExists",
          "parameters": {
            // Need an operation to check entity existence by ID
            "operation": "literal.string.check_entity_exists", // Hypothetical operation
            "entityIdSource": "event.payload.targetLocationId",
            "result_variable": "literal.string.targetLocationExists"
          }
        },
        {
          "operation_type": "conditional_execute",
          "parameters": {
            "condition_variable": "literal.string.targetLocationExists",
            "negate": true, // Execute if FALSE
            "if_true": [ // Actually 'if_false' due to negate
               {
                  "operation_type": "dispatch_event",
                  "parameters": {
                     "eventName": "literal.string.event:move_failed",
                     "payload": { // Construct failure payload
                        "actorId": "event.payload.entityId",
                        "direction": "event.payload.direction",
                        "reasonCode": "literal.string.TARGET_LOCATION_NOT_FOUND",
                        "details": "literal.string.Destination does not exist."
                        // ... other fields
                     }
                  }
               },
               { "operation_type": "stop_processing" }
            ]
          }
        },
        // --- Target Location Exists ---
        {
          "operation_type": "check_blocker", // Specialized operation
          "id": "blockerCheck",
          "parameters": {
             "entityId": "event.payload.entityId",
             "direction": "event.payload.direction",
             "blockerEntityId": "event.payload.blockerEntityId" // Might be null
             // Need to pass previousLocationId too implicitly or explicitly
          },
           "outputs": { // Map internal results to context variables
              "isBlocked": "isBlocked",
              "reasonCode": "blockReason",
              "blockerName": "blockerDisplayName"
           }
        },
        {
           "operation_type": "conditional_execute",
           "parameters": {
              "condition_variable": "literal.string.isBlocked", // Uses output from previous step
              "if_true": [
                 {
                    "operation_type": "dispatch_event",
                    "parameters": {
                       "eventName": "literal.string.event:move_failed",
                       "payload": {
                          "actorId": "event.payload.entityId",
                          "direction": "event.payload.direction",
                          "reasonCode": "variable.blockReason", // Use reason from blocker check
                          "details": "expression.format('Blocked by {0}', variable.blockerName)",
                          "blockerDisplayName": "variable.blockerName"
                          // ... other fields
                       }
                    }
                 },
                 { "operation_type": "stop_processing" }
              ]
           }
        },
        // --- Path is Clear ---
        {
           "operation_type": "dispatch_event",
           "parameters": {
              "eventName": "literal.string.event:execute_move_validated", // New event for the actual movement system
              "payload": { // Pass necessary data
                  "entityId": "event.payload.entityId",
                  "targetLocationId": "event.payload.targetLocationId",
                  "previousLocationId": "event.payload.previousLocationId",
                  "direction": "event.payload.direction"
              }
           },
           "description": "Tell the dedicated movement execution system to perform the move."
        }
      ]
    }
  ]
}

All operations in a system could also be made data-driven. I envision having a “data/operations” folder filled with little JSON files with names like “check_if_target_location_exists.operation.json”. Ah, what beauty.

Living Narrative Engine, #1

This past week I’ve been in my equivalent of a drug binge. Out of nowhere, I became obsessed with the notion of implementing a text-based immersive sim relying on “vibe coding,” as has come to be known the extremely powerful approach of relying on very competent large-language models to code virtually everything in your app. Once I tasted Google’s Gemini 2.5 Pro’s power, I fell in love. The few times it makes mistakes, it’s usually my fault for not expressing my requirements correctly. Curiously enough, OpenAI released a more powerful model just a couple of days ago: o3. Sadly it’s under usage limits.

Anyway, let me explain about the project, named Living Narrative Engine. You can clone the repository from its GitHub page.

It’s a browser-based engine to play text adventures. My intention was to make it as moddable and data-driven as possible, to the extent that one could define actions in JSON files, indicating prerequisites for the action, the domain of applicability, what events it would fire on completion, etc, and the action-agnostic code would just run with it. I mention the actions because that’s the last part of the core of this app that I’m about to delve into; currently actions such as “look”, “hit”, “move”, “unlock” and such are harcoded in the system: each has a dedicated action handler. That’s terrible for the purposes of making it data-driven, so I’ve requested deep-search research documents and product requirement documents from ChatGPT, which look hella good. Before I start tearing apart the action system of the app, which may take a couple of days, I wanted to put this working version out there.

Currently the app does the minimum for a demo: it spawns you in a room, lets you move from room to room, kill a goblin, open doors, take items, equip items (and drop and unequip them), and also unlock doors (which was the hardest part of the app to codify). I have introduced quest and objective systems that listen to conditions; for example, there’s no key in the demo to open the door where the goblin is located, but when the event “event:entity_died” fires with that goblin as the subject, the door opens mysteriously. The single JSON file that drives that is below:

{
  "id": "demo:trigger_unlock_treasure_door_on_goblin_death",
  "listen_to": {
    "event_type": "event:entity_died",
    "filters": {
      "deceasedEntityId": "demo:enemy_goblin"
    }
  },
  "effects": [
    {
      "type": "trigger_event",
      "parameters": {
        "eventName": "event:unlock_entity_force",
        "payload": {
          "targetEntityId": "demo:door_treasure_room"
        }
      }
    }
  ],
  "one_shot": true
}

The goal is to make everything as data-driven and agnostic as possible.

Everything in the game world is an entity: an identifier and a bunch of components. For example, if any entity has the Item component, it can be picked up. If it has the Openable component, it can be opened and closed. If it has the Lockable component and also the Openable component, the entity cannot be opened if it’s locked. This leads to fascinating combinations of behavior that change as long as you add or remove components, or change the internal numbers of components.

The biggest hurdle involved figuring out how to represent doors and other passage blockers. All rooms are simple entities with a ConnectionsComponent. The ConnectionsComponent indicates possible exits. Initially the user could only interact with entities with a PositionComponent pointing to the user’s room, but doors aren’t quite in one room, are they? They’re at the threshold of two rooms. So I had to write special code to target them.

Anyway, this is way too much fun. Sadly for the writing aspect of my self, I haven’t written anything in about five days. I’ll return to it shortly, for sure; these binges of mine tend to burn out by themselves.

My near-future goal of this app is to involve large-language models. I want to populate rooms with sentient AIs, given them a list of valid options to choose from regarding their surroundings (such as “move north”, “eat cheesecake”, or “kick baboon”), and have them choose according to their written-in personalities. I want to find myself playing through RPG, text-based campaigns along with a harem of AI-controlled isekai hotties.

I’m going back to it. See ya.

Life update (03/18/2025)

I spend most days either working or writing, but in the periods when I’m at home and I don’t have to work and I think that I’ve done enough writing for the day, I try to either exercise or play some game. Ever since All on Board! came out (it’s an app to play board games in VR), even though it’s quite barebones compared to what it will hopefully become in some months, I’ve regained the sense of joy that comes with playing board games. The mind stretches to grab the corners of the system each board game has created, which gives you a thrilling sense of your options and possible strategies.

I’m a systems builder, so every time I get back into board games, I fantasize about creating my own. A week or so ago I ended up gathering all the game mechanics I could find online, categorizing them, and posting them on this site, to the likely annoyance of many of my very few subscribers; when my emails hit their inbox, they must have expected to get new parts of stories, only to find themselves flooded with posts about game mechanics. That must have felt like a non sequitur. Anyway, I’d love to design my own board game, but I don’t have time to focus hard on anything else when I’m deep into writing a story. If I were unemployed, I suspect I would expect the rest of my spare time either preparing the next writing session, or fucking around.

Regarding digital games, these days it’s hard to pick anything decent. AAA games are on a deserved downward spiral. Most of the legendary studios, those that haven’t disappeared, exist in name only; the actual talent bailed. Bethesda needs to fire their lead writer, and perhaps Todd himself. Fans are shouldering the massive endeavor of keeping great gaming traditions alive; Morrowind modding, for example, is astonishing these days. Regarding huge games, I’m waiting to buy a better graphics card in order to finally have my playthrough of Cyberpunk 2077 in VR. Once you play certain things in VR, you really don’t want to spoil the experience by playing flat.

Anyway, I did buy a new game and enjoyed it a lot. Spent my whole Sunday afternoon playing it. This one was a bit of a meme a couple of years ago, but it still seemed up my alley: it’s the visual novel (of sorts) named The Coffin of Andy and Leyley. Supposedly a horror game, but it felt like a dark comedy to me. As well as a sibling abuse simulator. Mentioning any of the most conspicuous elements you experience in the story would involve spoilers.

In any case, you ultimately play, and anticipate upcoming chapters, because of Andrew and Ashley, the siblings in charge of that wild ride. Like in any great story, you return to it because you want to spend more time with one or more characters. Due to the subjects the author touches in this game, apparently she (her updates sound like they’re written by a woman, but I wouldn’t be sure these days) got death threats and partially doxxed, which led her to step back from the spotlight. However, the author is uncompromising in her dark vision, and refuses to bend the knee. Such authors are almost the only kind I can respect these days.

Oh, and Ashley Graves, the manipulative, sociopathic half of the sibling couple… I’m down bad for that black-hearted bitch. Even though not even a new birth would fix her.

All board game mechanics: Victory/Scoring Mechanisms

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


End Game Bonuses: Players earn (or lose!) bonus Victory Points (VPs) at the end of the game based on meeting victory conditions.

Highest-Lowest Scoring: Each player’s score is equal to the lowest value of several categories. Whoever has the highest lowest value is the winner.

This system is normally known as Knizia scoring. Tigris & Euphrates is an early example of this mechanism. Players are collecting four different color cubes – red, green, blue, and yellow – and their score is the color that they have the least of. A player with 12 red, 10 green, 6 blue, and 2 yellow has a final score of 2. This forces players to not be too specialized in which cubes they collect.

Highest-Lowest Scoring is a special case of Set Collection, where only complete sets are counted.

Kill Steal: Players contribute towards completing a task, but only the player who finally completes it gets a particular benefit or bonus reward (even if others share in the base level benefit).

Legacy Game: A multi-session game in which the state of each subsequent session irreversibly builds on the legacy of the previous one. Permanent and irreversible changes to the game state carry over to future plays. Components can be written on with permanent ink, torn apart, covered with stickers, and more. This mechanism was introduced in Risk Legacy. This should not be confused with the mechanism, which modifies the state between sessions, but the state can be reversed (e.g. Campaign Games). Games with reversible states existed much earlier.

Victory Points as a Resource: Victory Points (VPs) may be spent as a currency to impact the game state.

Business or Economic games that use currency and give the win to the players with the most money are common examples of this mechanism. However games with other themes like Small World also use this mechanism. Games where currency (or other resources) can contribute in a minor fashion as extra VPs at the end game (usually at some discount rate) should not be tagged with this mechanism, but rather as End Game Bonuses.

All board game mechanics: Technology/Progression

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


Algorithm Creation: Players design sequences of conditional operations or “programs” that execute automatically once set in motion. Success depends on anticipating how these algorithms will interact with a changing game state and with other players’ algorithms. This might involve programming the movement and actions of units, creating economic systems that operate independently, or establishing decision trees that respond to certain triggers.

Deck Construction: As the first step, or prior to playing the game, players create the deck they will use.

Knowledge Threshold Unlocking: Players accumulate specific types of knowledge or expertise during gameplay, which are tracked separately from other resources. When players reach certain knowledge thresholds in specific domains, new actions or strategies become available. This differs from tech trees in that knowledge accumulation happens gradually through many small actions rather than through discrete purchases or advancements.

Momentum Tracks: Actions build momentum when repeated in consecutive turns. Higher momentum provides increasing benefits for continuing the same strategy but creates penalties for switching. Players must decide when to pivot versus when to commit deeper. Example Implementation: An economic game where continued investment in specific industries creates increasing returns but also increasing risk of market collapse, requiring careful timing of strategy shifts.

Move Through Deck: Players Move Through a Deck of cards. Typically the goal is to reach the bottom (One Deck Dungeon), find and defeat a boss (Chainsaw Warrior), or simply know when to quit (Incan Gold).

Tech Trees/Tech Tracks: During the course of the game, new Actions become available to specific players, or existing Actions are improved. These are often themed as Technologies, but do not need to be. Sometimes this is expressed as a Tree, where gaining one Tech unlocks multiple other Techs. Or it can be a track, where advancing along the track unlocks upgraded or new Actions.

All board game mechanics: Resource Management

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


Automatic Resource Growth: The automatic increase of a resource triggered by a particular, conditional, deterministic (not random) game state.

Example 1. Unacquired resources in Agricola:

  • Uncollected wood from the wood-collection action space (condition) will offer +1 wood (result) on the following round (game state).

Example 2. Acquired resources in Agricola:

  • Two pigs in your farm, in an area with space enough for 3 pigs (condition) will automatically produce a 3rd pig (result) during the breeding phase of that round (game state).

Counter-example 1. Income in Monopoly:

  • Collect $200 (result) when passing “GO” (game state).
  • There is no condition (ex: if you own 1 or more properties)

Counter-example 2. Random Production in Catan:

The production is random not deterministic.

Players collect resources at the beginning of each turn based on a die roll.

Deck / Bag / Pool Building: Players play cards out of individual decks, seeking to acquire new cards and to play through their decks iteratively, improving them over time through card acquisition or card elimination.

It may include a “random-draw” to form a hand from the deck for the current round (as in Star Realms) and the deck is automatically reset once the draw pile is exhausted; or it may allow access to all available cards at once (as in Concordia) until the discards are retrieved. The latter may embody the Action Retrieval mechanic, where the card use activate actions.

This category also covers Bag Building, Pool Building, and related mechanisms (using chits, dice, etc).

Dominion pioneered this mechanism.

Hand Management: Hand management games are games with cards in them that reward players for playing the cards in certain sequences or groups. The optimal sequence/grouping may vary, depending on board position, cards held and cards played by opponents. Managing your hand means gaining the most value out of available cards under given circumstances. Cards often have multiple uses in the game, further obfuscating an “optimal” sequence.

Income: Players gain resources at defined times.

Increase Value of Unchosen Resources: If players do not select certain Actions or Resources, then they increase in value. Puerto Rico is a classic example of this technique, as unchosen roles have a coin placed on them. This mechanism is a simple way for designers to balance different options. The money may either come from the bank, as in Puerto Rico, or from the players themselves, as is done in Small World, where players must place a coin on factions that are skipped.

Loans: Players may take a Loan from the bank to get more money.

Examples include Monopoly where players can mortgage properties, and Age of Steam, where taking loans is a key strategic consideration.

Multi-Dimensional Resource Constraints: Resources exist in multiple dimensions or aspects simultaneously, and different actions require specific configurations across these dimensions. For example, a resource might have quantity, quality, and accessibility attributes, with different actions requiring different combinations of these attributes.

Resource Conversion Chains: Resources must be converted through a series of sequential transformations to become more valuable or useful. This creates a supply chain management challenge where players must balance efficiency against flexibility. Players may specialize in different parts of the chain, creating interdependencies. Examples include raw materials that must be refined, then manufactured, then distributed to be worth maximum points.

Resource Queue: Resources are in an ordered queue, and can only be pulled from one end, or rarely, both ends, but not the middle.

Resource to Move: Players expend a Resource to Move. This is commonly themed as fuel, but other games use money or other commodities.

All board game mechanics: Player Interaction/Negotiation

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


Alliances: Players have formal relationships that may change over the course of the game. This differs from Negotiation in that these relationships are governed by specific game rules. For example, in Dune, players may form alliances at each Nexus phase, which last until the next Nexus. During that time the players win together, may not attack each other, and grant their ally a special power. In Struggle of Empires players bid for the right to select their ally for that round, which is governed by similar rules.

Cooperative Game: Players coordinate their actions to achieve a common win condition or conditions. Players all win or lose the game together.

Bribery: Players offer bribes to other players to get them to perform specific actions. Typically players will place bribes on certain actions, and if another player selects that choice they get the bribe. Otherwise it is returned to the player. Santiago and Tonga Bonga operate this way. Bribery can also be a part of a Negotiation mechanism, as players may offer bribes which may or may not be binding. Intrigue is an example of the latter.

Collaborative Control: Multiple players jointly control a single game element (like a powerful neutral faction) and must coordinate or negotiate how to use it. This differs from fully cooperative games in that players still have individual goals, but share control over certain powerful elements. The shared element may provide significant advantages, but requires agreement among the controlling players to direct effectively.

Communication Limits: Games may limit players from communicating with one another openly. These restrictions can be absolute as they relate to certain specific pieces of information, or they may restrict certain types of communication, such as speaking.

Neighbor Scope: Actions, resources, or resolution are shared between neighbors.

Negotiation: Players make agreements about coordinating action, beyond simply Trading.

Agreements may be either binding or non-binding. Diplomacy is a notable example of the latter.

Risk Pooling: Players can join forces to mitigate risks by contributing to shared insurance mechanisms or joint ventures. When negative events occur, the pooled resources absorb the impact, but players must negotiate or follow predetermined rules for sharing the benefits when positive outcomes occur. This creates interesting dynamics where rational self-interest must be balanced against collective security.

Role Playing: Some board games incorporate elements of role playing. It can be that players control a character that improves over time. It can also be a game that encourages or inspires Storytelling. This mechanic can be viewed as an extension of Variable Player Powers.

Semi-cooperative Game: A game in which players are cooperating and competing with each other throughout the game, while trying to complete a common objective. There have been several ways to implement this. One classification is Grand Winner format. A Grand Winner game has two possible outcomes: A) One or more players win ) No players win. A game where players sometimes cooperate and sometimes compete but one always wins is not semi-cooperative. It is a Competitive game with a Negotiation mechanism. Other formats of semi-cooperative games proceed similar to cooperative games but winning and losing objectives are triggered individually such that the outcome may be that no players win, all players win or some players win and some lose. The individual win/loss games have shown to be far less controversial than the Grand Winner format.

Social Capital System: Beyond just resources, players build reputation and influence with different factions in the game. This social capital functions differently than regular resources – it’s gained through consistent behavior patterns and can collapse rapidly if players act against established expectations. Example Implementation: A political game where maintaining consistent ideological positions builds trust with certain factions, providing increasing benefits, but flip-flopping causes rapid reputation collapse.

Take That: Competitive maneuvers that directly target one opponent’s progress toward victory, but do not directly eliminate any characters or components representing the opponent. Such mechanics include stealing, nullifying, or force-discarding of one opponent’s resources, actions, or abilities. A take-that maneuver often results in a dramatic change in the players’ position of power over a relatively short period of time.

It is unclear whether this includes 2 player games (as every action inhibits your one opponent’s victory).

Team-based Game: In team-based games, teams of players compete with one another to obtain victory. There are a variety of possible team structures, including symmetrical teams like 2v2 and 3v3, multiple sides like 2v2v2, and even One vs. All.

Trading: Players may Trade assets directly with each other, rather than via a Market.

Traitor Game: A traitor game can be seen as a kind of team game, or as a cooperative game with a betrayal mechanism. The traitors typically win by triggering a failure condition for the players. For this mechanism, a traitor game is characterized by traitors that begin the game with hidden identities, or are assigned them during the game.

All board game mechanics: Player Elimination/Catch-up

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


Catch the Leader: The game systems advantage players that are behind or disadvantage players that are ahead.

Hot Potato: A single item is bad for players to have, and players strive to pass it to other players or avoid it so they are not holding it at game end or some other defined time. Example games include Old Maid, Exploding Kittens, and Catch Phrase!.

Lose a Turn: This is a meta-mechanism that can be applied to a variety of turn structures. A player who “Loses a Turn” must skip their next opportunity for a turn, and will go to the next round, or the next time their turn arises.

Once-Per-Game Abilities: Players have a special ability that they can use one time per game. These may be unique to them, like ‘feats’ in Warmachine, or common to all players, like the special power chits in Finca. Often players will receive bonus Victory Points if they do not use their one-time abilities during the game.

Player Elimination: A player can be removed from the game, no longer participating.

In some such games, all of an eliminated player’s material is removed from the game as well; in other such games this material may remain in play as neutral material. (E.g. an eliminated player’s armies and cities on a map might disappear, or might be become neutral armies and cities.)

In most games, an eliminated player cannot win, but this is not necessarily true. (E.g. in some games with victory based on scores, an eliminated player’s score is still eligible for victory.)

In most games with player elimination, a player is eliminated involuntarily. But in some games a player can choose to drop out (with hope that their score suffices to win (e.g. Wooly Wars).

In some games, player elimination is possible, but rare in practice and does not happen in a “typical session” (e.g. Age of Steam).

In some games, player elimination is common. In the extreme case, all players but one (the sole surviver = eventual winner) are eliminated during a session (e.g. Titan). In many player elimination games, typically some players are eliminated but multiple other players are not (e.g. Werewolf and BANG!).

Player elimination does not include two-player-only games where the goal is to defeat the opponent, e.g., Chess.

All board game mechanics: Placement/Building

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


Crayon Rail System: The Crayon Rail System is a subcategory of Route/Network Building. Types of these games use crayon or other non-permanent methods of making connecting lines on a board, often eraseable. The most popular Crayon Rail games are part of the Empire Builder system.

Layering: Components are placed above other components, partially covering the ones below, or overlapping in various ways. Only the topmost visible icons/areas are active.

Examples include Patchistory and Smartphone Inc. using cards, and Taluva using tiles.

Modular Board: Play occurs upon a modular board that is composed of multiple pieces, often tiles or cards.

In many games, board placement is randomized, leading to different possibilities for strategy and exploration.

Some games in this category have multiple boards which are not used simultaneously, preserving table space. Unused boards remain out of play until they are required.

Tile Placement: Tile Placement games feature placing a piece to score VPs or trigger actions, often based on adjacent pieces or pieces in the same group/cluster, or keying off non-spatial properties like color, “feature completion”, cluster size etc.

A classic example is Carcassonne, where a player randomly draws a tile, places it next to other tiles (along with a meeple), in order to complete map features.

All board game mechanics: Physical/Party Game Elements

The following is a list of all board game mechanics I know in this category, and that aren’t too niche. Card game mechanics are also included. I’m posting this mainly for my own reference.


Drawing: Players draw a picture and other players guess what the picture is intended to depict.

Flicking: A Physical Action needs to be performed by one or more players to determine the outcome of the action.

Ordering: The objective of the game is to rearrange a group of game elements from a disordered to an ordered state.

Paper-and-Pencil: The game is developed using paper and pen/pencil to mark and save responses or attributes that, at the end of the game, are used to score points and determine the winner.

A game that merely keeps track of score on a sheet of paper does not use a paper-and-pencil mechanism.

Physical Removal: Pieces are removed from a structure, and play is affected by things that fall (as in Ker Plunk), or a complete collapse of the structure (as in Jenga).

Speed Matching: A pattern is revealed, typically through a card flip, and players try to be the first to find a match with other game elements on the table, or see if a match exists.

Stacking and balancing: Players must physically stack and balance pieces. Junk Art and Bandu are examples.

Storytelling: In storytelling games, players are provided with conceptual, written, or pictorial stimuli which must be incorporated into a story of the players’ creation. Once Upon a Time uses a selection of words while Rory’s Story Cubes include ambiguous symbols. Some games like Snake Oil and Big Idea prompt players to pitch a product, which frequently takes the form of a brief story or vignette.

Other storytelling games include titles such as Tales of the Arabian Nights and Above and Below, game designs in which players don’t create their own stories, but instead experience a story from the inside as one of the participants. Games along those lines might present players with a particular narrative situation, after which the player will make a choice that affects which end to the narrative is told — with the results of this narrative affecting the player’s standing in the game.