A game idea may start with a grand sentence: a beautiful world, many challenges, and different characters. Its first prototype does not need all that. It needs an action the player can choose, a rule determining the outcome, and a clear way to know when an attempt ends. Before buying assets or building a large map, ask whether another person could follow the idea from a rules sheet without you explaining every move.
This guide creates a small original paper exercise for checking rule clarity, then explains how to record observations and choose the next step. It is neither a finished commercial game nor an actual user study, and it promises no enjoyment or success. The generated image shows symbolic paper pieces, not an exact exercise board. Follow the text for positions and quantities.
Reduce the idea to a testable question
Instead of “Is my game wonderful?”, ask “Does the player understand that collecting happens when landing on an item, not passing over it?” The first invites broad compliments; the second identifies something observable. Your question might concern step order, a clear ending, or a reason for choosing a move. Do not try to establish every aspect of the project in one session.
The Unity Learn unit frames playtesting as structured collection of design information.
Use that as a question framework, not certification of your prototype. Leave the long story, shop, online competition, and finished artwork outside the first version. They are not bad features; they do not answer this question about understanding a small rule. Keep them on a later list rather than consuming this session.
Write complete rules before polishing their appearance
Call the exercise “Collect Two Markers.” It needs one player, a path numbered 0 through 6, a large piece showing the player's position, markers at positions 2 and 4, and four boxes for used turns. Draw the materials on paper instead of buying equipment. Give markers distinct shapes or symbols as well as colour, rather than relying on two colours alone.
The player starts at 0 with no markers and zero turns used. Each turn, choose to advance one or two positions. There is no backward movement and no movement beyond 6. An illegal choice is not executed and consumes no turn; select a legal move instead. Landing on a marker collects it once. Passing over it does not collect it.
After each legal move, increase used turns by one and collect a marker at the arrival position if present. Check victory first: being at 6 with both markers means success. If success has not occurred and the fourth turn has been used, the attempt ends unsuccessfully. Reaching 6 earlier without both markers also ends unsuccessfully because forward movement is no longer possible. Do not grant a fifth turn to avoid an unwanted outcome.
Translate the words into a traceable state
Three things describe this model's state: current position, collected markers, and turns used. Do not replace values with “made good progress.” When the state changes, a reader should identify the rule responsible. Keep collected markers in a separate space or cross them out on the sheet; do not let them reappear without a rule.
Before each new attempt, restore position 0, both markers in their original places, and a zero counter. Returning only the player piece while leaving markers collected accidentally tests a different version. Write the version name and date on the sheet so original and revised rules do not become mixed during comparison.
Trace a successful route yourself first
| Stage | Position | Collected markers | Turns used | Outcome |
|---|---|---|---|---|
| Start | 0 | None | 0 | Attempt underway |
| Advance 1 | 1 | None | 1 | Underway |
| Advance 1 | 2 | Marker 2 | 2 | Underway |
| Advance 2 | 4 | Markers 2 and 4 | 3 | Underway |
| Advance 2 | 6 | Markers 2 and 4 | 4 | Success before checking the turn limit |
The route 0, 1, 2, 4, 6 moves 1 + 1 + 2 + 2 = 6 positions using four turns. It succeeds because the goal is achieved on the fourth move and victory is checked before declaring the limit exhausted. The route 0, 2, 4, 6 also exists, using three legal moves. This is a paper logic check, not a participant-test result.
Try an unsuccessful route: 0, 1, 3, 5, 6. It passes over 2 and 4 without landing, so neither marker is collected. Arrival alone does not satisfy the goal. This example reveals whether “collect while moving” is ambiguous compared with “collect when arriving at the position.”
Check boundaries, not just your favourite route
What happens if the player tries to advance two from 5, announces a zero move, or wants to return from 4 to 2? Under the current rules, these choices are illegal and do not change state. Do not invent an unwritten penalty during testing. Record the situation, then decide later whether an explanation or different rule is needed.
Also check victory on the final turn, reaching the end without items, and restarting. If each boundary requires an oral explanation, that is a note about instruction clarity, not proof the player is incapable. You are not testing their ability to guess what the designer was thinking.
Ask for observation without directing the solution
If someone agrees to try it, explain that the prototype is being examined, not the person. Give them the rules and let them describe their understanding before starting. Do not say “choose two steps here” and then record an independent solution. Note when and why you intervene, separating assisted attempts from independent ones.
Collect only necessary information. Full names and face recordings are unnecessary for this rule check. Obtain clear consent before any recording; anonymous notes can be enough. Afterward, ask “Which rule did you need to reread?” and “Why did you choose that move?” rather than a leading question such as “Weren't the instructions clear?”
Separate events from your explanation
An invented documentation example is “Moved from 1 to 3 and then took marker 2.” That is a describable event. “Was not paying attention” is an unproven interpretation. Perhaps the collection wording was unclear, or the board image suggested something else. Keep alternative explanations and follow-up questions instead of turning expectations into facts about a participant.
Do not write comprehension percentages or success rates without actual sessions and known counts. If you tried the prototype with one person, do not claim all beginners understood it. You may make a limited practical decision from that observation while preserving its evidential limits.
Change one cause and keep the previous version
If the question concerns collection, try improving the sentence or its location without simultaneously changing path, turn count, and other rules. Name the new version clearly. If several aspects change, call it a multiple-change revision rather than attributing every improvement to one sentence.
For a different question about available solutions, you could examine a three-turn version instead of four. Keep it as a separate exercise: the short route 0, 2, 4, 6 remains possible, while the four-move route cannot finish within the new limit. This follows from the rules, not from evidence that the new version is more enjoyable or appropriately difficult.
When should paper become a screen?
Once states, rules, and endings are clear, list the digital representation needed: display position, markers, and turns; choose a move; reject illegal transitions; show an ending and restart. Accounts, purchases, and networking are not prerequisites. Begin with simple shapes you may use, and retain the source and conditions of any external asset.
Godot's documentation offers a first 2D-game learning path with stated prerequisites.
This is an optional later learning route, not a requirement for the paper exercise or a claim one engine fits every project. Read its prerequisites and version before starting. Do not copy the tutorial game and present it as your original design. You can learn a tool while keeping the prototype's purpose small and testable.
Before developing further, write a closing decision for this version: revise instructions, change a rule, or defer the idea? Keeping an unsuitable prototype is a record of what you tried and why you moved on. Time spent decorating is not a reason to retain a rule you cannot explain.
When handing files to someone implementing digitally, send both rules and state table. Ask them to reproduce the final-turn success and unsuccessful route, not merely show an attractive screen. Matching the text is the first handover question. Motion, sound, and interface quality need later examination; this prototype does not establish them.
First-prototype completion checklist
- There is a specific test question, not a promise to establish all enjoyment.
- Start, moves, collection, victory, and endings are written consistently.
- I checked a successful route, an unsuccessful route, and boundaries.
- I can restore the starting state between attempts.
- Observations stay separate from interpretations, and help from independent solutions.
- I preserve versions and reasons for changes without inventing participant results.
Sources and transparency
The Unity Learn unit and Godot page were read on 2 November 2026. The two-marker exercise, rules, table, and routes are original to this explanation and have not been audience-tested. There are no success statistics or commercial-release guarantees. The generated conceptual image is not an implementation diagram. This AI-assisted article has not received independent human editorial review.
