Designing Your Game

Req 6bc — Test, Change, Repeat

6.

Do the following: Note: You must have your counselor’s approval of your concept before you begin creating the prototype.

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

6b.

Test your prototype with as many other people as you need to meet the player format. Compare the play experience to your descriptions from requirement 5(b). Correct unclear rules, holes in the rules, dead ends, and obvious rule exploits. Change at least one rule, mechanic, or objective from your first version of the game, and describe why you are making the change. Play the game again. Record in your game design notebook whether or not your change had the expected effect.

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

6c.

Repeat 6(b) at least two more times and record the results in your game design notebook.

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.

Circular diagram showing the repeated game design loop of prototype, playtest, observe problems, revise, and retest.

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.

Making Your First Game: Minimum Viable Product - Scope Small, Start Right - Extra Credits

Next, you will prepare something your players can follow without your help: a real instruction sheet.