Mechanism Design and the Game Behind the Game

A few years ago, I had a colleague who made his own board and card game. We would play it during breaks or after hours. Every few days, he would return with a new rule, a slightly adjusted attack value, or a different defence power for one of the characters.

He was watching how the game behaved in practice. Some matches ended too quickly. Others settled into a slow exchange where neither player could create an advantage. A strong card might be exciting in one matchup and oppressive in another. His updates were attempts to keep the game enjoyable while avoiding both a short coin toss and an endless match.

That made me wonder whether the same work could be done before playing every variation by hand. Could the rules be represented mathematically, matches run virtually, and the results used to choose better values? More generally, what is the science of choosing rules so that rational players produce the kind of behaviour a designer wants?

That question led me down the rabbit hole that is Game Theory, and then to what is often called reverse game theory: mechanism design.

It is a field of mathematics, economics, and strategic decision-making, with natural extensions into political economy. The common question is deceptively simple: how do you shape a system when the people inside it are making their own choices?

Game theory starts with the rules

Game theory usually takes a game as given and asks what the players will do. The rules, available actions, information, and payoffs are inputs. The analysis might ask whether a strategy is dominant, whether an equilibrium exists, or how a player should respond to an opponent.

Mechanism design turns the direction around. The designer starts with a desired outcome and asks which rules and incentives could make that outcome emerge when people pursue their own goals.

A compact version is:

game theory:         rules -> strategic behaviour -> outcome
mechanism design:    desired outcome -> rules and incentives -> behaviour

“Reverse game theory” is a useful intuition, though mechanism design is more precise than simply reversing an arrow. It is concerned with the information available to the designer, the private information held by participants, the incentives created by the rules, and the outcomes that result when participants act strategically.

The designer does not get to choose the outcome directly. The designer chooses the environment in which other people make choices.

The homemade game is already a mechanism

My colleague was adjusting more than numbers. He was changing the mechanism that produced the matches.

Suppose a character can attack for 8 damage, defend for 5, and spend one action per turn. Those values are part of the mechanism, but they are not the whole thing. The wider mechanism includes:

• which characters can target one another
• how turns are ordered
• what information players can see
• how resources are gained and spent
• whether a defeated character can return
• how victory is defined
• what happens when players choose not to attack

Together, these rules shape the incentives. If defence is cheap and there is no reason to leave a safe position, players may discover that waiting is the best strategy. If one attack is effective against every character, the rest of the card pool becomes decoration. If the first player can gain an advantage that compounds without limit, a match may be decided before the losing player has meaningful choices left.

A designer who wants “interesting, winnable matches with several viable strategies” is describing an objective for a mechanism. The rules are the proposed implementation.

That objective is also less precise than it first appears. “Balanced” might mean equal win rates across characters. It might mean that every character has a useful counter. It might mean that the outcome is uncertain until late in the match, or that players feel responsible for the result rather than lucky or trapped. Each describes a different property of the experience.

What a simulated match would contain

A virtual balancing tool would need a model of the game state and a way to choose actions. At the smallest useful level, a state might look like this:

state:
  turn number
  active player
  health and status of each character
  resources and cooldowns
  cards or actions available
  information visible to each player
  history needed by the rules

The simulator applies legal actions, resolves their effects, and advances the state until someone wins, loses, or a maximum turn limit is reached.

def play_match(game, player_a, player_b, rng):
    state = game.initial_state(rng)

    while not game.is_terminal(state):
        player = player_a if state.active_player == "A" else player_b
        action = player.choose_action(state, rng)
        state = game.apply(state, action)

    return game.result(state)

The loop is simple. The difficult part is deciding what the players do and what counts as a good result.

A random player can reveal obvious rules problems, such as an attack that is accidentally illegal or a resource that can grow without bound. Random play is a poor model of competitive behaviour, though. If the goal is balance among capable players, the simulator needs policies that make plausible decisions: a heuristic player, a search-based player, or a learned policy. Different policies may expose different weaknesses.

The evaluation also needs more than a single win rate. A parameter sweep might record:

• win rate by starting player and character pairing
• average and percentile match length
• frequency of draws or turn-limit endings
• how often each action or card is used
• whether one opening line dominates
• how often a player can recover after falling behind
• how sensitive the result is to small changes in the parameters

A change that moves every character to a 50 percent win rate may still produce repetitive matches. A change that gives the first player a 55 percent advantage may be healthier if the game contains meaningful counterplay and several routes to victory. The numbers are evidence about the mechanism, not a definition of fun.

How mechanism design applies to game balancing

The game designer chooses the mechanism. For a first model, the players are rational actors trying to maximise their chance of winning. The balancing question is whether pursuing that goal produces the kind of match the designer wants.

Incentive compatibility gives this a more precise foundation: following the intended strategy must be in a participant's own interest, given their information and the assumed behaviour of others. In a direct revelation mechanism, that usually means reporting private information truthfully. Encouraging varied armies is a broader incentive-design problem, not by itself a proof of incentive compatibility. The Nobel committee's account of mechanism design explains this distinction between a desired outcome and the strategic conditions needed to implement it.

