Eleven months into a two-year project, your task board has 340 open cards and your milestone says "Vertical Slice — 6 weeks". You already know you are not shipping all 340. What you probably do not know is which 60 of them are the game, and which 280 are the reason you will miss the date.
Scope cutting is the least glamorous skill in game production and the one that most reliably separates finished games from abandoned ones. It is also badly taught. "Cut scope" is advice, not a method. This is a method: a repeatable triage pass you can run in an afternoon, at any point in production, that produces a defensible list of what stays, what shrinks, and what dies.
Why "cut the least fun stuff" fails
The intuitive approach — rank every feature by how fun it is and chop the bottom — breaks for three reasons.
First, fun is not independent. A crafting system that scores 4/10 alone may be the only reason your resource economy has a sink. Cut it and the economy collapses, which is a much bigger hole than the one you were patching.
Second, cost is invisible in a fun ranking. A 3/10 feature that takes two days is cheaper to keep than a 7/10 feature that needs six weeks of animation, a new UI screen, localization for 400 strings, and a tutorial beat.
Third, some features are load-bearing for marketing, not for play. If your Steam page and your pitch deck both lead with "asymmetric co-op", that feature is functionally un-cuttable regardless of how it scores, or you are shipping a different game than the one you sold.
So triage on three axes, not one.
The three-axis triage pass
For every feature, system or content batch on your board, score three things from 1 to 5:
- Pillar support — how directly does this serve one of your stated design pillars? A feature that serves no pillar scores 1, no matter how much you like it.
- Remaining cost — everything left to reach ship quality: implementation, art, audio, UI, tuning, localization strings, QA, and the tutorial or onboarding beat it demands. Score 1 for cheap, 5 for expensive.
- Blast radius — how many other systems break or lose meaning if this is removed? 1 = isolated, 5 = load-bearing.
Then compute a keep score:
keep = (pillar × 2) + blast_radius − remaining_cost
Pillar is doubled because a game that is cheap and coherent but serves no pillar is not the game you set out to make. Sort descending. The result is not a decision — it is a reading order. You still argue about the middle, but you argue with numbers in front of you instead of vibes.
| Feature | Pillar | Cost | Blast | Keep | Verdict |
|---|---|---|---|---|---|
| Weapon modding | 5 | 3 | 4 | 11 | Keep, full scope |
| Enemy faction AI | 4 | 4 | 4 | 8 | Keep, reduced |
| Base building | 3 | 5 | 2 | 3 | Reduce to a single hub |
| Fishing minigame | 1 | 3 | 1 | 0 | Cut |
| Photo mode | 2 | 2 | 1 | 3 | Defer to post-launch |
The interesting rows are the ones scoring 3–6. Those are your reduction candidates, and reduction is almost always better than deletion.
Reduce before you cut
Most features have a cheaper version that keeps 80% of the value. Before you delete anything, ask what the smallest honest version looks like:
- Fewer instances, same depth. Six enemy types with three behaviours each beats eighteen types with one. Depth is what players read as "designed"; breadth is what they read as "content".
- Systemic instead of authored. Replace 40 hand-scripted events with 8 event templates that pull from a table. You lose specificity and gain a shipping date.
- Static instead of dynamic. A weather system that changes per-level on load is a fraction of the cost of one that transitions in real time, and most players will not notice which one they played.
- Cosmetic instead of mechanical. If a faction system is expensive because factions must react to each other, ship them as flavour and reputation gates first. The mechanical version becomes a post-launch feature with a real audience attached.
Hades shipped God Mode — a stacking damage-resistance buff — rather than a full difficulty-options matrix. Celeste's Assist Mode exposes a handful of toggles like game speed and invincibility instead of a bespoke easy-mode content pass. Both are the cheap version of an expensive idea, and both are better designs than the expensive version would have been, because they are legible in one screen.
Running the pass without a fight
The reason teams avoid scope triage is that it feels like a referendum on whose work matters. Structure it so it is not.
- Write pillars down first, and get agreement on them before anyone sees a score. Three to five sentences. "Every fight is a puzzle with a time limit" is a pillar. "Fun combat" is not.
- Score cost with whoever will do the work, not with the person who wants the feature. Designers systematically underestimate art and localization tails.
- Score in one sitting, decide in another. Sleeping on it kills roughly half the arguments.
- Record the reasoning, not just the verdict. Six weeks later someone will ask why base building got cut, and "I think we ran out of time?" is how features get quietly re-added.
- Give every cut feature a destination: post-launch, sequel, or dead. "Dead" is a valid and useful answer. Ambiguity is what causes a cut feature to keep consuming design attention.
That last point is where documentation earns its keep. In GameDesignerX, the natural home for this is the decision log — one entry per verdict, with the pillar it served, the score, and the reason — cross-linked to the mechanics entry it retires and the milestone it was pulled from. Cut features move to a deferred column on the task board rather than being deleted, so a later "can we bring back X?" is answered by reading, not remembering.
What to check after the pass
A triage pass that only removes things will quietly break your game. Two follow-ups are mandatory:
- Re-check your economy sinks and sources. If you cut a crafting system, something was consuming resources that no longer does. Faucets and sinks have to rebalance after every content cut.
- Re-check your onboarding. Every cut removes a tutorial beat; every reduction changes what the first ten minutes teach. Walk the opening once and confirm it still introduces only the mechanics that survived.
Then update the milestone with the new estimate, not the old one with fewer cards in it. The point of triage is a date you believe. If the number did not move, you did not cut enough.
A short checklist
- Pillars written down and agreed, before scoring
- Every open feature scored on pillar, cost, blast radius
- Cost scored by the person doing the work
- Reduction options written for everything in the 3–6 band
- Each verdict logged with reasoning and a destination
- Economy sinks/sources rechecked
- Opening ten minutes re-walked
- Milestone date recalculated and communicated
Run this at every milestone boundary, not just when you are panicking. The first pass will be painful and will take a full day. The fourth will take two hours, because by then you will have stopped adding things you were always going to cut.