Small rules, surprising games

The trouble with one generous rule

Night Mail’s designer wants successful deliveries to feel rewarding. Every delivered letter earns a coin. Coins buy larger bags. Larger bags carry more letters. More letters earn more coins. It sounds pleasantly sensible.

During a two-player race, one courier makes an early delivery first. They buy a larger bag, complete the next round with more letters, and buy another upgrade before the other player can catch up. Soon the player who is ahead gets stronger simply because they are ahead. The second player is still pressing buttons, but the race feels settled.

No single rule says “make the loser miserable.” The result comes from the rules interacting over time. That is the central challenge of systems design: the game you write as a list is not always the game that appears when people play it.

Before adding another feature, draw the connections. Deliveries produce coins. Coins increase capacity. Capacity increases deliveries. The line comes back to where it started. You have found a feedback loop. Now you can ask whether that loop supports the experience you intended.

Read a game in three directions

The MDA framework, introduced by Robin Hunicke, Marc LeBlanc, and Robert Zubek, distinguishes mechanics, dynamics, and aesthetics. In plain language: the rules you build, the behavior that develops during play, and the experience the player has. Here “aesthetics” includes felt experience, not only visual style.

For our courier race, buying capacity is a mechanic. A leading player completing increasingly large deliveries is a dynamic. Feeling powerful, or feeling that catching up is hopeless, is part of the experience. The framework helps you keep these levels connected instead of assuming that a feature produces a feeling directly.

You can work forward: “If I add this rule, what might players do, and how might that feel?” You can also work backward: “I want a close, readable contest. What behavior would support it, and which rules might produce that behavior?” Neither direction eliminates testing. Both make your guesses easier to inspect.

Try this with a feature from your own idea. “A day-night cycle” is only a rule or presentation system until you explain its effects. Perhaps shops close at dusk, so players plan a route through the village. Perhaps nothing changes except the sky, so the effect is mostly mood. Both can be valuable. They require different implementation work and different tests.

Watch an early lead grow or shrink

The experiment below starts two couriers with different resources. Each round they receive a base income. You can add a bonus based on current wealth, or a catch-up bonus for the courier behind. Run the same number of rounds in each mode and compare the gap.

This is intentionally a toy model. There are no human decisions, missed deliveries, or secret skills. It isolates the effect of one rule so you can understand it. It cannot tell you whether a real player would enjoy the result.

Reinforcing feedback makes a difference grow

A reinforcing loop feeds an advantage back into the thing that creates the advantage. More territory produces more income; more income buys more units; more units capture more territory. A small difference can become a large difference through repeated turns.

“Positive feedback” is another name for this kind of loop. Positive does not mean pleasant or well designed. It refers to the direction of the effect. A negative experience can come from positive feedback, which is a reliable way to make a design meeting confusing. Use “reinforcing” when you want to keep the meaning clear.

Reinforcing loops can be useful. A single-player game may use them to create a satisfying sense of growth. A short competitive round may use them to help a deserved lead resolve into an ending rather than dragging on. A survival game may deliberately make a mistake cascade into a tense recovery problem.

The questions are about scale and timing. How quickly does the advantage grow? Can the player recognize why it is growing? Is there a possible response? How much play remains after the outcome becomes obvious? A snowball that ends a five-minute round can be exciting. The same snowball followed by forty minutes of mandatory cleanup can be tedious.

In Night Mail, bag upgrades might fit a solo delivery campaign but damage a short head-to-head race. The rule did not become intrinsically bad. The surrounding goal and timescale changed. This is why copying a successful mechanic from another game is not the same as copying its effect.

Balancing feedback pushes back against a difference

A balancing loop reduces a deviation. A courier with a heavy bag moves more slowly. Owning more territory raises its upkeep cost. A player behind in a race receives a shorter optional route. The advantage still exists, but part of the system pushes against it.

“Negative feedback” is the traditional term. Again, it does not mean punishment or a bad feeling. A balancing rule may help a game stay interesting by preventing one variable from running away. It can also frustrate players if it makes every improvement feel canceled.

Suppose every extra coin in Night Mail immediately raises all prices by the same amount. The player may feel as if earning money changes nothing. The economy is stable, but it has lost the sense of progress the designer wanted. Stability alone is not a design goal.

A catch-up mechanic also needs to respect the skill being tested. If a careful route plan earns a lead and the game secretly erases it, the player may stop trusting the contest. A visible risky shortcut for the trailing courier can preserve a chance to recover while still asking for a decision or execution.

