Scope: cutting a game down to something you can finish

Why features cost more than they look

A feature is never the feature. It is the feature plus everything that has to exist around it, and the second half is always the expensive half.

• The first 60 percent of a feature is fun to build. The remaining 40 percent is states, edge cases, balance, localisation and bugs, and it takes longer than the first part.
• Every feature multiplies against the others. Crafting plus multiplayer is not two features, it is crafting, multiplayer and crafting-in-multiplayer.
• Content scales linearly with scope, and it is the biggest cost line, which is why cutting a system usually saves less than cutting the content that system needed.

One system deep beats six systems shallow

The most reliable structural advice for a small team, and the hardest to follow, because six shallow systems always sound like a richer game in a pitch document.

• Pick the system your game is actually about and make it excellent. That is what reviews describe and what players tell their friends.
• Everything else is support, and support can be simple without anybody minding.
• Shallow systems are noticed. A crafting system with eleven recipes reads as unfinished; no crafting system reads as a design decision.
• Depth is cheaper than breadth, because depth reuses the interface, the tooling and the content pipeline you already built.

Nobody has ever finished a game and wished it had one more half-built system.

Build the cut list before you need it

The worst time to decide what to cut is the month you have to. By then you are cutting under pressure, protecting sunk cost, and the obvious candidates are the ones already half built.

1. List every feature and content set in the plan. Not tasks, things.
2. Rate each on cost: days remaining, honestly, including states and QA.
3. Rate each on value: does removing it change what the game is?
4. Sort into four groups: core, valuable, nice, and vanity.
5. Draw a line under valuable. Everything below it is your cut list, in order, written down and agreed before anybody is panicking.
6. Revisit at every milestone, because things move between groups as the game becomes real.

Load-bearing features

Some features hold others up, and removing them collapses more than expected. Check before you cut, because this is how a saving becomes a rebuild.

• Economy sinks. Cutting the shop leaves currency with nothing to do, which quietly breaks progression.
• Tutorialisation carriers. If the crafting screen was where players learned resources exist, removing it leaves a hole two hours later.
• Pacing beats. A feature that exists to break up combat is doing work that is invisible until it is gone.
• Difficulty valves. Consumables and upgrades often function as the game's real difficulty setting.
• The test: trace what depends on it, in systems, in teaching and in pacing. If the answer is nothing, it is a clean cut.

Cutting without gutting

The choice is rarely keep it or delete it. These are the intermediate moves, roughly in order of how often they are the right answer.

The scope conversation

• Scope creep is usually good ideas, which is why it is hard to refuse. The answer is not no, it is not now, and a place to write it down.
• Keep a parked list that people trust. Ideas that vanish get re-raised; ideas that are visibly parked stop costing meeting time.
• Price every addition in the currency of the cut list: what comes out to make room? That question converts an abstract request into a trade.
• Watch for feature-shaped fixes. "Players are bored in the middle" is sometimes answered by a new system and more often by cutting the middle.
• Protect the person saying no. On small teams that is usually one person, and without support they stop.

Signs you are already over scope

1. Feature complete has moved more than once.
2. Nobody can list the game's features from memory.
3. Several systems are at 70 percent and none are finished.
4. The team is building new things during what was meant to be polish.
5. The screen list has grown by a third since production started, per from core loop to screen list.
6. Playtesters describe the game with a list rather than a sentence.
7. You cannot say what would be cut if you lost two months.

A scope review, in an afternoon

1. Write the game in one sentence. If you cannot, that is the finding.
2. List every feature and content set on cards.
3. Sort into core, valuable, nice, vanity.
4. For each nice and vanity item, estimate days remaining including states and QA.
5. Add those days up. Compare against the weeks you have.
6. Trace dependencies on everything you plan to cut.
7. Write the cut list in order and share it with the whole team.
8. Agree the trigger: at what point do you start cutting?
9. Park the ideas nobody is building, visibly.
10. Re-run it at every milestone.