Req 6bc — Test, Change, Repeat
This requirement covers two connected steps in the same testing cycle:
- Req 6b — test your prototype, fix unclear rules and exploits, and make at least one important change
- Req 6c — repeat that process at least two more times and record the results
If Req 6a was about building, this page is about improving. This is where game design becomes iteration — the repeated cycle of testing, learning, changing, and testing again.
Req 6b — First Real Playtest
The first playtest almost always reveals problems. That is good news. It means the players are teaching you about your design.
Compare what happens in play to what you promised in Req 5b. If you said the game would feel fast and exciting, did it? If you said it would create teamwork, did players actually talk and coordinate? If not, that gap matters.
What Problems to Look For
The requirement names four big trouble spots:
- unclear rules — players do not know what they are allowed to do
- holes in the rules — situations happen that the rules do not cover
- dead ends — the game stalls or players run out of meaningful choices
- rule exploits — a player finds a strategy that breaks fairness or fun
When you spot one of these, do not just patch it quickly. Ask what caused it.
Make a Meaningful Change
You must change at least one rule, mechanic, or objective and explain why. A strong change is tied to an observed problem.
For example:
- change the scoring because one strategy dominates
- change turn order because downtime is too long
- change an objective because players are confused about how to win
- change a resource limit because the early game feels too punishing
Record each test round
This makes your notebook useful instead of vague
- Version tested: What build or ruleset was used?
- Players: Who played, and how many?
- Expectation: What were you hoping this version would do?
- Problems observed: Confusion, imbalance, boredom, loopholes, dead ends?
- Change made: What did you revise and why?
- Result: Did the change have the effect you expected?
Req 6c — Repeat at Least Two More Times
One fix is not enough. Games improve through repeated testing. When you repeat the cycle, you learn whether your first solution created a new problem, solved the old problem, or revealed a deeper issue underneath.

By the third or fourth test, patterns start to appear. Maybe players always get stuck in the same phase. Maybe everyone loves one part of the game and rushes through the rest. Maybe a rule you thought was central turns out not to matter much at all.
Compare Expected Effect vs. Actual Effect
This is the heart of the requirement. Every change is a prediction. Did it do what you thought it would do?
You might say:
- “I shortened the round timer to increase urgency, and it worked, but it also made younger players feel rushed.”
- “I added a shared team goal to improve cooperation, but one strong player still controlled most decisions.”
- “I simplified the setup, and that change helped immediately.”
That kind of answer shows real design thinking.
In Req 4d, you analyzed how rule changes affected an existing game. Now you are doing the same work on your own design. That connection is the whole point of the badge.
Next, you will prepare something your players can follow without your help: a real instruction sheet.