A small brief with a firm boundary
A one-page brief is useful when a project has more possibilities than time. Its purpose is to make the next version clear enough to build and evaluate. It is not a substitute for every production detail, and it does not need to predict the whole future of the game.
Start with the player experience
Write one sentence describing what the player does and why it might be interesting. “Guide a creature through a courtyard by changing the sounds it follows” gives you more to work with than “an atmospheric adventure with innovative mechanics”. Prefer verbs and concrete situations to promotional language.
Add the intended session length and the context of play. A short desktop prototype and a touch-screen game for brief sessions have different practical constraints. If you do not know the final platform, state the one you are testing now.
Define the smallest complete loop
Describe the starting state, the main action, the feedback and the endpoint. For the courtyard example, the player enters, experiments with a bell, moves the creature onto a plate and opens the gate. This sequence gives the prototype a beginning and an end without demanding a campaign.
List the essential assets and systems needed for that loop. Separate them from desirable additions. A save system, dialogue tree or equipment menu may be unnecessary for this particular test even if the eventual game might use one.
Name the exclusions
Write down what this version will not attempt. This is a scope agreement, not an apology. Excluding combat, multiple levels or online features makes it easier to assess a new idea when it appears halfway through development.
For each tempting addition, ask whether the current test becomes impossible without it. If not, put it in a later-ideas list. The brief should help you protect the experiment rather than accumulate every suggestion.
End with a test and a stop condition
State how you will judge the prototype. For example, observe whether a new player can discover the bell-and-gate relationship without a verbal hint. Specify what must work before sharing the build: start, play, restart and finish.
Finally, give the document a version and date. When the design changes, update the brief rather than leaving conflicting intentions in several places. A useful one-page brief is short because its decisions are clear. It gives a small team, or a future version of yourself, something concrete to return to when the project begins to drift.
Decide what to remove
When a small game grows beyond its available time, cutting a few decorative assets may not be enough. The larger cost often sits in systems that depend on one another: inventory, crafting, equipment, progression and the interfaces needed to explain them. Scope reduction works best when you identify the experience you are trying to preserve.
Name the central decision
Write the action that makes the game interesting in plain language. Perhaps the player changes a creature’s route by moving sound sources. If that is the heart of the prototype, a large equipment system may be optional even if it was part of the original pitch.
List the features that directly support the central decision. Then list those that add variety, presentation or future possibility. This is not a ranking of artistic value. It is a way to see which work is necessary for the current test.
Look for dependency chains
A crafting system may require recipes, resources, collection rules, an interface, saving and explanations. Removing only half the recipes leaves most of that structural work intact. Replacing crafting with a single prepared tool might preserve the important interaction while removing an entire chain of dependencies.
Draw a simple connection map if the relationships are unclear. Mark what would break if a feature disappeared. The most useful cut is sometimes a boundary change rather than a smaller quantity of the same content.
Replace breadth with a complete example
Instead of five unfinished levels, finish one that introduces, develops and resolves the main interaction. Instead of several partially working characters, use one with clear behaviour. A complete example helps you judge pacing and comprehension in a way isolated fragments cannot.
Keep removed ideas in a separate document with a sentence about why they were postponed. This reduces the feeling that they have vanished forever and prevents them from quietly returning to the active task list.
Rebuild the plan around the smaller game
Update the brief, asset list and test question after a major cut. Otherwise the old expectations continue to influence everyday decisions. Define what must work before the next playable build and stop adding features once that test is ready.
Scope is not a measure of ambition or seriousness. A small game can ask a precise question and deliver a memorable answer. The useful measure is whether the work you are doing brings the current experience closer to something another person can play, understand and finish.