Tag: board games

Life update (06/07/2026)

On By Jon UreñaIn Escritura, Inteligencia artificial, ProgramaciónLeave a comment

These past six months or so, I’ve been working on three different projects, or more accurately, on three distinct ideas for projects:

  • A structured way of creating stories that doesn’t rely on an act structure, by which I mean that the whole stories are based on the causality of tracking entities, entity statuses, cast members, facts, beliefs, secrets, locations, objects, visible affordances, events, intentions, plans, clocks, obligations, consequences, open threads, relationships, and emotions. As part of this project idea, I also wanted to structure worldbuilding and propagation of canon facts.
  • A platform to encode any card/board game relying on a game-agnostic engine, which would help prototype card/board games.
  • A maximally-emergent, causality-first simulation that would be able to produce the kind of adventures you get through Dwarf Fortress, Rimworld, Skyrim, etc., without relying on any scripting or game director.

The story-related projects, which ended up being two repositories in Node/Typescript, were the easiest, although they were complicated projects in their own right. But the other two projects deserve their own paragraphs.

That platform to encode any card/board game started as an extremely-ambitious notion: any user would be able to encode every aspect of any game in YAML files. YAML that basically works as programming is a terrible idea, which I realized deeper into the project. I started programming it in Node/Typescript, which was also a terrible idea: it’s far too slow of a combination when it involves AST parsing of the YAML; I had to spend lots of time bytecoding or Rust WASM-fying parts of the Typescript engine to get decent performance, which was never good enough for me, and a lot of possible wins were denied by marshalling issues. But by far, my biggest mistake was proving the project’s ability to accomodate multiple card/board games by implementing two games: Texas Hold ‘Em and Fire in the Lake COIN. Texas Hold ‘Em was mostly fine despite the YAML base: it took like three days.

Merely thinking of Fire in the Lake makes my skin crawl now. Fire in the Lake is an extraordinarily complex board game representing the Vietnam War. Not exactly a traditional wargame, although it’s hard to explain. The point is that back in 2020, before large language models, I attempted to program it in Rust to learn the language. Huge mistake. Having to abandon that project a third of the way in let a splinter stuck in me from which I never fully recovered. So months ago, I decided I would rely on large language models to take the splinter out and properly implement Fire in the Lake. Huge fucking mistake.

The Fire in the Lake map is extremely complex. The adjacencies between provinces and cities are confusing, which involves country borders as well, but much worse, it also features LoCs like roads and the Mekong river. Merely representing it visually without just pasting the map on screen was a fucking nightmare. As if the map graph wasn’t enough of a mess, what the factions can do is much worse: operations and optional special activities, each of which can be as complex as entire regular games. I’m talking sweeping, assaulting, subverting, governing, air striking. Then you have the event deck, which causes stuff to happen on the map and on the markers and tracks, which is easy enough to depict, but the game designers also went out of their way, for which I commend them except for the fact that I tried to program this cursed game, to make almost every card of the 130 its own little exception. Some cards offered grants for actions which may or may not be optional, some of which were taken by different factions other than the one currently playing. Again, makes my skin crawl. I had whole GitHub workflows dedicated to ensuring that the granting system didn’t shit itself.

After I managed to encode the entire game rules and content, which I did manage to do (a fleeting win), I got myself into the issue of encoding competent AI bots. I didn’t want to just copy the flowcharts, given that a computer would run the bots, so I had ChatGPT-Pro deep research what would make a competent human player for each of the factions. My intention was to encode that. I got really deep into AI architecture to figure out what kinds of bots would work well for my requirements, and I finally reached a point in which it seemed like I just had to push through, and keep iteratively improving the bot encoding, to finally get them running. But a few days ago, I found myself not even reading the tickets, not even checking out what was being committed. My subconscious had already understood that this project was a bust. It was crippled from the beginning, and I had done little else than push against entropy. I would never be happy enough with how Fire in the Lake would be shown on the web app, I would never feel comfortable enough with how it was implemented, and worse yet, the engine had taken in too much of Fire in the Lake’s specific shape that disentangling it to implement other games would make me have to fix Fire in the Lake at every step. So I gave up.