Make the desired behaviour worth choosing

Suppose the goal is to make players fight over central territory instead of turtling in their starting bases. High-yield resource nodes in the centre can make leaving safety worthwhile. Alternatively, defensive upkeep could increase with each round, making indefinite waiting progressively less attractive. Players seeking to win then have a reason to engage without a rule explicitly ordering them to attack.

The size of the incentive matters. If the central resource is worth too little, everyone stays home. If it is worth too much, the opening becomes a race for one square and the rest of the map is irrelevant. The reward must justify exposure without making the first successful capture decide the match.

Give strong choices a cost or a counter

A dominant strategy is a best choice regardless of what opponents do. A strictly dominant strategy is always better than the alternatives. If one faction or build provides that kind of advantage, competitive players have little reason to choose anything else. A popular or powerful build is not necessarily dominant in this technical sense, but it can still make play repetitive if its counters are impractical.

Three familiar tools change that calculation:

• Asymmetric counters: Unit A beats B, B beats C, and C beats A. This rock-paper-scissors structure makes the opponent's choice matter. Costs, positioning, and access to the counter still determine whether it works in practice.
• Diminishing returns: Suppose equally priced farm upgrades add 10, then 8, then 5 gold per round. The next farm becomes less attractive relative to another investment. This encourages diversification only if the alternatives offer competitive returns.
• Action economies and opportunity costs: With three action points per turn, an attack costing all three sacrifices movement and defence. Its damage may be high, but using it leaves an opening that another player can exploit.

A Nash equilibrium is a set of strategies where no player can improve their expected payoff by changing strategy alone. In ordinary rock-paper-scissors, independently choosing each option with equal probability is such an equilibrium. That gives the designer a useful question: after players adapt to each other, does the game still support varied choices? An equilibrium can also be dull or one-sided. Its existence does not certify good balance. Nor does mechanism design always seek to remove dominant strategies: making truthful reporting dominant can be exactly the goal of an economic mechanism.

Keep an early lead from deciding everything

Catch-up mechanics, sometimes called rubber-banding, aim to preserve meaningful choices for a trailing player. A hypothetical drafting game might let the last-place player choose a new unit first each round. The advantage comes from earlier access to a contested option, while the leader keeps the resources already earned.

Power Grid's rules use a related mechanism: player order depends on connected cities, with power-plant size breaking ties, while resource buying and network building run in reverse order. Players with smaller networks therefore get earlier access in those phases. Catan (a game I introduced to my colleagues and likewise spent endless break hours and after hours playing) also reverses the initial placement order for the second settlement. That compensates for setup order. It is not a recurring benefit for whoever is losing.

Another option is to make further progress more expensive as an empire grows. Each additional territory could increase upkeep or technology costs, slowing the conversion of an early territorial lead into an overwhelming economic advantage. This is a brake on snowballing rather than a direct reward for being behind.

Both approaches need restraint. A generous last-place bonus can make deliberately falling behind profitable, while excessive upkeep can make expansion pointless. The aim is to keep recovery possible without making earlier decisions irrelevant. Extra Credits' episode on catch-up mechanics explores that design problem.

Search for the tradeoff

The Extra Credits “Perfect Imbalance” video perfectly illustrates the mechanism-design connection. Its explanation of cyclical counters and asymmetric strengths shows how balance can come from giving each choice a situation where it is strong and another where it needs help, rather than making every choice identical.

For a turn-based game, we can make that idea more explicit with an optimisation solver. The game can be modelled as a combinatorial decision space: positions, resources, actions, upgrades, and responses produce a large set of possible lines. A simulator can score candidate rule parameters against objectives such as counterplay, recovery chances, match length, and strategic variety, then search for a region of “perfect imbalance” where the game is neither trivially easy nor punishingly hard. This kind of balance search once tended to require a large game studio's resources, subject-matter experts and bespoke tooling, but agentic coding makes a useful first version of the simulator, solver, and analysis loop much more accessible to indie developers, even though the designer still has to decide what “enjoyable” means.

These rules do not force a player to behave in one way. They alter the payoff landscape so that the desired choices become reasonable.

The same idea appears in public policy

Take a simple version of the budget thought experiment. Suppose government spending is about 25 percent of GDP and private activity accounts for the other 75 percent. A planner is given a preferred allocation for next year's growth and wants private investment to move closer to that mix. The government controls its own budget, but private firms and households control many of the remaining decisions. It cannot simply issue a complete instruction for every unit of private capital and expect the plan to execute.

The target is to create conditions in which firms pursuing their own objectives produce more of the desired aggregate behaviour.

That is recognisably a mechanism-design problem, but “find the best sector allocation for maximum GDP growth” hides most of the difficulty.

