I'm making Tingbase in Unity 6 and C#. It's a 3v3 hero shooter where you swap between Tank, DPS and Healer. The core sentence for it is short: pick a role, enter a match, play until it ends. Anything that doesn't serve that sentence is a candidate for the cut.

The one question I ask first

If this feature goes, what does the player actually lose?

If the honest answer is "a bit of depth" or "a bit of variety", the feature was never required. It goes on the later list.

The follow-up is for when I catch myself saying "it doesn't work without this". Would a player notice it was missing if I never told them? If not, the absence is mine, not theirs. Players look for what you promised them, not for what you imagined.

Count the real cost

The visible task is always the small number. The real list is code, content, UI, sound, testing, integration with other systems, and then the second iteration after the first version is "done". When I write all of that down next to a feature, most cuts make themselves.

Time box it, or just call it

Two approaches I've seen work on real teams:

1. Give the threatened feature a short, dated window and clear conditions. If it misses them, it leaves. No re-arguing.
2. If even the time box would cost more than it saves (extra systems, already behind), call the cut right away.

Whichever one you use, say it in one plain sentence: how much time there is, what the feature is, and that it's out. "Parked for now" is a different sentence, and people hear the difference. On a solo project, the person most attached to the feature is you, so be honest with yourself here.

Turn it off, then write it down

In practice I turn the feature off, hand the build to someone, and ask if anything feels missing. If they only notice after I point at it, that's my answer.

Then I write it on the later list instead of deleting the note. Deleting it just reopens the argument a month later.

I wrote a longer version with examples from other studios' production notes and a decision table here: How to cut a feature on yuvalgg.com

I work this way on Tingbase, a 3v3 hero shooter I'm building in Unity 6 and C# (Steam app 4086630). It's already bigger than a one-verb toy, but the rule didn't change: one loop, three roles (Tank, Healer, DPS) that share it, and a store page I can point at.

Write the sentence, then write what is out

Put the game in one sentence: who does the verb, where, and how a try ends. If the description needs a second page, it's still two games.

Then sort every feature into four buckets:

• Must: what the game can't start, end or be understood without. Usually the verb, the fail state, and what those two need.
• Should: useful, and the first thing cut when hours run short.
• Could: the idea you're excited about.
• Won't: the decision you write down so you don't argue it again in month four.

Write the cut order while you're calm, so when a week runs behind you just read the next line. Reopen a cut only with evidence (a playtest note, a timed piece that proved the list wrong), never with a 1 a.m. mood.

Time one piece before you time the game

Guessing the whole game from enthusiasm is how the list lies. Build one representative piece in plain shapes. If the grey boxes aren't fun, painting them won't rescue them.

Then write down how long that piece took. Your real estimate is that time, multiplied by the number of pieces, plus the work around them: menus, saving, testing, and whatever you promised for release. List every asset the finished version still needs (art, animation, sound, UI, music), give each a time that includes polish, and trim until the total fits the hours you actually have.

The content multiplier

Once the verb works, you repeat something: more rooms, more waves, more heroes on the same rules. For Tingbase that's modes and roles around one shooter loop. A multiplier is only cheap when the pipeline exists. The first room teaches you the verb; the fifth tells you whether art, collision and spawns still take the time you wrote down. If not, cut rooms before you add a second verb to fill the week.

MVP first, then one polished piece

These are two different questions, and I used to mash them together:

1. MVP: the ugliest version that still has the loop. Colored boxes, a beep, one fail, a restart. It asks: is this fun at all?
2. One polished piece: a chunk with final art, sound and UI. It asks: how long does finished content really take? Use that number for the rest of the list.

Before both, prove the build path: a blank project that launches outside the editor.

Decide what survives a loss

The fail state decides your data. A run that resets to a clean room is one job. A local high score is another. Unlocks, story flags and permanent upgrades are more jobs, each saved, loaded and tested. "It saves" can mean three different games, so write down the one you mean. Same for platforms: one PC, one player, offline is a test you can run tonight. Accounts, matchmaking and cloud saves are a later project.