The third project was the maximally-emergent, causality-first simulation. From the beginning I had a very clear idea of what I wanted; basically by ideal game which nobody has built yet to my knowledge:

  • A simulation able to simulate dozens or hundreds (or thousands) of agents in an area the size of Skyrim, with settlements, roads, points of interest, etc.
  • The simulation should be maximally emergent and causality first. By which I mean that there would be no scripting and no game director. The simulation should be able to produce complex chains like this: a big monster gets displaced from a wilderness area due to the activity of some bandits -> the monster ends up hunting around some nearby road -> the monster attacks a caravan -> the caravan survivors reach a town and speak with the authorities about the attack -> the authorities decide to set up a bounty for the monster -> someone creates the bounty and posts it at some board -> some passing adventurers see the bounty and decide to take it -> they gear up and gather supplies for the hunt -> they travel to the area where the monster is supposed to be -> they track it to their den -> they find out some other adventurers casually killed the creature already. This all should happen due to causal chains, no scripting at all.
  • You as the player are indistinct to every other AI agent in the simulation. The simulation isn’t even aware that a human player exists. That means that the world continues regardless of what you do, but you can disrupt it.
  • Every agent, including the human player if any, acts on their beliefs, which may be truthful, stale, or based on straight lies. People gain beliefs by talking to each other, reading notices, observing the world. This allows chains like someone going home to take money, only to discover that the money is missing because someone has stolen it.
  • I should be able to chat through LLMs with any agent in the game, and the LLM would feed into the game which beliefs were actually shared or seeded, which would have gameplay effects.

That’s the main core. Such a simulation would allow any flavor and any kind of gameplay you could imagine. You would just have to build it incrementally. But I underestimated the complexity of such a project, which should be built upon an extremely-robust set of foundational documents of various categories. Mistakes I make during its implementation:

  • The foundational docs, while more comprehensive than those of any other repo, just weren’t comprehensive enough. They would have required several iterations of deep research with ChatGPT-Pro.
  • I approached it almost as a research project instead of something that would allow me to play it at every stage, even on the terminal.
  • I went breadth first: I wanted a significant set of gameplay mechanics in order to prove the emergent nature of the simulation, and found myself programming takeovers of institutions before I had properly proved that people could eat and shit regularly without dying.
  • By the time I figured out that even though I had banditry in, AI agents in simulations weren’t able to sustain their basic needs, the project was basically crippled; I just hadn’t accepted it yet. I should have built up step by step, being able to play it to the fullest along the way, and only add features that I missed while playing.
  • The AI architecture, while extremely competent in some regards, was crippled as well: I relied too much on GOAP because HTN felt like scripting at first. Then I realized that you could use HTN in a fully emergent way that respected the foundational principles, and relying on GOAP only for the leaf goals.

With this third project, I found myself also disheartened, and feeling that I was fixing mistakes in a crippled project, when likely I would need to build it from the ground up.

So, two days ago I decided to start from zero (a Re:Zero, you could say) both those complex projects: the card/board game one, and the emergent simulation one. It’s amazing how quickly projects progress once you’ve taken the lessons to heart and you’re on the right track. For the card/board game, I’m building it up following a ladder of game complexity. I already have Race to N, Tic-tac-toe, Connect Four, and Othello in. I’ve checked legality issues online, and found out that even if you don’t take money for it, publishing a page that simulates a game with an IP behind it is actually illegal (oops), so I couldn’t have uploaded the project with Fire in the Lake in regardless. While I intend to program in the kinds of games I’m most interested in playing (basically those on my gaming shelves), I won’t be able to upload them to the public repository.

Playing Othello and losing terribly

Regarding the simulation, that third project, it’s shaping up far better. I can play the current state of the simulation at any point through a terminal user interface, which at the moment is mostly rudimentary. The foundational documents are sets of dozens, and extremely comprehensive. I will no longer push for breadth, nor implement mechanics that I don’t miss through playing the simulation.

The important thing is that I’m feeling energized again to work on these projects. I woke up at six in the morning today eager to get back to it. And that’s the best state of being for a wrecked creature such as myself.

LudoForge #4

On By Jon UreñaIn gaming, Inteligencia artificial, ProgramaciónLeave a comment

Now that the evolutionary process to grow game definitions is progressing at a steady pace in my app, named LudoForge, I fed the architectural docs to ChatGPT so that it would write a good explanation on how it works. It may be interesting to those curious about how complex systems can grow organically through an evolutionary algorithm that mimics biological evolution.

