All board game mechanics: Combat/Conflict Resolution

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.


Area-Impulse: Players subdivide turns into impulses alternating between players which repeat until both players pass (or in some cases a sunset die roll ends the impulses catching one or both players off guard). In those impulses a group of units is once activated or gets to act collectively before being marked spent. However instead of the activated units being grouped by a certain radius from a leader the units activated are in an area (and thus the need for the impulse system to have areas, not hexes). The areas exist to define scope of activation on an impulse (as well as restrict what can be done on that impulse with respect to attack and movement range). Thus each of a players groups of units each acts once by means of small alternating impulses instead of the traditional all my units then all your units. Finally, before the next turn of impulses, spent units are reset and regain the ability to act.

Campaign / Battle Card Driven: The Campaign/Battle Card Driven mechanic is a relatively recent development in wargames that focuses the players’ actions on cards they have in their hand. Performing a single action uses a single card; cards will often be multi-purpose.

Action / Event is a similar but more distinctive mechanic. Games where the cards are used to deploy specific units are considered to be using Command Cards. Games where cards are used to affect the outcome of battles are considered to be using Card Play Conflict Resolution.

Card Play Conflict Resolution: Each player simultaneously or sequentially plays one or more cards. These modify the base outcome of a conflict and allow various special abilities to apply. This can function similarly to Area Majority / Influence, but with a discrete resolution or award of the conflict target, rather than by dynamic/shifting control of a fixed asset. It is also similar to Force Commitment, but that mechanic presupposes a more liquid resource where the quantity can be chosen.

Critical Hits and Failures: Dice are rolled, and those exceeding a target number generate a success. Certain rolls (typically the highest and/or lowest on the die) generate additional success or extreme failure.

Force Commitment: The players select how many of their forces they will commit to the battle to different categories. This can be simultaneous (hidden) or incrementally, prior to resolution. Frequently players must lose all forces that they commit. Arguably this is a form of auction/bidding, but distinctive when applied to war or area control games for multiple/parallel contests.

Dune is an early example of this mechanism.

Ratio / Combat Results Table: In many Board Wargames to resolve a combat between units, the Attacker and Defender total the strength of the units involved in that combat. This is then expressed as a “Ratio” (Attacker versus Defender) which is used to index into a “Combat Results Table (CRT)”. A dice roll then determines the final result of the combat.

Stat Check Resolution: There is a target number required to succeed at some test. A random number is generated (by card draw, die roll, etc.), which is compared to the target. If it meets or exceeds the target, the action succeeds.

All board game mechanics: Auction/Bidding

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.


Auction / Bidding: This mechanic requires you to place a bid, usually monetary, on items in an auction of goods in order to enhance your position in the game. These goods allow players future actions or improve a position. The auction consists of taking turns placing bids on a given item until one winner is established, allowing the winner to take control of the item being bid on. Usually there is a game rule that helps drop the price of the items being bid on if no players are interested in the item at its current price. In most games, once a winner for one item is done, if there are more items to be bid upon, another auction is held for those items. The process repeats until a game condition is met or items are exhausted in the auction phase of the game. This is similar to Worker Placement, but workers can be kicked off spots by bidding higher.

In Power Grid, for example, you start with no power plants and must win bids to be able to produce power. Winning a bid on a given power plant allows that player to add it to their current inventory of power plants and also allows for more power to be made in a given turn. In Vegas Showdown, players bid on rooms. such as a slot machine or a restaurant, in order to build a larger hotel with more prestige and value. Winning players pay for the room based on their bid and place it in their hotel. In both examples, bidding is done in a turn format and players have the option of passing on bids.

Auction Compensation: Losing bidders in an auction receive a lesser award in place of the lot they bid on.

Bids as Wagers: Players bid that they can achieve some outcome in the ensuing gameplay phase. Scoring is based on whether and how well players achieve their bids. Examples would be Spades or Contract Bridge.

Closed Economy Auction: Closed-Economy is a meta-mechanism that can modify any auction type. In a Closed-Economy Auction, all the money spent in the auction is paid out to the auction participants themselves.

For example, in Nightmare Productions, the winning bid is distributed evenly between the non-winning players, and losing bids is the only way to gain more money.

