What survives a cut

The hidden cost of entanglement

Cutting a feature sounds like removing a line from a spreadsheet. In practice, something built early enough tends to get load-bearing: other systems lean on it, levels are designed around it, animations are triggered by it. By the time the cut is called, the feature is no longer a module you can lift out — it is a wall, and pulling it brings the ceiling with it.

This is why scope-cutting decisions made late are so much more expensive than the same decisions made early. A feature on a whiteboard costs nothing to remove. A feature that has been in the codebase for six months, that the AI references, that three levels were designed to accommodate, that the tutorial explains — that feature has accreted dependencies. Remove it, and you spend the next two weeks finding every place the rest of the game assumed it was there.

What survives a cut, then, is usually whatever is already woven through enough of the game that extracting it would cost more than shipping it in a reduced state. The feature itself may be diminished — one mode instead of three, one character instead of four — but its skeleton remains, because the skeleton is now part of the architecture.

There is a related phenomenon: features survive because their removal would leave visible seams. A UI panel that references a scrapped system still ships, emptied out. A door that leads to a cut room stays locked rather than disappearing, because rebuilding the wall is a week's work nobody has. Players read these as mysteries; sometimes they are just scar tissue.

The practical lesson is about timing. At concept stage, every feature is droppable. Once it becomes the dependency that other dependencies depend on, it is no longer truly optional — only modifiable. Studios that track coupling between systems early, not just feature lists, are the ones that can still make a clean cut when they need to.