Teaching a computer to invent tabletop games (and occasionally rediscover the classics)

If you squint, evolving game designs is a lot like evolving creatures: you start with a messy ecosystem of “mostly viable” little organisms, you test which ones can survive in their environment, you keep the best survivors—but you also keep a diverse set of survivors so the whole population doesn’t collapse into one boring species.

In our system, the “organisms” are game definitions written in a small, strict game DSL (a structured way to describe rules: players, state variables, actions, effects, win/lose conditions, turn order, and so on). Each candidate game definition is wrapped in a genome: basically an ID plus the full definition.

From there, the evolutionary loop repeats: seed → simulate → score → place into niches → mutate elites → repeat.

1) Seeding: where the first games come from

Evolution needs a starting population. We can generate seeds automatically, or import them from disk, or mix both approaches. The important bit isn’t “are the seeds good?”—it’s “are they valid and diverse enough to start exploring?”

So seeds must pass two kinds of checks before they’re even allowed into the ecosystem:

  • Schema validation: does the JSON structure match the DSL’s required shape?
  • Semantic validation: does it make sense as a playable ruleset (no broken references, impossible requirements, etc.)?

And there’s a third, subtle filter: when we place games into “niches” (more on that below), seeds that land only in junk bins like unknown/under/over are rejected during seed generation, because they don’t help us cover the design space.

Think of this as: we don’t just want “a bunch of seeds,” we want seeds scattered across different climates so evolution has many directions to run in.

2) Playtesting at machine speed: simulation as the “environment”

A human can’t playtest 10,000 games a day. A simulation engine can.

For every candidate game, we run automated playthroughs using AI agents (simple ones like random and greedy are enough to expose lots of structural problems). The engine repeatedly:

  1. Lists the legal moves available right now
  2. Checks termination (win/lose/draw conditions, cutoffs, loop detection)
  3. Lets an agent pick an action (with concrete targets if needed)
  4. Applies costs and effects, recording what happened
  5. Advances the turn/phase according to the game’s turn scheduler

Crucially: when a complex game definition tries to do something illegal (like decrementing below a minimum, or targeting something that doesn’t exist), the engine records skipped effects/triggers instead of crashing, so the system can observe “this design is broken in these ways” rather than just failing outright.

This is the equivalent of an organism interacting with the world and leaving tracks: “it tried to fly, but its wings didn’t work.”

3) Turning playthroughs into numbers: metrics, degeneracy, and fitness

After simulation, we compute a set of analytics that act like proxies for design quality—things like:

  • Agency: did players have meaningful choices, or were they railroaded?
  • Strategic depth (proxy): how large is the typical decision space?
  • Variety: do many different actions get used, or does one dominate?
  • Interaction rate: are players affecting each other or only themselves?
  • Structural complexity: is this a tiny toy, or something richer?

These are not “fun detectors.” They’re sensors.

Then we run degeneracy detection: filters that catch the classic failure modes of randomly-generated rulesets:

  • infinite loops / repeated states
  • non-terminating games (hits max turns/steps)
  • games with no real choices
  • trivial wins, dominant actions, excessive skipped effects, etc.

Some degeneracy flags cause an outright reject (hard gate), others apply a penalty (soft pressure), and too many penalties at once can also trigger rejection.

Finally, all of this becomes a feature vector, and we compute an overall fitness score—the number evolution tries to increase.

4) “Growing in niches”: why we don’t keep only the top 1%

If you only keep the single highest-scoring game each generation, you get premature convergence: the population collapses into one design family and stops surprising you.

Instead, we use MAP-Elites, which you can picture as a big grid of “design neighborhoods.” Each neighborhood is defined by a few chosen descriptors (think: agency bucket, variety bucket, etc.). Each candidate game gets “binned” into a niche based on its descriptor values, and then it competes only with others in that same niche.

  • Each niche keeps its best resident (the “elite”).
  • Over time, the map fills with many different elites: fast games, slow games, chaotic games, skillful games, high-interaction games, and so on.

This is how you get a museum of interesting survivors, not one monoculture.

5) Reproduction: mutation (and why mutation is structured, not random noise)