Constrained Bidding: This is a meta-mechanism that can modify other auction techniques. Players may not bid any number that they wish. They may only bid based on increments and/or combinations of certain resources. Examples of this are Ra, which forces players to select one of three bid tiles for their bid, and High Society, where players must increase bids by adding money cards from their hand and are not allowed to make change.

Dutch Priority: A Dutch Priority Auction is a multiple-lot auction in which prices for the lots are determined based on the number of bids placed on the lots up for bid. The winning bidder is the first player, in bid priority, who chooses to pay the current price for a lot, which is equal to the number of bidding tokens there. Priority may be determined by a variety of factors, including global turn order or turn order for each lot based on order of bid placement. Players may typically pass on the purchase when they are the priority bidder by removing their bidding token. This has the effect of reducing the price for the lot by one. The Speicherstadt introduced this mechanism. In that, players place meeples one at a time on different lots to be bid on. After all meeples are placed, each lot is evaluated. The player with the first meeple placed on a lot may purchase it, but must pay a price equal to the total number of meeples. If they cannot or will not purchase it, they take their meeple back, and the next meeple in line may purchase, now at $1 less. This opens up lots of opportunity for counterplay and brinkmanship in a relatively simple system.

English: An auctioneer asks for bids of a certain amount and players indicate their willingness to bid at that amount, usually by holding up a hand or paddle, or by calling out. Players are permitted to adjust the increment of the bid, usually by shouting out their actual bid, though this is done infrequently, and usually either to indicate a smaller increment than the auctioneer requests, or a much larger one. When a certain amount of time with no increases occurs, or it is clear that no one wishes to raise the current bid, the auctioneer declares that the high bidder is the winner.

Fixed Placement: a meta-mechanism that modifies a multiple-lot auction by creating rules about which lots players may bid on, and representing bids visually on a board or cards. It is often combined with constrained-value bids. A Fixed-Placement auction ends when every player passes and/or no player has the right to bid further. The highest bidder for each lot wins the lot. Good examples of this mechanism are in Amun-Re and Vegas Showdown. In these games, there is a track below each lot up for auction. Each player places a marker on the lot they are interested in, at the value they want to pay. If another player wants to bid on that lot they do it by placing their bid marker on a space higher than the current bidder. The outbid player retrieves their bid token, and may place it on the same lot at a higher price, or another lot. When all players have placed their token, the bids are resolved.

Multiple Lots: An auction in which players simultaneously bid on Multiple Lots in parallel, instead of bidding for one lot at a time serially. The actual format of the auction can follow any of the auction mechanisms. For example, in Revolution! players perform a simultaneous Sealed Bid Auction on 12 different actions.

Once Around: The players each have one opportunity to bid, either passing or raising the prior bidder. The order of bids is determined by one of the Turn Order structures. After the last player has their opportunity to bid, the high bidder wins. Although this helps shorten the auction (as increasing game length is a pitfall of including auctions), it strongly favors the last player to bid, as they know what their winning bid needs to be, so the designer needs to take care to balance properly.

Sealed Bid: Players secretly make a bid. All bids are revealed simultaneously, and the high bidder wins. Typically some tie breaker mechanism is required. Common ones include closest to start player or using a secondary currency for a tie-breaking bid. A variation on this is called Sealed Bid with Cancellation. In this case, if two or more players have the same high bid, they are eliminated from contention. The highest non-duplicated bid is the winner. This is best used with Constrained Bidding to make ties more likely, and was first used in What the Heck? (originally called Hol’s Der Geier, so it is sometimes referred to as “the Hol’s Der Geier mechanism”).

Selection Order Bid: Selection Order Bid is a form of multiple-lot auction in which players are not directly bidding on the lots themselves, but the order in which they’ll draft the lots. As the bid increases, players may pass and accept a later place in the order. In some cases, players must pay their entire current bid (an all-pay mechanism), and in others they may recover some of their bid.

An early example of this mechanism is in For Sale.

Turn Order Until Pass: Starting with one player and going in turn order, players may raise the current bid or pass. When all players but one have passed, the player remaining in the auction is the winner. Normally players that pass may not re-enter the auction. However, allowing re-entry is a variation that is not uncommon.

All board game mechanics: Area Control/Influence

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.


