# Turn an idea into a playable brief BerryBlox creator resources Edition 1.0 · November 4, 2026 Define the first player journey, the smallest useful build, and what good looks like before work begins. Take away: One clear brief you can use for your next build. Beginner · 6 min read Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms. Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox. ## Start 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.