Turn an idea into a playable brief
Define the first player journey, the smallest useful build, and what good looks like before work begins.
One clear brief you can use for your next build.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Orchard Delivery: one complete loop
- Player promise
- A player follows a marked orchard path, collects three fruit, and brings them to a basket to open the gate back to the starting clearing.
- First version
- One clearing, one path, three fruit, one basket, one gate. No shop, upgrades, multiplayer rewards, or second map in this build.
- Action and feedback
- Collecting a fruit removes that fruit for this player and updates a visible count. The basket explains how many are still missing; it does not accept an incomplete delivery.
- Completion check
- Start at the real spawn. Deliver all three fruit once, see the gate open, then return to the basket and confirm it does not award another completion.
- Next question
- Can a new player find the basket without a spoken hint? Capture the route and the first point of hesitation before adding more features.
Expected resultA brief with one named ending, a refusal case, a small scope, and a question the next prototype can answer.
Try it in your blank worksheetStart with one player promise
Describe what a player does and why it feels rewarding. Keep the first version small enough to observe from arrival through a complete loop. A list of genres or features is not a player journey.
Use your own references as direction, and describe the specific quality you want to borrow: readable paths, a calm palette, or a satisfying interaction. Record rights and provenance before reusing anyone's assets.
Illustrative brief: players explore a small orchard, collect three marked fruit, and return them to a basket to open a second path. This is a design example, not a built or tested game.
- Working title
- Player and intended device
- In one sentence: players [action] to [goal] because [reward]
- What makes this yours
- Reference links and the specific qualities to study
Write the first complete loop
Name the action, the visible cue, and the state change for each step. Walk the intended path from the player's actual spawn; a staged camera view cannot establish that a player can find it.
- The first objective can be understood without reading the whole brief.
- An unsuccessful action has a clear response and a way to recover.
- There is one named completion event, separate from later upgrades or unlocks.
- Arrival: what is visible and what can the player do?
- First action: input → feedback → authoritative result
- Reward: exact quantity, unit, and unlock condition
- Return: what makes the next loop interesting?
- Refusal: what happens when a requirement is missing?
Choose a small build and a clear handoff
Separate required behavior from optional polish. Assign each deliverable one owner, an exact output, its dependencies, and a review question. A visual reference is not a tested asset; a saved script is not an integrated feature.
- Inputs, UI, rewards, and failure recovery have an owner.
- An acceptance check includes normal play and at least one changed or refused case.
- The handoff lists unresolved art, runtime, device, and service checks.
- Must have for this loop (maximum five items)
- Later ideas, deliberately outside this build
- Reusable source, permissions, and known limitations
- Deliverable / owner / dependency / output path / review question
- Acceptance: player action + expected result + evidence to capture
Make the next session concrete
Take one unanswered question into the next session. For a first prototype, the useful question may be whether players understand the first interaction, rather than whether the whole game is ready.
- Next question to answer
- Smallest task that can answer it
- Evidence to bring back
- What would make us revise the brief?
Try a ten-minute brief review
Read only the player promise and the loop aloud to a teammate. Ask them to explain the first action, the reward, and the ending without seeing your feature list. If their version differs, revise the promise before assigning more work.
Keep the required build to a single complete route. Put ideas that do not help answer the next question in the later list, with the reason you deferred them.
- What your teammate understood / missing cue / one change to the brief
Evidence and limits
This is an editable planning workbook. It contains no scripts, models, or Studio-tested game assets. Completing it does not prove the game is playable, secure, optimized, or ready to release.
Record statuses separately: planned, implemented, locally checked, Studio tested, physical-device tested, and owner accepted. Keep the exact build and unresolved checks with each result.