Area Majority / Influence: Multiple players may occupy a space and gain benefits based on their proportional presence in the space.

In El Grande, for instance, players earn their score in a region by having the most caballeros in that region.

Enclosure: In Area Enclosure games, players place or move pieces in order to surround areas contiguously with their pieces. The oldest and most famous Area Enclosure game is of course Go, but many newer examples also exist.

Area Enclosure is different than Area Majority / Influence because players actually create the areas on a gridded board during the course of play, whereas in Area Majority/Influence the actual areas are pre-existing and players are merely competing control over them.

King of the Hill: Games with a king of the hill mechanism reward players with points or other advantages for occupying a special position on the board. How long can you hold your ground?

Ownership: Players own entities, and perform actions for those entities, or collect benefits if others use them. Le Havre and Caylus allow players to own action spaces, and gain a benefit when other players use them.

Static Capture: Pieces are captured when another piece occupies or passes over their space.

All board game mechanics: Action Selection/Turn Structure

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.


Action Drafting: Players select from an assortment of Actions in a shared pool. The available Actions are limited in quantity, and once a player has chosen an Action it may not be chosen again.

Action / Event: On their turn, the player plays a card that shows Action Points and an Event. They must choose to either use the Action Points or perform the Event. If they choose to use Action Points, typically the Event may be performed by another player.

Action Points: A player receives a number of Action Points or Operation Points on their turn. They may spend them on a variety of Actions.

Action Queue: Players create Action Queues and perform them in sequence. Queues can either be “Batch” queues, where all actions are executed in sequence, or “Rolling” queues where actions are added to the end of the Queue, and the first action is then executed. Players may each have their own queue of actions, or there may be a shared action queue. Nuclear War is an example of a Rolling queue. Colt Express is an example of a Batch queue. Impulse utilizes a shared rolling queue. Some games utilize a fixed action queue printed to the board, such as in Bus and Dominant Species.

Action Retrieval: Each player has a set of Actions available to them, embodied in cards, tokens, or some other affordance. Once performed, they are spent and may not be performed again until retrieved. Action Retrieval typically is itself an Action, or may take an entire turn.

Action Timer: Players place owned timers on action spaces and pieces and take an action. When the timer runs out, it may be moved to another location to take that action. There are no turns -; players may move their own timers any time after they have expired.

Advantage Token: One player has a token that permits them to do a special Action, or modify an Action. Once used, the token passes to another player.

First used in Storm over Arnhem, this mechanism has been used to great impact in many games since, notably as The China Card in Twilight Struggle.

Auction: Players bid for turn order. A variety of auction mechanisms may be used.

Claim Action: In each round there is a First Player, and turns are taken clockwise from the first player. There is an action that may be taken to claim a place in the turn order (typically, but not always, first) for the next round, with play proceeding clockwise from the First Player. If no one takes the action, turn order remains unchanged.

Command Cards: Players have a hand of cards that allows them to activate and perform actions with a subset of their units.

Follow: One player selects an Action. Other players may then perform that Action, or a modified version of it. This is closely related to Action Drafting (ACT-02) and Role Selection (TRN-10), and is often implemented alongside those systems.

Impulse Movement: A turn is broken up into a series of small Impulses. Depending on their speed, units will be able to move in specific Impulses. An early example of this is contained in Star Fleet Battles.

Interrupts: This is a meta-mechanic for Turn Order. Players may take an action that interrupts the normal turn flow.

Order Counters: Players place “Order Markers” into specific regions (or zone, or hexagon, or square) of the game board, indicating what they want to do in that particular region of the game board. After all markers are placed, they are executed in sequence.

Passed Action Token: Players possess one or more Action Tokens. Those who have an Action Token may take a turn, then they pass the token clockwise, allowing the next player to perform an action. Actions are performed in real time; – there is no pausing and structure within the turn. Typically, to prevent stalling and to keep the game moving, in games with multiple Action Tokens, if both tokens are held by the same player, then they suffer a penalty.

Pass Order: On their turn, players may either take an action or pass. The first player who passes becomes the new first player for the next round. The second player who passes becomes the second player for the next round, and so on. Reversing pass order and turn order is also possible when going later in turn order is more advantageous.

