A first release rarely fails because the idea is small. It fails because the idea grows faster than the time available, and nobody decides what to cut.
Scope is the skill of protecting the part that makes the game worth playing, and postponing everything else without apology or guilt.
The core loop is the product
The core loop is the action a player repeats: aim, dodge, place, decide, collect. Everything else in the game exists to support or vary that single action.
Write the loop down in one sentence. If it needs a paragraph, the project is probably several games sharing one menu screen.
Test the loop before building around it. A strong loop carries simple art and thin content; a weak one collapses under any amount of polish.
Write down what the player does in the first minute and in the hundredth. If those two descriptions are identical, the loop may be too thin to carry a release.
Cut features that are not the hook
Every feature costs more than its own build. It needs a tutorial, an interface, a save state and a bug pass before it counts as finished.
Sort the list into what the loop needs and what would be pleasant. The second column is not deleted, it is simply given a later date.
Removing one ambitious system often buys the polish that makes the remaining systems feel complete rather than merely present.
Be honest about which feature the game is really about. Players remember one thing clearly, and that thing deserves the funded time.
Build a vertical slice first
A slice is one complete piece of the game made to final quality: a single level, a single encounter, a single menu. It proves the whole chain works.
Breadth hides problems while a slice exposes them. If the slice is not enjoyable, more content will not rescue it later.
Finish the slice before adding volume. The work after that becomes repetition of a known pipeline rather than a series of discoveries.
Show the slice to someone outside the project. Their reaction to one level predicts the reaction to twenty more accurately than any pitch does.
Content is the expensive half
Design is measured in weeks, content in months. Levels, enemies and dialogue grow with the number of combinations, not with the number of ideas.
Choose a structure that reuses what it builds. A hub, a run-based format or a small set of arenas keeps content inside a realistic budget.
Decide the content ceiling early and treat it as a rule. Raising it halfway through is the most common reason a first release never arrives.
Count the work in units that repeat. If a level takes a week and the plan contains twenty, the plan has already answered the scope question.
Protect the schedule, not the wish list
Time is the only scope variable that is genuinely fixed. Feature count, polish level and content volume are all negotiable when the deadline approaches.
Give each milestone one testable outcome: the loop plays, the level is complete, the screen is final. Vague milestones hide slippage until it is too late.
When a deadline nears, cut a feature rather than a test pass. A smaller finished game beats a larger one that never reaches players.
Review the plan at each milestone and remove what is no longer needed. Scope creeps in quietly, one entirely reasonable addition at a time.
Postponing is not abandoning
Keeping a written list of postponed work does two things: it silences the fear of losing the idea, and it feeds the next project with material.
Many cut mechanics become the entire hook of a follow-up. Treating them as material rather than failure keeps momentum on the current build.
Nothing has to be thrown away. It only has to be given a different date, and that date is not this release.
Give each postponed idea a short note explaining why it was cut. The reason often matters more than the idea when the next project begins.
Scope for a first release: how to cut without killing the idea
Related guide on this topic.
Know when it is done
A release is finished when the loop works, the content is complete and the remaining problems are known rather than hidden behind promises.
| Scope item | Keep for release | Postpone when |
|---|---|---|
| Core loop | Always | Never |
| Secondary systems | If they support the loop | They need their own tutorial |
| Content volume | What the structure reuses | Every level needs new assets |
| Polish passes | One per finished system | The system may still be cut |
| Online features | If the loop depends on them | They only add reach |
Write the finishing criteria at the start of the project. Deciding what finished means halfway through is how small games grow until they stop being small.
Shipping the modest version teaches more than another year of building. The next project begins with knowledge the current one cannot supply at all.
Accept that the last stretch of polish is invisible to everyone except the developer. Ship when the game is clear, not when it is perfect.
- Write the core loop down in a single sentence.
- Sort every feature into need and pleasant-to-have.
- Finish one vertical slice to final quality before adding content.
- Set a content ceiling and treat it as a rule.
- Cut a feature before cutting a test pass.
Scope is not a limitation imposed by talent. It is the discipline that lets a small idea arrive finished instead of stalling three quarters of the way through.
Cutting is the work. The clearer the cut, the more of the remaining time goes into the part players will actually remember afterwards.