Try changing the strength of the catch-up rule in the experiment. At low strength, the gap closes slowly. At high strength, positions can swing or overshoot depending on the rule. That is a clue to investigate, not an automatic verdict. Some games want dramatic reversals; others want steady progress.

Follow what enters, stays, and leaves

You can understand many game economies with three questions. What is stored? What adds to it? What removes it? Oil is a stored resource. Refilling at a post adds oil. Lighting a crossing removes oil. The total at a moment is the result of these flows over time.

Now inspect the timing. If every post refills oil to full, conserving it only matters between posts. If oil carries across the entire evening, an early route choice affects later deliveries. If the player can wait safely at a post for unlimited refill, a timed mission and an untimed mission will behave very differently.

Look for sources without meaningful limits and sinks without meaningful benefits. Unlimited safe coin farming can make a difficult delivery optional in a way you did not intend. An expensive repair that only returns the player to the previous state can feel like maintenance rather than progress. Either may be deliberate, but neither should hide in the design by accident.

Keep units explicit. “One oil per second” and “one oil per crossing” create different incentives. The first encourages fast movement and may penalize players who pause to read. The second lets them think without spending the resource. A tiny wording change can have a large accessibility and pacing effect.

Make a table for your game’s main resource. Include its starting amount, every source, every sink, its maximum, and when it resets. Then play five imagined turns with actual numbers. The purpose is not to find perfect balance. It is to discover whether the resource can do the job you assigned it.

Play it: combine rules and follow the consequences

Begin with an empty box and launch the ball. Keep its trace, add two bumpers, and launch with the same angle and power. You changed the environment rather than the input. Watch the first collision, then follow the consequences through the rest of the flight.

The ball uses the same reflection rule for either bumper. Their arrangement creates a path that would be awkward to describe as a list of special instructions. This is a small, inspectable example of behavior produced by interacting rules.

• Keep the launch fixed and compare bumpers off versus on. Use the dashed saved trace to see where the paths separate.
• Change only bounce retention. Does a livelier collision help the ball reach the tray, or send it past the useful route?
• Find one setting where a bumper helps. Then explain the sequence in plain language: hit this surface, travel here, fall into the tray. A surprising result is more useful when you can inspect its cause.

Let familiar rules meet in unfamiliar ways

Emergence is behavior that comes from interactions among rules rather than from a separate instruction for every situation. In Night Mail, rain raises water, water moves floating crates, and crates can block a narrow channel. A player who notices the relationship might redirect a crate to protect a crossing. You did not need a special “protect this crossing” button.

This kind of discovery can be satisfying because the player feels that their understanding of the world is useful. It depends on consistency. If a crate blocks water only in the one place where the designer expected it, players may learn that experimentation is unreliable.

Consistency does not mean simulating everything. You can choose a small set of objects and interactions, then communicate the boundaries. Perhaps only marked floating crates can be moved. Perhaps decorative fences never block water. The player needs a way to tell those classes apart. Otherwise a limitation looks like an arbitrary exception.

Emergence also creates testing work. Can a crate block the only exit? Can it trap the courier? Can two moved objects make a delivery impossible? You need a policy for recovery: undo, reset, alternative routes, or a clear failure state. A surprising possibility is only charming until it consumes someone’s evening.

An economical prototype uses a few rules with useful relationships. One movable object, one current, and one goal can expose interesting behavior. Ten unrelated objects may offer more content while giving the player less to reason about. Count connections as well as features.

Players follow what the game rewards

Suppose your story celebrates careful delivery, but the scoring system rewards distance traveled. A player may run in circles because that is what increases the score. They are not necessarily playing incorrectly. They are responding to the objective your rules made visible.

A score is a statement about value. So is a progress bar, an achievement, a daily task, or a resource reward. Compare those statements with the experience you intended. If you want players to explore, rewarding only fast completion creates tension between your message and your incentives. You can make that tension intentional, but you need to notice it.

Watch for rewards attached to an easy proxy. Counting button presses is easier than recognizing thoughtful decisions, but rewarding presses may encourage repetition. Counting time in a session is easier than understanding satisfaction, but longer sessions can result from confusion as well as enjoyment. Measure the behavior you actually care about whenever you can.

For Night Mail, a route-efficiency medal could encourage planning. A hidden bonus for taking the scenic route could encourage exploration. Offering both as separate optional goals gives different players something to pursue. Combining them into one opaque score may make both harder to understand.