Programmed Movement: Players simultaneously program their movement, and then reveal and execute it. This mechanism tends to promote chaos in a game, and benefits those with good spatial relations. This is a specialized form of the Action Queue mechanism.

Progressive: One player has the First Player token. At the end of the round, the token passes to the player to the left, who becomes the new First Player for that round. During the round, players take turns clockwise around the table. Counterclockwise movement is called “Regressive Turn Order” and can also be included in this category.

Random: Representatives of play pieces or players are randomized, and one is drawn at a time. That player or play piece takes its turn, then a new random draw is made.

Role Order: Players secretly and simultaneously select an action, role, or priority. Then they are revealed, and the actions/roles revealed determine the order in which players act.

Rondel: The available Actions are represented as pie wedges in a circle. Each player has one or more tokens on Rondel’s wedges. On their turn, they may move their token around the Rondel and perform the Action indicated by the wedge where they stop. It is typically more costly to move further around the Rondel.

Simultaneous Action Selection: Players plan their turn secretly and simultaneously. Then, they reveal their plans at the same time.

Stat-Based: The turn order within each Round is set by some statistic relating to the players’ resources or position in the game. A typical case is when turn order is performed in order of current score (as a catch-up mechanism).

Time Track: In this Turn Order mechanism, there is a linear “Time Track” with many spaces. Each player has a marker on the track, which indicates where they are “in time.” Markers farther on the track are further forward in time. The player with the marker lowest on the track (furthest “back in time”) takes the next action. Different actions have different costs in time. The player’s marker is advanced a number of spaces according to the cost of the selected action. Then, the next lowest marker on the track takes an action. It is possible that the same player takes multiple turns in a row. NOTE: If there is a time tracker that does not determine turn order, that does not qualify as using this Time Track turn order mechanism.

Variable Phase Order: Variable Phase Order implies that turns may not be played the same way as before and / or after.

Using Puerto Rico as an example, every turn is different. Depending on who starts selecting the roles and what roles they take, you may have to play the ‘build’ action sooner than you’d wish. In other games, you may be denied from taking certain action.

Most games with limited action and any game without a static game turn order fall under this ‘mechanism’. Use of variable player turn order are not Variable Phase Order games.

Worker Placement: A stylized form of Action Drafting, players place tokens (typically the classic person-shaped “meeple”) to trigger an action from a set of actions available to all players, generally one-at-a-time and in turn order. Some games achieve the same effect in reverse: the turn begins with action spaces filled by markers, which are claimed by players for some cost. Each player usually has a limited number of tokens with which to participate in the process, although these may increase as the game progresses.

There is usually(*) a limit on the number of times a single action may be taken. Once that limit for an action is reached, it typically either becomes more expensive to take again or can no longer be taken for the remainder of the round. As such, not all actions can be taken by all players in a given round, and “action blocking” occurs. If the game is structured in rounds, then all actions are usually refreshed at the start or end of each round so that they become available again.

From a thematic standpoint, the game pieces which players use to draft actions often represent “workers” of a given trade (this category of mechanism, however, is not necessarily limited to or by this thematic representation). In other words, players often thematically “place workers” to show which actions have been drafted by individual players. For example, in Agricola each player starts with two pieces representing family members that can be placed on action spaces to collect resources or take other actions like building fences. When someone places a piece on a given space, that action is no longer available until the next round.

Keydom, which was published in 1998, is widely recognized as the first of the worker placement genre of games. Other early design experiments with the mechanism include Bus (1999) and Way Out West (2000). Well known examples of worker placement include Agricola (2007), Caylus (2005) and Stone Age (2008).

Variable with dice: Workers are represented by dice whose pip values impact play. Kingsburg and Alien Frontiers are examples of this mechanism.

Variable with different worker types: Workers can differ in abilities, or can be upgraded and downgraded, or are valid for placement in different areas and buildings. Games that implement this mechanism include Age of Empires III: The Age of Discovery and The Manhattan Project.

Refactoring my “Fire in the Lake” software