Once we have elites across niches, we generate the next generation by mutating them.

Mutation operators aren’t “flip random bits.” They are rule-aware edits that make plausible changes to game structure, such as:

  • tweak a number (thresholds, magnitudes)
  • add/remove/duplicate actions (with safety guards so you can’t delete the last action)
  • add/remove variables (while rewriting dangling references)
  • change turn schedulers (round-robin ↔ simultaneous ↔ priority-based, etc.)
  • add triggers and conditional effects
  • modify termination rules (win/lose/draw conditions)

The key is: the operator library is rich enough to explore mechanics, not just parameters.

Mutation retries (because many mutations are duds)

Some mutations do nothing (“no-op”), or produce something that can’t be repaired. The runner will retry with a different operator a few times; if it still can’t produce a productive mutation, it falls back to keeping the parent for that offspring slot.

This keeps evolution moving without pretending every random change is meaningful.

6) Repair, rejection reasons, and staying honest about failure

After mutation, we may run repair (optional), then validation and safety gates. If a candidate fails, it’s not just dropped silently—the system classifies why it failed:

  • repair failure
  • validation failure
  • safety failure
  • evaluation error
  • evaluation returned null fitness/descriptors

And it persists these outcomes for observability and debugging.

This matters because “evolution” is only useful if you can tell whether the ecosystem is healthy—or if you’ve started breeding nonsense.

7) Adaptive evolution: learning which mutations are actually useful

Not all mutation operators are created equal. Some will be reliably productive; others will mostly create broken genomes.

So the runner tracks per-operator telemetry every generation: attempts, no-ops, repair failures, rejection counts, and how often an operator actually helped fill a new niche or improve an elite. evolution-runner

Those stats feed into adaptive operator weighting, so the system gradually shifts its mutation choices toward what’s working in the current region of the design space—without hardcoding that “operator X is always good.”

8) Optional superpower: motif mining (stealing good patterns from winners)

Sometimes an evolved game contains a little “mechanical phrase” that’s doing real work—like a neat resource exchange loop, or a repeating pattern of effects that creates tension.

When motif mining is enabled, we:

  1. select elites (top per niche + global best)
  2. re-simulate them to extract trajectories
  3. mine repeated effect sequences (“motifs”)
  4. convert those motifs back into DSL effects
  5. feed them into a special mutation operator that can inject those motifs into new games

That’s evolution discovering a useful mechanic, then turning it into reusable genetic material.

9) Human taste enters the loop (without turning it into manual curation)

Metrics are helpful, but “fun” is subjective. So we can add human feedback:

  • ratings (“how good is this?”)
  • pairwise comparisons (“A or B?”)

Rather than asking the human to judge random games, the system uses active learning to choose the most informative comparisons—especially cases where its preference model is uncertain, and it tries to include underrepresented niches so taste is learned across the map.

Under the hood, the preference model is an ensemble trained online (so it can update continuously) and its uncertainty controls how much feedback to request per generation (adaptive budget).

Fitness can then blend:

  • “objective-ish” signals (metrics/degeneracy)
  • “human preference” signals

So the system doesn’t just breed games that are non-broken—it breeds games that align with what you actually enjoy.

10) Why this can rediscover known games and invent new ones

If your DSL is expressive enough to describe the rules of an existing game, then in principle there exists a genome that encodes it. Evolution doesn’t need to “know” the game—it only needs:

  1. Search operators that can reach that region of the rulespace (structural mutations, not just numeric tweaks)
  2. Selection pressure that rewards the behaviors that make that game work (choice, balance, interaction, clean termination, etc.)
  3. Diversity preservation so the system keeps exploring many styles instead of collapsing early

Once those are in place, rediscovery becomes a side-effect of searching a huge space under the right constraints. And invention is what happens when evolution stumbles into combinations nobody tried on purpose—then keeps them because the ecosystem rewards them.

The simplest mental model

If you want the non-technical version in one breath:

We generate lots of small rulesets, machine-play them thousands of times, score them for “does this behave like a real game?”, sort the survivors into many different “design neighborhoods,” keep the best in each neighborhood, then make mutated children from those survivors—occasionally learning from human taste and reusing discovered mechanics—until the map fills with strong and varied games.

