Should the opening instruction explain the entire game?

Usually it only needs to explain the immediate decision. Introduce later systems when the player reaches them, while keeping essential safety or purchase information available wherever it applies.

How can I tell whether the goal is clear?

Watch a tester who has not heard your explanation identify and attempt the goal. Their description and chosen action are more useful than simply asking whether the instructions look clear.

Plan and test game mechanics

A mechanic needs an observable rule: an action, a change in state and feedback to the player. Before adding more systems, test whether the first action, win condition and restart work together. The existing guides below provide the starting workflow and debugging checks.

Open Mechanics collection ↗

Prepare a game for publishing

Publishing starts with a game that can be tested, understood and maintained. Check the available creator controls, audience settings and safety requirements before a release. Use the publishing guide for the sequence, and the troubleshooting guide for an actual blocked step.

Open Publish collection ↗

BC-0031 · CORE GUIDE

Editorial review 2026-09-26

How to Give a Build Game a Clear Player Goal

Tell the player what to do, where to begin and what success will look like. Put that instruction beside the first relevant action, then watch whether a new tester can start without an explanation from you.

Objective

Create an opening goal that a new player can connect to a visible action and destination.

Before you start

Choose the task that actually begins the current prototype.
Identify the object, area or cue that represents that task.
Prepare an observation note without prefilled success claims.

Steps

Write a short action phrase naming the immediate target.
Check that the named target or its intended clue can be recognized from the opening context.
Place a control hint near the action that needs it rather than mixing it into unrelated instructions.
Use consistent names in the objective, progress feedback and completion message.
Ask a new tester what they think the task is before explaining it.
Revise the specific wording or visual cue that caused confusion and repeat the observation.

Verification

The player can describe the goal in their own words before receiving coaching.
The first attempted action relates to that goal rather than a misleading decoration.
Objective text remains readable alongside the controls on the intended screen size.
Progress feedback tells the player whether the intended action counted.
Completing the task changes or removes the old instruction instead of leaving a stale objective.

Limitations

This observation plan has not been run against a generated project by this guide.
A tester's hesitation may come from control or visibility problems rather than wording alone.
Clear instructions do not establish a retention or discovery outcome.

Working notes

Write the immediate goal as an action, not a theme. 'A mysterious island adventure' describes the setting. 'Carry the parcel to the lit dock' tells the player how to begin and supplies a destination they can look for. The opening instruction can be short because it only needs to support the current decision.

Connect the words to something visible. If the instruction mentions a dock, make the intended dock identifiable from the starting area. A label cannot compensate for a destination hidden behind unrelated scenery. If exploration is deliberate, explain the clue the player should follow instead of implying that the destination is already obvious.

Separate objective feedback from control instructions. A movement hint answers how to act; an objective answers why that action matters. Show each where it becomes relevant. Presenting lore, every control, the shop and later goals together makes it harder to identify the action that actually starts play.

Check understanding before coaching. Ask the tester what they think they are trying to accomplish, then let them attempt it. If you explain the route first, you can no longer tell whether the opening screen taught it. Record the misunderstood word or visual cue rather than treating hesitation alone as proof that the whole game needs redesign.

Record prior familiarity when you repeat the check. The same person now knows something about the route, so their next attempt is a familiar-player retest. To examine first-use discoverability again, use another uncoached tester where possible; otherwise label the evidence as a retest rather than a fresh opening observation.

Examples

Opening objective: Carry the parcel to the lit dock. Pickup feedback: Parcel collected—look for the dock light. Completion feedback: Delivery complete. This sequence names the same objective throughout instead of switching between unrelated labels such as cargo, gem and reward.
An instruction that needs revision: Complete all objectives to unlock your destiny. Replace it with the immediate observable task and leave later goals for the moment when they matter. If the player must activate a switch, name or visually identify that switch.
Illustrative observation: The tester walked toward the brightest decoration because it resembled the described destination. Clarify the destination's identity or reduce the misleading cue. Recheck without coaching, recording whether the person is new to the route or already familiar with the earlier attempt.

Common questions

Should the opening instruction explain the entire game?: Usually it only needs to explain the immediate decision. Introduce later systems when the player reaches them, while keeping essential safety or purchase information available wherever it applies.
How can I tell whether the goal is clear?: Watch a tester who has not heard your explanation identify and attempt the goal. Their description and chosen action are more useful than simply asking whether the instructions look clear.