Although I had been refactoring bunches of code present in some methods into other methods, and created a couple additional structs when the original structs were handling concerns beyond what they were originally created for, at this point of the project some structs were accumulating massive amounts of methods. Refactoring them would require identifying the general purposes of the methods involved, classifying them and then isolating them from the original code so that area of the codebase wouldn’t be so brittle. I focused first in the area that handles executing the player or bot commands. As a general overview, each of the four players will push through the mouth of the system some words that will relate to their intentions, what they want to do in this turn. If they push through words like “event”, “operation”, “pass”, the system needs to understand that the player wants to play the active card for the event, or wants to perform an operation, or intends to pass. However, we also have words like “6”, “an loc”, “saigon”, “pacify”, “rally”. The system should reliably handle what kind of operation the player wants to play, in what space or spaces of the board, or stuff like how many troops it wants to deploy. In my initial design I simply passed an array of Strings through the command execution system, and those methods had the responsibility to figure out the intention of the player from whatever subset of words the method received. That was a clear violation of the separation of concerns, given that those methods should simply have to focus on executing an operation, a special activity, or delegating declaring that player as having passed, for example.

Before dealing with that major issue, I needed to take some scissors to the execute commands function. The mess of switches and ifs ended up being distributed into isolated functions that handled executing the events, others that executed each kind of operation, others that executed each kind of special activity, another that handled passing, and the biggest group, one that handled atomic executions such as deploying some units somewhere, manipulating the resources of a faction, setting a space to a level of support, improving the trail that the NVA faction uses, etc. That refactorization into a couple dozen files passed the integration tests without much trouble; thankfully, the three almost end-to-end tests that I wrote and that simulated three entire turns of the game are very resistant to refactorization.

There was another section of the code that handled the entirety of the flow of the game: how to deal with the couple of current cards, how to determine what factions were eligible or ineligible, how to slot those factions so that other parts of the system would know that the choices of those factions were already occupied, etc. It ended up being a tremendous chunk of code. I found three major different concerns for the methods involved: some methods just handled the general game flow: setting the active card, informing whether the turn had ended, moving to the next eligible faction according to the order shown in the active card, taking in the general player choices, being able to answer to whoever asked whether the turn had ended or not, etc. Another concern involved handling all the different possibilities for the factions: whether some faction is eligible, whether all are eligible, whether some faction has passed, determining the eligibility of a faction depending on some previous one’s actions, etc. The final concern was related with slotting the factions and moving them around into “holes” that can only hold either one of them at a time or four (maximum number of players). Whether a player has chosen, for example, to perform an operation without a special activity, is very important in this game system, because that means that the following player can only do a limited operation, while if the first player had chosen to play the card’s event, the second player would have been able to do a full operation plus a special activity.

The most pressing concern regarding the following features I had to implement had to do with the fact that I was passing an array of words from the “mouth” of the system to the lowest levels that handled command execution (in some cases to the very lowest level of executing atomic commands). It reeked of primitive envy; what the system should truly know is whether the player intended to perform one of the main choices (passing, event, operation), what operation if the player went that route (ex. rally, train, sweep), whether the player chose to do the additional action allowed for some of the main operations (such as improving the trail), or if the player chose a special activity, which one. We also have the fact that the player might have written the names of spaces (can be cities, provinces or lines of communication), and the program has to figure out if those locations are related to the event, the operation or the special activity. So I refactored out the entirety of that system and created an interpreter that chews the initial commands and just registers the player intentions. It can be asked “does the player want to activate the event?”, which returns a boolean response, and it can be asked to provide the locations associated with the event, for example. Far, far cleaner than the original, system, and not particularly hard to write. It suffers from a case of “excess of switches/ifs”, but it’s not pressing to figure out how to refactor that out. It reads each word as it comes, and depending on what intentions had been “detected”, it will convert to internal enums stuff like the names of places. If it receives the name of a space, the program determines whether, for example, the name actually refers to a space, and in that case if the player had previously sent the word to perform a operation, and in that case if it also had sent the word to perform a special activity. In that case the following spaces would be sent to a list of spaces associated with the special activity, but they would get associated to the operation or the event in other cases.

Again, thanks to the integration tests, the first time I got the major changes to compile, they immediately passed all the tests, so I knew that the previously codified functionality remained intact. That’s the advantage of test driven design: you can dismantle main areas of the code, improve it substantially, and remain confident that everything keeps working as it should. You wouldn’t dare to risk major changes otherwise.