How to Scope a Game You Can Actually Finish

To scope a game you can finish, lock one core verb, one loss or reset condition, one content multiplier, and one release target. Build a playable version of that loop, measure how long a representative unit takes, and maintain a hard cut list with evidence required to reopen anything.

Scope is not the number of ideas in the pitch. It is the interacting work needed to build, test, explain, distribute, and support the promised game.

A two-hour project can be dangerously large if every minute needs unique art and rules. A game with one screen can be dangerously large if it includes accounts, real-time multiplayer, user-generated content, moderation, cloud saves, and six platforms.

Use this subtraction worksheet alongside the one-page game design document.

Step 1: Write One Core Verb

Choose the action the player repeats while making meaningful decisions.

Weak verbs hide systems:

• explore;
• experience;
• survive;
• progress.

More useful verbs expose implementation:

• route power;
• place blocks;
• negotiate trades;
• dodge projectiles;
• photograph evidence;
• arrange ingredients.

“Explore” can become useful when made concrete: “mark a safe route through rooms that rearrange after every photograph.” Now the game has an action, information, and consequence.

Fill this in:

The player repeatedly [verb + object]
to [observable goal]
while [pressure changes the decision].

If the sentence requires “and” four times, several games may be sharing one design.

Step 2: Give the Game a Loss, Reset, or Completion Rule

The rule tells production which state matters.

Examples:

• a timer reaches zero and the room resets;
• three enemies cross the gate and the run ends;
• the player spends the final resource and must bank the current result;
• every guest leaves satisfied and the day completes;
• the arrangement violates a constraint and returns one piece.

Write what persists after the outcome. Permanent upgrades, local high scores, story flags, unlocked levels, and a completely clean reset require different data and balance.

If the design cannot explain failure or completion, it cannot yet explain what content must test.

Step 3: Choose One Content Multiplier

A multiplier creates new situations from an existing rule. It is how a small game avoids requiring a new mechanic for every minute.

Possible multipliers:

• room layout changes the value of one movement ability;
• enemy routes combine with one line-of-sight rule;
• cards recombine a fixed set of actions;
• dialogue relationships change who provides information;
• one weather state alters visibility and sound;
• resource placement changes the safe route.

Do not count “more content” as a multiplier. Ten hand-authored enemies with unique code multiply production. One enemy interacting differently with terrain can multiply play.

Complete the sentence:

The same [core rule] produces variation when [one changing variable].

Keep one multiplier until playtesting proves it exhausts its useful combinations.

Step 4: Lock the Release Container

Choose boundaries that affect implementation:

Target platform:
Primary input:
Offline or online:
Number of players:
Expected complete run:
Save model:
Languages at release:
Accessibility commitments:
Distribution destination:
Post-launch support promise:

These are not paperwork. Each line changes architecture, assets, QA, store copy, and support.

“PC” is still broad. Keyboard-only, controller support, Steam Deck, Windows plus Linux, and browser export create different test matrices. Promise only what can be verified.

Godot's first 2D game tutorial demonstrates a complete small loop with a moving player, spawning enemies, avoidance, and score. Use that as evidence that a first playable does not need the full release platform matrix. Prove the game first, then expand deliberately.

Step 5: Fill the Subtraction Worksheet

Start with the imagined version, then remove dependencies until one complete experience remains.

The “reopen only if” column is the defense against disguised backlog. “Later” means enthusiasm can restore the item. An evidence trigger makes the cut real.

Use technical requirements and accessibility needs as evidence too. Not every trigger comes from a playtest count.

Step 6: Count Content Units

Name the repeatable unit:

• room;
• puzzle;
• encounter;
• day;
• dialogue scene;
• track;
• mission;
• card set.

Then count the intended release units. “Enough levels” is not a scope.

For each unit, list required work:

Unique risk is where the multiplier may be lying. If every room needs a custom rule and a special save exception, the project does not have twelve units. It has twelve small software projects.

Step 7: Prototype the Riskiest Dependency

Do not prototype the easiest feature. Identify the assumption that could invalidate the game:

• precise movement may not feel readable;
• generated layouts may not remain solvable;
• two-player authority may be too complex for the schedule;
• dialogue variation may explode writing and localization;
• the target device may not hold the performance budget.

Build the smallest test that can kill that assumption. Use disposable assets. Define pass and fail signals before starting.

If the test fails, choose among changing the rule, reducing the release container, replacing the multiplier, or stopping the project. Adding polish is not a response to a structural failure.

Step 8: Measure One Representative Unit

After the prototype, build one unit close to release quality. Track design, code, art, audio, integration, and testing time.

Build a second unit. Compare them.

Forecast remaining unit work = remaining unit count × observed range per unit

Add non-unit work separately: menus, save handling, platform integration, accessibility review, store assets, regression testing, release review, and support.

Use the indie game budget to translate that work into cash and founder-time burn. If the forecast exceeds runway, cut units or complexity before creating more assets.

Step 9: Order the Cut List

A useful cut list is pre-ranked:

1. optional content units;
2. cosmetic variants;
3. secondary progression;
4. extra platform or input promises;
5. nonessential story branches;
6. entire systems that do not strengthen the core verb.

The exact order depends on dependencies. Cutting an online mode late may require undoing account and networking architecture, while cutting two levels may remove self-contained content. Make the order before the schedule is in crisis.

For each cut, record what else disappears:

Cut: second playable class
Also removes: animation set, balance matrix, UI selector, save fields, tutorials, localization strings
Promise preserved: route dangerous rooms by trading light for movement

The best cut removes a dependency tree while preserving the game's sentence.

Run the One-Minute Scope Test

Answer without opening a design archive:

• What does the player do repeatedly?
• What pushes back?
• How does a run end or reset?
• What one variable creates content variation?
• How many content units ship?
• Which platform and input are promised?
• What is the next cut if the forecast grows?

If any answer begins with “It depends,” write the branches and choose one for the current release.

Common Scope Traps

“The System Is Generic, so Content Is Cheap”

Generic code can make authoring possible without making design, art, testing, balance, or localization free. Measure the full unit.

“Online Can Come Later”

Networking can change authority, save state, identity, failure handling, UI, and security. If online is not in the current architecture, describe the game as offline. Do not market a later promise with unknown cost.

“Procedural Means Infinite Content”

Generation adds rules, validation, edge cases, tools, and testing. It can multiply useful combinations only after the output is consistently playable.

“AI Will Finish the Assets”

Any tool may accelerate a step, but the release still needs coherent direction, rights checks, integration, accessibility, performance, and QA. Budget the accepted asset, not the first generated file.

“Early Access Removes the Need to Finish”

Charging for an unfinished state creates its own product, support, communication, and update obligations. It is not a hidden cut list.

The Scope Contract

Finish this page before production:

Core verb:
Pressure:
Loss or completion:
What persists:
One content multiplier:
Release container:
Number of units:
Riskiest assumption:
Prototype pass signal:
Observed unit-cost range:
Available time and cash:
First three cuts:
Evidence required to reopen each cut:

Scope is locked when this contract fits the available runway with contingency and the prototype supports the central decision. It remains alive only through evidence: actual unit cost, target-device performance, playtest behavior, or a platform requirement.

The goal is not to make the smallest game imaginable. It is to remove everything that does not help the chosen game reach a verified release.