That’s the evolutionary process: not magic, not random, but a relentless loop of variation + playtesting + selection + diversity.

LudoForge #3

On By Jon UreñaIn gaming, Inteligencia artificial, Programación1 Comment

If you don’t know about LudoForge, you should probably read the previous posts. In summary: I’m developing an app to evolve tabletop game prototypes according to a “fun” factor made up of plenty of fun proxies like player agency, strategic depth, etc. The code is now mature enough to run X evolutionary generations on demand, produce shortlists of the best games, and finish. That’s great because it means the code works well, although there’s always room for improvement. But the shortlist of four winners is absolutely terrible in a way that has had me giggling for a while. I’ll let ChatGPT explain these “games.”

Game 1: “The Shared Counter Chicken”

Two players take turns. There’s a shared number on the table that starts at 0 and can be increased up to 15. The “win condition” is simple: whoever makes it hit 15 wins instantly.

The game also includes a couple of other buttons that change other numbers… but those numbers can never actually produce a win. They’re basically decorative dials. One of them always gets set to 12, but the victory threshold for it is 20, so it’s like having a “Launch Rocket” button that always fuels you to 60% and then stops forever.

So what do players really do? They increment the shared counter… and then start playing a tiny psychological game of chicken: “I could push the counter closer to 15… but then you might get the final move.” So the game hands them some useless actions that function as “stalling.” If both players are stubborn, they can just keep stalling until the match times out.

It’s not strategy so much as who blinks first.

Game 2: “The Game Where You Can’t Move”

This one is my favorite kind of failure because it’s so clean.

The game defines two counters. The only action in the entire game says: “Decrease both counters.”

But the action is only allowed if both counters are greater than zero.

And the game starts with both counters at zero.

So on turn one, a player looks at the rules and… there is literally nothing they’re allowed to do. No move exists. The game doesn’t even fail dramatically. It just sits there like a vending machine with the power unplugged.

In other words: it’s a tabletop game prototype that begins in a stalemate.

Game 3: “First Player Loses: The Speedrun”

This one actually runs, which makes it even funnier.

There are two counters. One counter is the only one that can possibly lead to a win — the other one only goes downward forever, so its “win condition” is a permanent lie.

The “real” counter starts at 0, and there’s an action that increases it by 2. The victory threshold is 4.

Here’s what happens:

  • Player 1 goes first. Their only sensible move is: 0 → 2.
  • Player 2 goes next and does the same move: 2 → 4.
  • Player 2 instantly wins.

So the entire “game” is basically:

“Player 1 sets up the win for Player 2.”

It’s like a sport where the first player is forced to place the ball on the penalty spot and then politely step aside.

Game 4: “The Unwinnable Ritual”

Three players this time. There’s one shared counter. Winning requires the counter to reach 4.

But the rules only let you do two things:

  • Set it to 2.
  • Decrease it by 2 (if it’s above zero).

Notice what’s missing: any way to make it bigger than 2.

So the win condition is a castle in the sky. The game is a ritual where players take turns setting the number to 2, or knocking it back down toward 0. It can never, ever reach 4. No amount of cleverness changes that.

It’s essentially a machine that cycles between “2” and “less than 2” until you get bored or the turn limit ends it.

ChatGPT finished its report with this note: “The first evolutionary run didn’t produce brilliant board games. It produced life, in the same way early evolution produced algae and sea foam. These were rule-sets that technically existed… but didn’t yet deserve to.”

These idiotic games already provided fun by existing, so as far as I care, this app has already been a success. The good thing is that I have code to handle degeneracy, fitness, etc., so I simply have to tighten that code so some of these nonsensical points would either kill a genome or penalize its fitness.

By the way, earlier tonight I was playing tennis in VR with people across Europe while I waited for Claude Code to work through the tickets of one of the app’s new features. And yet the world is terrible. We live in the lamest cyberpunk dystopia imaginable.

Life update (03/18/2025)

On By Jon UreñaIn Escritura, Slice of lifeLeave a comment

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

On By Jon UreñaIn gamingLeave a comment

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

On By Jon UreñaIn gamingLeave a comment

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

On By Jon UreñaIn gamingLeave a comment

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

On By Jon UreñaIn gamingLeave a comment

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

On By Jon UreñaIn gamingLeave a comment

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.