The store page is scope too

A store listing, an installable build, an age rating, a trailer, and a tutorial for every system you add are all hours. If the game goes on Steam, the page is a Must just like the quit button.

The calendar is a poor boss

Published advice ranges from two weeks to nine months or more for a first game. That disagreement is the warning: the number of weeks isn't the test, the timed piece against your available hours is. Give each milestone one testable outcome ("the loop plays", "the level is complete"), and when a deadline gets close, cut a feature, not a test pass.

New ideas wait on the later list

Crafting, a day-night cycle, a friend who can join: each sounds like an afternoon, but brings art, UI, edge cases, saves, balance and a tutorial. Write the idea on a later list the hour you have it, review that list only at a point you already scheduled, and let it in only if it serves the original verb.

The first game is finished when a stranger can start it, lose, and try again, and you can still describe it in the original sentence. The later list is the start of the next one.

This post first appeared on yuvalgg.com. Read the full guide on yuvalgg.com, with the sources I used and a quick check on what to do with a feature you want to add. If you already have a prototype, here's what a vertical slice is and how I scope one.

I make Tingbase, a 3v3 hero shooter, in Unity 6 and C# (Steam app 4086630), and I’m building my second game, Mini Games Arena (Steam app 5080600), in Unity too. Below is how I think about a slice for both of them.

Prototype, slice or demo

A prototype comes first. If the core of the game is not fun in grey boxes, final art will not save it. The slice comes after, once you know what you are building.

What a slice looks like in Tingbase

Tingbase is built around one idea: you switch between Tank, Healer and DPS instantly with the 1, 2 and 3 keys, in the middle of a fight. That switch is the heart of the game, so it has to be in the slice.

A thin slice for a game like this is one arena, one full 3v3 match, all three roles, and the switch between them, with final-quality models, effects, sound and HUD. It does not need every mode. Tingbase has PvP arenas, deathmatch and co-op waves, plus a Simple and a Complex ability mode, but one mode played start to finish tells you more than five half-built ones.

What a slice looks like in Mini Games Arena

Mini Games Arena is a different shape. Players meet in a hub, the host starts a shuffled run of short minigames, every round scores points, and the top players end on a podium. Coins from kills, goals and wins go to a locker with skins, emotes, weapons, cars and trails.

Here the slice is not one minigame. It’s the whole loop at a small size: the hub, two or three minigames, scoring, the podium and the locker. That proves the flow works. After that, each new minigame is content you repeat, and the slice tells you what one costs.

How thin to make it

Pick the smallest piece that has a start, the core challenge and an end. For a match-based game that’s one match. For a level-based game that’s one level. If the piece can’t be played start to finish by someone who has never seen it, it’s not a slice yet.

Keep the amount of content tiny and the quality high. One finished arena teaches you more than three rough ones.

Time the second one

The first finished asset is slow because you are also building the pipeline: import settings, materials, sound setup, how things get into the build. The second one shows the real cost. Time it, multiply by how many you plan to ship, and you have an honest estimate for the rest of the game. If the second takes as long as the first, the pipeline is not ready yet.

This is where a slice saves a small team. It turns “we’ll add more maps later” into a number. If that number does not fit, cut features before you start production, not after.

What you leave out

Placeholders are fine in places a player barely looks, like a menu icon, as long as you mark them. The main play area should be final, or the slice won’t tell you the real cost. Known bugs can stay if they don’t block a full playthrough. Menus, options, extra modes and progression beyond what the loop needs can wait.

When you’re done

The slice is done when a new player can start it, play the whole piece, and finish it at the quality you plan to ship, and you know how long the next piece takes. Then you can decide whether to build the rest of the game, show it to a publisher, or turn part of it into a demo for your Steam page.

This post first appeared on yuvalgg.com. Read the full guide on yuvalgg.com, with an interactive check for whether what you have is a prototype or a slice. If you are still deciding what goes in the game at all, I wrote up how I scope a first game too.