Suppose a government wants more private investment in research. It can fund research directly, but firms still choose how to spend their own money. A tax credit is one way to change that calculation: it raises the after-tax return on qualifying work, giving firms a reason to do more of it.

The design problem is deciding what qualifies. Imagine a credit intended to support new research. A firm might start a project that was previously too expensive, claim the credit for work it already planned, or relabel an existing expense to qualify. All three responses could increase reported qualifying spending, but they would not represent the same increase in research activity.

This is where the mechanism-design framing helps. The government wants an outcome and can choose policies that change the relative payoffs of different actions, firms hold information about their costs and plans, and the eligibility rules shape what they find profitable to do. The question becomes: which rules reward the activity we want, and which merely reward appearing to do it?

The objective needs care too. More research spending is an input, not a guarantee of useful results. Even if the broader target is GDP growth, the design still has to account for public cost, displaced investment, and benefits that may take years to appear.

There is also a modelling trap. A relationship estimated under one policy regime may change when people adjust their decisions to a new rule. This is the warning in Lucas's critique of policy evaluation: evaluating a policy requires modelling how behaviour responds, rather than assuming historical response coefficients stay fixed.

In game design, the smaller version is simply that players adapt to the patch. A balance change needs testing against the strategies it encourages, not only the strategies players used before it.

Where game design differs from economics

The shared tools are strategic models, incentive constraints, and equilibrium analysis. Game designers can often work within a much more controlled environment, though the analogy has limits.

Information control. In a digital turn-based game, the engine can track every encoded state variable: resources, positions, hidden cards, cooldowns, and legal actions. The designer also chooses which information players receive. That does not reveal a player's intentions or preferences, and complete engine state does not mean complete information for each player. Still, it is a substantial advantage over a policymaker trying to infer private costs, capabilities, and unreported activity.

Rule enforcement. Within a correctly implemented engine, a player cannot spend an action point they do not have or decline an upkeep charge. An economic model cannot make tax evasion or an informal market impossible just by leaving it out of the permitted actions. Games have a tighter boundary, but enforcement is not literally absolute: software can have exploits, players can collude outside it, and a board game's rulebook needs people to enforce it. The practical advantage is control over the legal state transitions.

The fun constraint. Economic mechanisms may target efficiency, welfare, revenue, or investment. The public-policy example above adds GDP growth to that list. A game designer also has to care about engagement, tension, agency, and enjoyment. A perfectly symmetric game with equal win rates can still fail if every turn takes ten minutes of tedious calculation. A catch-up rule can preserve uncertainty while making players feel that their earlier choices did not matter. Enjoyment is not exclusive to games as a human concern, but here it is a direct design criterion that a win-rate table cannot capture.

Simulation can test a mechanism, not certify it

This is the same reason I keep coming back to simulation-first thinking: a model is most useful when it exposes assumptions and lets us disturb a system cheaply, not when it pretends to certify the future.

A virtual tournament would be useful for my colleague's game. It could find combinations that deserve attention and eliminate obviously weak ones before another evening of manual testing. It could reveal that a defence bonus only looks fair against one character, or that a catch-up rule turns every late game into the same script.

The simulator would still be a model. If its player policies are weak, it may miss a dominant strategy. If it omits hidden information, bluffing, or social negotiation, it may prefer rules that look good for purely tactical play. If it optimises only average match length, it may produce a game with a pleasant mean and a miserable tail.

A sensible workflow would be iterative:

1. Define the player experience and the failure modes that matter.
2. Represent the legal state transitions and resource flows.
3. Implement several plausible player policies, not one idealised opponent.
4. Run many matches across starting positions, matchups, and random seeds.
5. Search parameter variations and record the tradeoffs rather than only the winner.
6. Play selected candidates manually and update the model when human behaviour exposes a missing mechanism.

The last step matters. Simulation is good at exploring a defined system. It is less good at telling us whether the defined system captures the thing people actually care about.

The useful connection

The connection between a homemade card game and economic policy is that both involve a designer trying to shape decentralised decisions without directly choosing every decision. One optimisation algorithm cannot solve either problem by itself.

Game theory helps analyse what strategic players do under a set of rules. Mechanism design asks how the rules might be chosen so that self-interested behaviour moves toward a desired outcome. Simulation provides a way to explore the consequences before relying on the mechanism in the world.

For a board game, the desired outcome may be a tense match with several viable plans and no automatic opening. For public policy, it may be more investment in productive capacity under constraints that include fairness, resilience, administrative cost, and unintended effects. In both cases, the hard part is stating the objective clearly enough, modelling the incentives honestly, and checking which behaviours the rules make attractive.

My colleague was doing a small, practical version of this every few days: observe the outcomes, infer where the incentives were wrong, change the mechanism, and test again. A simulator would have made that loop faster. Mechanism design gave me a name for the deeper question underneath it: if I want a particular pattern of behaviour, what rules would make that pattern a sensible choice for the people playing the game?