How to test one rule at a time

Testing one rule means the next build differs from the last in a single place. The note already says where they were, what they tried, what they expected, and what the game did. This guide shows you how to choose the build those four lines are about.

Jeremy Gibson Bond, in a chapter published on InformIT on September 2, 2017, calls the loop iterative design: a small change, a play, a look at how the feel moved, then the next small change. Change several rules between plays and you cannot tell which one did what. A subtle change can show in a play or two. A major change needs more plays, because one odd session, a fluke, can fake a result. His exercise, the card game Bartok, adds one rule at a time. Play that one rule a couple of times. A number counts. Five starting cards instead of seven changes the experience, and so does a second discard pile. Do not stack a second new rule on the first try.

What changed since the last build

What changed since the last build?

The differenceTwo thingsOne ruleNothing you can point at

You cannot tell which change did it. Put one back, and test the other on its own.

Write the prediction first

A guide to the Game Design merit badge asks you to change at least one rule, mechanic, or objective, and to say why. Tie it to a problem you saw. An unclear rule, a hole, a dead end, and an exploit are the spots they name. Ask what caused it before you patch. Their notebook is the build, who played, what you hoped, what you saw, what you revised, and whether it did what you expected. The badge wants that cycle at least two more times, because one fix can create a new problem. Their examples include scoring when one strategy dominates, turn order when the wait is long, and an objective players cannot parse. Their tip matches Bond: one major thing per round. By a later pass, the same phase may stall, or a rule you thought was central may barely matter. They also compare the session with the feeling you claimed. If you said it would be fast, was it? The playtest page already wants that sentence written before they sit down.

With the rule, and without it

Eduardo Amengual Risso, at EDAM Games, writes the decision a doubtful rule is supposed to change, then compares a build with it and a build without it. Everything else stays put. In his prototype Dwarves Life, traps were meant to make a low-health player hesitate at a chest. The trap cards shared a deck with other rewards, so the exception showed up more often than the chest, and players opened chests anyway. He removed the traps and the rest still worked. Removal is not his universal answer. If the rule does change the choice, try a clearer presentation before another exception. Watch the bookkeeping. A dislike is not yet a reason to delete it.

Vladislav Tsaran, writing on May 13, 2026, calls it one variable per session. Two small edits are still two variables. His “too fast” complaint was tested as more time, then more mechanics, then a reorder of mechanics already there. The reorder was the cause. The added mechanics were not. Write which rule this build is for before anyone arrives.

Bobby Lockhart, in “Lean Games” on February 8, 2012, says he is not sure of the best way to check rules one at a time. His smallest set is the rules that make the player go through the fun part of the toy. Angry Birds, in his account, makes knocking the blocks down the goal, and stops you toppling them by hand.

End on the note you already know how to write. One build. One difference. What they tried, and what the game did. Then “change” or “no change, because.” The next test is the next single difference, not a second guess folded into this one.

Related: Game development, How to make a game in Unity, Unity vs Unreal Engine, Tingbase, Mini Games Arena, projects.

Common questions

What should I fix first if two things are broken in my game?

Fix the one that stops the core loop from working. Write the other one down and leave it for now, because if you change both at once you won't know which fix actually helped.

How many playtests do I need for one change?

A small change often shows its effect in one or two plays. Bigger changes, or results that surprise you, need more sessions so one unusual game doesn't drive your decision.

How do I know if a game rule is worth keeping?

Write down which player decision the rule is supposed to change, then watch. If players don't make different choices with it, test the game without the rule and see if anything is lost.

Should I explain a new rule before a playtest?

No, let players try it first. Where they get confused is your most useful feedback. If you explain it up front, you're testing your explanation instead of the rule.