The player is allowed to surprise your diagram

A rules diagram can explain how oil enters and leaves Night Mail. It cannot establish what every player will care about. One player hoards oil for safety. Another spends it to light every abandoned lamp. Two friends decide that their courier never uses bridges. The same rules now support different activities.

Miguel Sicart’s Against Procedurality challenges accounts that locate a game’s meaning too exclusively in its procedures. His argument gives us a useful counterweight to systems diagrams: attend to the creative and interpretive work of players.

Imagine that a player spends ten minutes arranging parcels into a picture instead of delivering them. Before fixing this “failure,” ask what happened. Did they misunderstand the goal? Did the parcels accidentally block the exit? Or did they discover a form of play they value? Those cases call for different responses.

An original testing exercise: give two people the same five-room paper map. Tell one that the aim is to deliver quickly. Tell the other that the aim is to find a route they would enjoy walking. Keep movement and oil costs identical. Ask each to explain a route. You have changed the framing, so this is not a clean test of the map alone. It is a way to notice how a player’s purpose changes the significance of a rule.

Now put the written goal aside and let a player invent one. Observe which parts of the map become useful. This can reveal expressive possibilities you did not budget for. It does not mean every unexpected behavior deserves a feature. Decide whether supporting it fits your project and whether it harms anyone else’s play.

In a shared game, one person’s experiment can become another person’s obstruction. Parcel stacking may be delightful until it blocks a teammate’s only exit. A reset, an alternate route, or separate building spaces can preserve experimentation while preventing a single player from taking over the session.

Write down what your model leaves out

The courier simulation above updates both players at the same time. It does not include skill, luck, negotiation, route choice, or a player leaving the session. Its numbers can demonstrate a feedback relationship. They cannot establish that a comeback feels earned.

This distinction is practical. If a catch-up rule makes the totals equal, ask how it becomes visible in the game. Is the trailing courier given a shorter route, cheaper fuel, or unexplained points? The same final balance can feel like an opportunity, a gift, or an insult. Presentation and player action are part of the design.

Make a boundary note beside your next spreadsheet: “This model includes these quantities and leaves out these behaviors.” Then choose one omitted behavior that might reverse your conclusion. For example, the leading player may slow down on purpose to receive a trailing-player bonus. Run that strategy by hand.

A model becomes more useful when you know where it stops. You can use arithmetic to catch an exploit, a paper game to see how people reason, and a playable scene to test timing. You do not need one enormous simulation to answer every question.

Run a five-round paper simulation

Keep the first version. A before-and-after table lets you explain the effect of your change. It also protects you from remembering that the old economy was worse in every possible way. Usually it had a benefit you may want to preserve.

Do not balance a whole game in this exercise. You are learning to expose a relationship. Once you understand it, put that relationship into a playable situation and see whether people use it as expected. A simulation can reveal a mathematical problem. It cannot supply the missing player.

1. Choose one resource and one repeating activity from your game.
2. Write the starting amounts and exact rules for gain, spending, and reset.
3. Create two starting situations, one slightly ahead of the other.
4. Play five rounds with the same basic strategy. Record the resource totals after every round.
5. Draw the relationship between the resource and future performance. Does success make later success easier?
6. Change one rule, predict the result, and run the same five rounds again.
7. Write what the simulation leaves out, especially player decisions, skill, and information.

A worked revision: keep growth, shorten the snowball

We want the courier race to reward good deliveries without making an early lead permanent. One revision lets coins buy temporary route tools rather than permanent bag capacity. A tool can help with one crossing, then it is spent. The leader gains options, but the advantage does not automatically multiply every round.

This revision creates a new question: will the leading player hoard tools and still run away later? We can cap the carried tools, make unused tools expire at the end of a short race, or accept hoarding as a strategy. Each option changes a different part of the experience. We should test the one that best supports our promise of a close, readable contest.

We could also keep permanent capacity in the solo campaign, where growth is the point. Sharing code does not require sharing every balancing rule. The important design skill is tracing consequences and choosing them deliberately.

You now have a way to inspect a game as a connected system. Next, we will look at how a new player learns that system. A rule can be beautifully designed and still fail if the game asks the player to use it before they can recognize it.

Sources & further reading

Sources for the ideas discussed here, plus further reading. The lesson’s examples and interactive exercises are original.

• Hunicke, LeBlanc & Zubek: MDA, a formal approach to game design and game research