How to cut a feature

Every game project hits the moment where something has to go. If you sorted features into Must, Should, Could and Won’t while scoping your game, the Should list is the first to go when time runs short. Writing something down as Won’t ends the argument.

I make Tingbase in Unity 6 and C#. It’s a 3v3 hero shooter where you swap between Tank, DPS and Healer. Here’s how I decide what goes.

What the player loses

A tip published on beindie on 3 August 2026 puts the decision in one question. If this feature goes, what does the player lose? If the answer is some depth or some variety, the feature was never required. Cut it.

The follow-up is for the sentence “it does not work without this.” What happens if the player never notices it is missing? If the answer is nothing, the absence belongs to you. The player is looking for what you promised. Eduardo Amengual Risso, at EDAM Games, frames the same cut as an experience you are keeping. Write down the experience the project must still deliver. Separate the mechanics that support it from the ones that only add possibilities.

Risso’s move is the example. Shadow Strike’s stealth, memory, and alerts each needed intelligence, levels, animation, interface, and sound, and the player still had to understand why. He paused that project. Boostbound spends the ambition on a car reaching the end of a level. Your depth stays on the verb you already kept.

On Tingbase the verb on Steam is: pick a role, enter a match, play until it ends. An extra system that does not serve that sentence is the one I cut.

Which feature is in front of you?

Only variety or depthAlready wired into other systemsThe one I built

If the player only loses variety, it is out. Write it on the later list and describe the game without it.

List code, content, interface, sound, testing, integration, and the iteration after the first version. The visible task is the small number. Kira Walsh’s scoping chapter keeps a feature as core only when removing it makes the game incoherent, and allows a wishlist row only when you can name what leaves the core. In that list, the default is out. The smallest game loop shows that core.

A time box, then a sentence

Reed Devany, lead producer on SeaFeud, an underwater racing game made in Unreal Engine 5 by 48 graduate students at the SMU Guildhall, describes two ways a cut got made. No method is guaranteed. Dated June 26, 2023.

A structured go/no-go gives a threatened feature a short calendar and conditions it has to meet. Miss them, and it leaves. The proof can be that it works and can be finished without dropping the rest. On SeaFeud the ceiling was five days, most passes under nine hours a person. Those are their boxes. Of six decisions, the team kept some he expected to lose.

One case was cat people living underwater. By first playable the team still could not explain how that society functioned there. The artists had two days to make the aesthetic work, or the characters would change. The conditions failed, and the cats were cut. Devany sat with the designer who had loved them. The feelings were real, and the agreed conditions still stood.

The other method is calling the cut when a time box would cost more than it saves. Coral Canyon was one of four tracks, each with its own art, and the lead artist said the pool could not cover every request. The canyon sat half a milestone behind and needed extra engineering. They removed it so three tracks could be finished. The designers, six weeks in, could reverse an existing track, build from assets they had, or join the other teams. They joined the other teams. What shipped was the smaller set, played by testers.

Rob Sandberg, in a production note dated June 5, 2026, separates the cut from dismissing the work. Acknowledge that the work was good. Then one sentence: the time you have, the label the feature carries, and that it is out. “Parked for now,” when the decision is that it is out, is a different sentence, and he says people hear it. If you are alone, the beindie tip names the hard case. The feature nobody will discuss often belongs to the person who most enjoyed building it. On a solo project, that person is you.

Turn it off, then write it down

Describe the game as if the feature had never been promised. In Metal Thunder he cut a real AC-130 crew’s fire-control officer, sensor operator, and radio coordination early, because a player cannot carry that load at once. A late cut would have meant pulling out the systems around those roles.

Turn the feature off and hand someone the build. Ask whether anything is missing. If they notice only after you ask, the cut has its answer. Write the feature on the later list. The note stays, because deleting it reopens the argument the scope page already closed. What a playtest is for is that hand-off.

In Unity, the cut is one change. Name the script that serves the feature, read the diff, and reject any edit that removes the core action you kept. Leave the scene in the editor. When the build still starts, loses, and quits, commit. The later list holds the idea. The project holds the game you can finish.

A cut that is only a feeling is how a week disappears. A cut that is a sentence is how Tingbase stays the game on the Steam page.

Related: Game development, How to make a game in Unity, Mini Games Arena, projects.

Common questions

How do I know which game feature to cut?

Ask whether a player would notice it missing. If the core game still works without it, it's a good candidate to cut.

Should I delete the code when I cut a feature?

Turn it off first and play a build without it. Remove the code once you're sure the game still works fine.

When is it too late to cut a feature?

When other systems have been built around it. The earlier you cut, the cheaper it is.