Chapter 37: Scope Management — Why Your First Game Should Be Small (and How Small Is Small)

Every designer — every single one, without exception — has the same conversation with themselves sometime in the first year of trying to make a game. It goes like this. They sit down with a notebook. They write "MY GAME" at the top of the page. And then, for two glorious hours, they describe it. A vast open world. Eight playable characters with branching stories. A crafting system. A base-building system. A political reputation system. Procedural dungeons. A companion AI that remembers everything you do. Seven endings. Multiplayer. Mod support. Voice acting. An original orchestral score. A photo mode. A New Game Plus. The notebook fills up. The future game is gorgeous in the designer's head. It is the game they always wanted to play. It is the game the world needs. They close the notebook with the quiet satisfaction of someone who has done important work.

Then they open Godot. Or Unity. Or Unreal. And they try to move a character across a screen.

Three weeks later the character moves. A month after that, the character can jump. A month after that, the character can attack. The notebook is still in a drawer. The eight playable characters are as distant as Mars. The designer has built approximately one half of one percent of the game they described, and they have already worked harder than they have ever worked at anything in their life. At this point, one of two things happens. The designer either quits, or the designer makes the single most important decision of their career: they admit, out loud, that the game in the notebook is not the game they can ship. The game they can ship is a much smaller game. And they start cutting.

That cut is what this chapter is about. Scope management is the craft of deciding what your game actually is — not what it would be if you had infinite time and money and team, but what it will be given the actual time and money and team you have. It is the least romantic topic in game design. It is also, in practical terms, the one that determines whether you ever finish a game at all. Everything else in this book — mechanics, level design, narrative, systems, polish — is downstream of scope. If your scope is honest, those things get their chance. If your scope is not honest, none of them do, because the game dies in the middle.

I don't care if your game is "innovative." I care if a player picks it up and doesn't want to put it down. For that to happen, the game has to exist. For the game to exist, you have to ship it. For you to ship it, the scope has to be one that a person (or a small team) can actually finish. This chapter is the one that ties the previous thirty-six together by asking: of everything you could build, what will you build? And, maybe more importantly: what are you going to let go of?

The Scope Trap

First-time designers make the same mistake. Not a similar mistake — the same mistake. They start with a game too big to ship. This is not a failure of intelligence or ambition; in fact, it is almost always a function of excess ambition, which is why it is so hard to correct. You love games. You have played games with a hundred hours of content. You know what excellent games look like. You want to make one. You have taste. The gap between your taste and your skill is where the trap lives.

Call it the dream-game fallacy. The dream game is the one you see in your head. It is always larger than it needs to be, because dreams do not have scope spreadsheets. In the dream, you see the final product — the polished trailer, the Steam page, the reviews — without seeing the three years of grinding implementation that made it. You see the result, not the labor. When you start building, you start from the dream, and every week the dream says and also this, and also this, and also this. The dream is never satisfied. No game ever matches the dream. The dream's job is not to be matched; it is to inspire you to start. Once you start, it needs to be replaced with a scope that corresponds to reality.

The trap has a second form, subtler and more dangerous: just one more feature. You have built the core movement. It works. The character moves, jumps, attacks. You could stop adding features and start building levels. But there is this one idea you've had about a grappling hook, and wouldn't it be cool if — and now you are spending two weeks on a grappling hook, and the grappling hook interacts poorly with the double jump, and now you are retuning the double jump, and the grappling hook and the double jump together break the camera, and now you are rewriting the camera. Three weeks ago you had a moving character. Today you have a moving character, a grappling hook, a double jump, and a broken camera. The game has gotten bigger. It has not gotten better. Nothing you added is levels, or enemies, or story, or polish. You added surface area — things to maintain, balance, test, teach, and eventually ship.

This is how games die. Not dramatically. Not in a single explosion. They die because every week for two years the surface area grows and the core content doesn't, and one day the designer looks at the project and realizes that finishing it would take another three years, and they do not have another three years in them. They close the project. They do not ship. Nobody ever plays the game.

I have watched this happen to friends. I have done it myself. It happens to professional studios; it is the story of half the unreleased indie games on abandoned itch.io profiles. The scope trap is the ordinary way games fail. Learning to recognize it, and to resist it, is not a nice-to-have design skill. It is the design skill in the shipping phase. Without it, none of the other skills get to meet a player.

💡 Intuition: The game in your head is a mood board. The game you will ship is a budget. These are different documents. You cannot ship a mood board. You will ship some version of a budget. The only question is whether you write the budget now, honestly, or discover it three years in when everything is on fire.

What Scope Actually Means

When designers say "scope," they often mean different things without realizing it. Getting precise about scope is the first step to managing it. Scope is three-dimensional, not one-dimensional. Trimming one dimension while expanding another is not actually cutting scope; it is rearranging it.

The three dimensions are content volume, system depth, and polish bar.

Content volume is the raw amount of stuff in the game. Levels, enemies, items, dialogue lines, cutscenes, audio files, areas, bosses, weapons, characters. The things a player will encounter. A game with 20 levels has more content volume than a game with 5. A game with 50 enemies has more than a game with 8. If you doubled the number of levels in your game, you doubled that dimension of scope.

System depth is how many interacting mechanical systems your game has, and how deep each one goes. Into the Breach has a small amount of content volume (eight maps, a handful of missions) but a deep combat system where every unit, weapon, and enemy interacts in predictable ways. Stardew Valley has moderate content volume (one valley, a dozen villagers) but enormous system depth — farming, fishing, mining, combat, relationships, cooking, crafting, seasons, festivals, a whole calendar of events. More systems compound: adding a crafting system means every new item needs a recipe, every recipe needs ingredients, every ingredient needs a source, every source needs to be balanced against every other source. Systems are multiplicative in cost.

Polish bar is how finished every piece of the game is. Animation smoothness, sound design density, UI clarity, bug-count, visual fidelity, game feel. A game with a low polish bar feels like a prototype. A game with a high polish bar feels like a shipped product. Celeste's polish bar is extremely high — every movement has tuned easing, every sound has feedback layers, every menu is considered. Raising the polish bar on an existing game is not cheap; it often costs more than the initial construction.

Scope is a cube defined by these three axes. If you pick large content volume and high system depth and high polish bar, you have described The Witcher 3, which took CD Projekt Red more than three and a half years with hundreds of people. If you pick small content volume and low system depth and high polish bar, you have described Journey, which took thatgamecompany about three years with a small team. If you pick small content volume and high system depth and low-to-moderate polish bar, you have described Dwarf Fortress, which has been in development for more than two decades by two brothers.

There is also a fourth hidden dimension: time. Scope always includes a time axis. You can achieve almost any cube of content/systems/polish if you are willing to spend enough calendar time on it. The trouble is that calendar time is not free. You have a life. You have finite runway. You have collaborators with their own lives. You have the risk that if you take too long, the context around the game changes — the market moves, the platform you targeted changes, your team loses steam. Time is not a magic resource you can always pay with.

Which brings us to the tradeoff triangle. You have heard some version of this before, in other fields: fast, cheap, good — pick two. Games have their own version: scope, quality, time — pick two. If you want high scope and high quality, you pay in time (years). If you want high scope and fast delivery, you pay in quality (half-finished). If you want high quality and fast delivery, you pay in scope (small). There is no fourth option where you get all three. Every game that appears to have hit all three — hit the deadline, shipped polished, huge scope — had either an invisible subsidy (enormous funding, thousands of people, years of pre-production that don't count as "the project") or an invisible cost paid by people's health and relationships (the crunch that shows up in postmortems but not in trailers).

Scope management is, at its core, choosing your position on this triangle honestly. You do not manage scope by wishing. You manage it by deciding, concretely, what the other two corners of your triangle look like.

The Rule of 3x

Everything takes three times longer than you think it will.

Not two times. Not one and a half. Three.

This is not a joke. It is the single most reliable estimate a designer ever makes. When you sit down with your team and try to guess how long a feature will take, the right move is to let people say their number, and then multiply by three. Not because your team is incompetent — they are not — but because humans, as a category, are bad at estimating creative and technical work. We estimate the happy path. We do not estimate the twelve edge cases that show up in testing, the dependency on a system that was not quite ready, the day someone is sick, the refactor that becomes necessary three weeks later, the bug that turns out to be in the engine and takes two days to isolate. These are not exceptions. These are the average development week. The happy-path estimate leaves them out. Reality does not.

This is Hofstadter's Law, compounded: "It always takes longer than you expect, even when you take into account Hofstadter's Law." Douglas Hofstadter was describing human work generally. Games are a particularly savage example because they sit at the intersection of software (where edge cases breed) and art (where quality is subjective and iteration is infinite). You cannot truly finish a feature; you can only decide it is good enough. The decision-that-it-is-good-enough is itself the longest part of development. That is why 3x is, if anything, too conservative for certain kinds of polish work, where 5x or 10x is more accurate.

What does 3x mean in practice? It means your "six-month project" is an eighteen-month project. Your "one-year project" is three years. Your "one weekend's work on the menu system" is a week. If this sounds depressing, that is because you are still living in the happy path. Once you accept the 3x rule, you plan in 3x terms, and you become radically less depressed about development — because suddenly reality matches your plan. The misery is not in slow development; the misery is in slow development measured against a fast plan. Fix the plan. Plan for reality. You will feel better, and your game will ship.

🛠️ Practitioner Tip: When planning a milestone, get estimates from your team and then quietly tripling them in your private schedule. Do not tell the team you are doing this. Their optimism is what keeps them making. Your private triple is what keeps the project solvent.

The best teams develop calibrated estimation over years of deliberate practice — tracking what they estimated versus what it actually took, until they get better. You do not have years yet. So use 3x until you develop better instincts. You will not overshoot. I promise.

The Vertical Slice Principle

The single most important artifact of game production is the vertical slice. This is the one polished thing that represents the whole. A level that has all the features the final game will have — combat, exploration, narrative, UI, audio, polish — at production quality, even if only for a narrow piece of the game. If your vertical slice is good, the game will probably be good. If your vertical slice is not good, the game will almost certainly not be good. The vertical slice is your concrete answer to the question what will the game actually feel like?

A vertical slice is not a demo. A demo is a marketing artifact, usually produced late. A vertical slice is a development artifact, produced early. Its audience is you, your team, your publisher if you have one, and trusted playtesters. Its purpose is to prove the core experience works before you commit to building thirty levels of it. Proof of this kind cannot be faked. You have to actually build the thing.

Half-Life 2 is the legendary example. Valve famously built a "sandbag demo" — a short, hand-crafted combat scenario — that they used for years to prove the physics-based gameplay could carry the game. Before the sandbag scenario played well, the studio had no game. After it played well, the studio had the proof of concept it needed to commit to building the rest. The sandbag wasn't in the final game. It was the vertical slice.

Breath of the Wild's Great Plateau is the shipped vertical slice. Nintendo built the Great Plateau — the walled-in starting area — as a compressed version of the entire game. Every mechanic you will use in the next hundred hours is introduced there: climbing, cooking, weapon durability, elemental interactions, shrines, physics puzzles. If the Great Plateau is not fun, Breath of the Wild is not fun. The team could tune the Great Plateau to ruthless precision, knowing that if they got it right, the rest of the game would inherit that quality. It is a vertical slice that stayed in the product.

For an indie working on the progressive-project action-adventure game of this book, your vertical slice is one complete level. Not one screen. Not one combat encounter. One level, start to finish. It has its tutorial beats, its exploration, its combat, its secrets, its boss, its resolution. It has the art style you will ship with. It has the audio mix you will ship with. It has the UI you will ship with. It has the polish you will ship with. When you play it, it feels like the game, not like a prototype of the game.

Building that vertical slice is hard. It takes months. It forces decisions you would rather defer — what is the art style actually? what does the UI actually look like? what does the boss fight feel like? You cannot hand-wave those questions in a vertical slice. You have to answer them.

But once you have the slice, two things happen. First, you know whether your game is worth making. If the slice isn't fun, the game won't be fun, and you have saved yourself two years of building a non-fun game. You can rework the slice, or pivot, or abandon — but you make the decision now, cheaply, instead of later, expensively. Second, if the slice is fun, you have a template. The rest of the game becomes a matter of producing more levels to the standard the slice set. You have answered the hard questions. Now you are in production, which is still hard but at least is a known quantity.

🎮 Case Study — The Great Plateau: The first 90 minutes of Breath of the Wild are the entire game in miniature. Climbing a tall thing. Cooking dinner. Sneaking past a monster. Lighting a tree on fire and using the updraft. Discovering a shrine. If Nintendo had put those 90 minutes in front of a playtester and the playtester had said "this is dull," the whole game would have been in trouble. They didn't. The playtester said "I cannot put this down." The rest of the development was, in a sense, scaling that proof.

MVP vs. Vertical Slice

There are two models for "what do I build first to prove the game works." You will hear both terms, and they mean different things. Picking the right one for your project matters.

MVP (Minimum Viable Product) is the language of tech startups, borrowed with adjustments into games. An MVP is the ugliest, smallest version of the whole game that plays end to end. It has the opening, the middle, the ending. Every mechanic is present in the simplest possible form. The art is placeholder. The audio is thin or missing. The UI is temporary. But you can start the game, play it through, and reach the credits.

The MVP's purpose is to prove the structure works. Does the arc of the game hold together? Do the mechanics pay off against each other? Is the pacing right? Is the length right? An MVP tells you whether the game is shaped correctly.

Vertical slice is the language of game production specifically. A vertical slice, as above, is a narrow but polished piece of the game at final quality. It proves the feel works. Does the combat snap? Does the art style read? Does the audio punch? Does the level design guide the eye? A vertical slice tells you whether the game is textured correctly.

These serve different questions, and which you build first depends on what you are more worried about. If you are confident the game will feel great but worried whether the overall structure holds up — whether twenty hours of this mechanic will be boring, whether the story's arc lands — build an MVP first. If you are confident the structure works but worried whether the moment-to-moment feel will be good enough — whether combat is satisfying, whether the art style reads — build a vertical slice first.

Most indie projects need the vertical slice sooner. The question most first-time designers most need to answer early is "is this fun second-to-second?" because if it is not, nothing else will save it. Solo developers often can't spare the time to build an MVP and a vertical slice, and vertical slice wins the coin flip for most indies because the rest of the game is a repeat of its pattern.

Large studios often do both. They build a gray-box MVP first (to validate the structure), then a vertical slice (to establish the quality bar), then full production. This is expensive and only makes sense at scale. For you, pick one, and if you pick vertical slice, commit. It is the thing that forces you to actually finish something to shipping quality, which is the skill you most need to develop.

Scoping by Mechanics, Not by Content

Here is a trick that will save you hundreds of hours of wasted work: scope by mechanics, not by content.

A mechanic is a rule of interaction. Jumping. Shooting. Pushing blocks. Rewinding time. Talking to NPCs. Content is the stuff the mechanics operate on. Enemies. Levels. Puzzles. NPCs. Dialogue. Most beginner designers scope by content: "my game will have 30 levels and 50 enemies." This is a mistake. It measures scope in the wrong dimension. Every additional level costs level-design time. Every additional enemy costs art and AI and balance time. The marginal cost of each new piece of content is linear, often superlinear — because each piece of content needs to be playtested against every mechanic, every other content piece it can meet, every state the game can reach. Doubling content does not double work. It more than doubles it.

Scoping by mechanics works differently. You pick one deep mechanic — maybe two — and you build your entire game around exploring its variations. The content becomes a delivery mechanism for the mechanic, not the reverse. You do not need 50 enemies to make a great game. You need 5 enemies that interact with your core mechanic in 50 interesting ways.

Braid is one mechanic: time rewind. Every level, every puzzle, every chapter is a new variation on what time-rewind can mean. Rewinding normal time; rewinding only certain objects; worlds where time loops; worlds where time moves with your character. It is one mechanic explored exhaustively. The game is four hours long, won Game of the Year at IGF, and launched the entire indie explosion.

Baba Is You is one mechanic: you can push the words that make the rules, and doing so changes the rules. That is the entire game. Hundreds of puzzles exist because the developer found hundreds of implications of that one idea. He did not need to invent a new mechanic every ten levels. He just needed to find new angles on the one mechanic.

Celeste is one mechanic: the dash. Eight directions of dash, recharged when you touch the ground or a crystal. That is it. Every one of the 700+ rooms in the game is a variation on what the dash can do in different terrain. Springs, dash-refill berries, bubbles, wind, moving platforms — every piece of content is designed to exercise the dash in a new way. The dash is so deep that seven chapters of a shipped game, plus a DLC expansion with another eight chapters, did not exhaust it.

Downwell is one mechanic: you fall, and you shoot downward. Your gun is also your jump. The whole game fits in a tall vertical screen and lasts a few minutes per run, but it has infinite replayability because the shoot-down mechanic interacts differently with every enemy and every level generation.

The pattern: pick a mechanic. Make it deep. Build levels that explore it. Don't build levels and then design mechanics to fit — you will end up with ten shallow mechanics, none of which carries the game. One deep mechanic carries a game. Ten shallow ones carry nothing.

For your progressive project — the action-adventure you've been building — you already have mechanics from earlier chapters. Movement, combat, interactables, dialogue, upgrades. The question at scope-time is: which of these is my game actually about? Not which do I have — I have too many — but which is the one where the interesting variations live? Commit to that one. Let the others exist but be supporting. The game's spine is one mechanic explored deeply. The rest is scaffolding that lets players experience the spine in different contexts.

⚠️ Pitfall: Beginners add mechanics when they are worried the game is not interesting enough. This always makes the game less interesting, because now no single mechanic gets the attention it would have needed to become deep. If you are worried the game is not interesting, the answer is almost always to remove a mechanic and deepen what's left, not to add.

The Must-Have / Nice-to-Have / Cut List

The single most useful document in your project, after the design document itself, is the Must-Have / Nice-to-Have / Cut list. It is the living scope ledger. Every feature, every system, every piece of content lives somewhere on this list. Nothing gets built that is not on the list in some tier. Nothing gets promoted or demoted without a decision. When the project is in trouble, this document tells you what to do.

The list has three tiers, and each tier has a specific definition you must discipline yourself to honor.

Must-Have is the game does not ship without this. The core mechanic. The tutorial. The core loop. Enough content to be worth the asking price. A menu system. Save/load. Audio that doesn't crash. These are the ones where cutting means you no longer have a game. Be ruthless here. Most designers put too many things in Must-Have. If the game would still be a game without this feature — even a worse game — it is not Must-Have. It is Nice-to-Have.

Nice-to-Have is the game is better with this, and worse without it, but we can ship without it. New Game Plus. A photo mode. Additional difficulty modes. A boss rush mode. Extra cutscenes. Collectibles that affect nothing. Settings beyond the default. Additional languages beyond English. Controller rumble. These are the features you love and want, and they each add quality, but the game exists without them. Put everything plausible here, sorted by impact-per-effort.

Cut is not in this game. Ever. Completely cut. Not "cut for now." Not "maybe in a patch." Cut. Gone. You will not think about this feature anymore during development. If you cut a feature and you keep returning to it in your head, you have not actually cut it; you have just stalled it, and it is still costing you mental bandwidth. Cut means removed from consciousness.

Here is the discipline: every feature in the project should live in exactly one tier, and the tiers should follow the ratio of roughly 1 : 2 : 4 or worse. For every Must-Have, you should have two Nice-to-Haves. For every Nice-to-Have, you should have two to four things you already Cut. If your project has fifty Must-Haves and no Cuts, you have a dream document, not a scope document. You are not managing scope; you are pretending to.

Update the list weekly. At each update, ask three questions. Has anything in Must-Have been built? (if yes, mark done). Has the schedule slipped? (if yes, demote something from Must to Nice, or Nice to Cut). Has a new idea emerged that needs to go on the list? (if yes, place it, and be honest — new ideas almost always go in Nice-to-Have or straight to Cut; rarely are new ideas so important that they join Must-Have mid-project).

The hardest tier to administer is the Cut list. You will want to be gentle with your ideas. Don't be. Cutting is a mercy. A cut feature is a feature that does not ruin your schedule, does not absorb your team's energy, does not get half-built and shipped broken. A cut feature is a gift to the features that remain. Many designers find it useful to keep the Cut list visible — to look at it sometimes, like looking at photos of people you loved. But they do not build from it. The Cut list is closed.

🛠️ Practitioner Tip: When you cut a feature, write a one-sentence obituary for it in your design journal. "The grappling hook. September 2025. Cut because it broke the camera and tripled the animation budget, and without it the game is still a complete game. Loved, not built." Giving cuts a ceremony keeps them cut. Grief, not denial, is the healthy response to losing a feature.

Death by Feature

Every feature costs more than you think it costs. This is the second scope rule, after 3x.

The cost of a feature is not its implementation time. It is the sum of:

• Implementation time — building the thing.
• Integration time — making it work with every other system.
• Testing time — playing it, finding its bugs, tuning its edge cases.
• Balancing time — making sure it is neither too strong nor too weak.
• UI time — exposing it to the player in a clear way.
• Teaching time — writing tutorial or onboarding that introduces it.
• Documentation time — writing the internal notes so your teammates or future-you can maintain it.
• Art and audio time — every new feature usually needs its own visual and sonic vocabulary.
• Forever-maintenance time — every bug fix, every patch, every engine update, every expansion must respect this feature. You will never stop paying for it as long as the game is maintained.

A feature that takes two days to implement takes two weeks to integrate, test, balance, expose, teach, document, art-and-audio, and commit to maintaining. The implementation time is perhaps ten percent of the total cost. When a team member says "I can build that in a weekend," what they are proposing is actually ten weekends — but they are only seeing the first one.

This is why adding features is so much more expensive than it feels, and why cutting features saves so much more time than it feels like it should. Cutting a feature returns all of that cost to the project. Cutting two features returns more than twice as much, because the two features also would have interacted with each other, and each additional system multiplies the integration cost.

Star Citizen is the cautionary tale writ large. Cloud Imperium Games has been developing Star Citizen since 2012. It has raised over $700 million in crowdfunding, making it one of the best-funded entertainment projects in history. At the time of this writing, the game still has not released. The game kept growing: space combat, planetary flight, ground combat, FPS, mining, ship interiors, modular ships, player cargo, full MMO infrastructure, a separate single-player mode (Squadron 42). Each feature sounded reasonable in isolation. Each feature was fundable in isolation. The sum has been a project that is, institutionally, incapable of shipping, because its scope grows faster than its production. The most expensive lesson in game development history is still being paid, pledge by pledge, by its backers.

Anthem, BioWare's 2019 shared-world shooter, is the more tractable cautionary tale. Jason Schreier's long-form reporting on the project documented the scope chaos in detail: years of "vision changes" where the game was re-scoped during production, mechanics that were scoped in and then scoped out without any other mechanic replacing them, a core loop that was never stabilized. The game shipped, but as a pale version of what was promised, and EA pulled the revamp attempt ("Anthem NEXT") two years after launch. Unlike Star Citizen, Anthem did ship — but it shipped broken, because no one had been willing to cut features when the schedule demanded it. The features survived. The player experience did not.

The pattern in both: features feel like additions, so adding them feels like progress. But most of a feature's cost is invisible at the moment of addition. By the time the cost is visible, it has already been paid. The cheapest feature is the one you never start.

⚠️ Pitfall: The "it's just one more feature" moment is not a moment where you have chosen to add a feature. It is a moment where you have chosen to delay shipping. Every feature is a delay. Frame the choice that way — should we delay shipping for this? — and decisions come easier.

Scoping for Polish

Here is the rule nobody wants to hear: polish takes two to three times as long as construction.

This ratio varies — some features polish fast; some art passes drag on for months — but across a project the ratio holds. If it took you six months to build the game's core, plan for twelve to eighteen months to polish it. This is where the 3x rule meets reality. The implementation phase is 25% of the schedule. The polish phase is 50-75%. Shipping is the last thing that happens, and it takes the longest.

New designers underestimate this so catastrophically that their projects almost always die in the polish phase. They build the game, they can play through it, they think they are almost done — and then six months later they are still fixing bugs, and still tuning combat, and still re-drawing menus, and the joy is gone, and the project dies not from failure of ambition but from exhaustion.

The solution is to scope for polish from the start. When you are deciding what to include in the game, you should include only what you can afford to polish. If you cannot polish it, cut it. A half-polished feature is worse than no feature at all. An unpolished mechanic feels broken, which makes players distrust the game. An unpolished level feels cheap. An unpolished UI feels amateur. Every unpolished piece drags down the whole experience, because players judge by the weakest part, not the strongest.

This is the 80/20 rule applied to scope. Eighty percent of the polish effort goes into twenty percent of the features — the ones players interact with most, or the ones that set the quality bar. Your core mechanic, your opening hour, your main menu, your first boss fight. These need to be polished until they shine. The other eighty percent of the features can be adequate. But nothing can be broken or cheap-feeling.

To apply this: for each feature, estimate its polish budget alongside its construction budget. Build (two weeks) + Polish (four to six weeks). That is the feature's real cost. If you cannot afford both, you cannot afford the feature. Cut.

This will shrink your scope dramatically. That is the point. The scope you can ship polished is the scope you can ship. Everything else is the scope you wish you could ship and won't.

The Playable Prototype Milestone

A rule I've come to trust: by the end of the second week of any new project, you must have something playable.

Not something you can demonstrate on a slide. Not something where the character stands still. Something where a person — you — can pick up a controller or keyboard, press inputs, and have the game respond in some basic approximation of what the final game will do. A cube that moves. An arrow that shoots. A character that jumps on a platform. Something. You can put your hands on it and play it.

If you reach the end of week two and you do not have a playable thing, the project is already in trouble. Maybe not fatally, but the signals are bad. Two weeks is not a lot of time, but it is enough to get a prototype moving if the project is tractable. If you cannot get a prototype moving in two weeks, your scope is probably wrong, your tech stack is probably wrong, or both.

The two-week milestone is a diagnostic. It tests whether your project idea can survive contact with reality. A lot of beautiful ideas disintegrate in the first two weeks because the tools do not do what you assumed, the mechanic is harder than you thought, the asset pipeline is unforgiving. Discovering this at week two is a gift. Discovering it at week thirty is a tragedy. The cheap way to fail is early. The expensive way is late.

Once you have the playable prototype, your development becomes sustainable. You can iterate on something real. You can playtest. You can answer the question "does this feel good?" with data instead of speculation. You can invite friends to try it. You can post a gif on social media. The project becomes visible to itself. It starts to have momentum.

Before the prototype, the project is speculation. After, it is production. Never confuse the two phases, and never spend more than two weeks in the pre-prototype phase without stopping to ask what is wrong.

🛠️ Practitioner Tip: On day one of a new project, open the engine and get something moving on screen by end of day. Not the right thing. Just something. A cube. A sprite. A dot. You are establishing that the pipeline works and that you can make things happen. Everything else follows from that. If you spend day one in planning documents, you will spend week one in planning documents, and you will not have the playable prototype at week two.

Scope Creep and How to Resist It

Scope creep is the gradual, almost imperceptible growth of scope during development. Unlike the dream-game fallacy, which is about how big the game is when you start, scope creep is about how much bigger it gets as you go. It is insidious because it happens feature by feature, and each feature seems small.

Scope creep has several sources, each requiring its own defense.

Self-creep. You, the designer, keep thinking of new ideas. Most designers do. You have taste, you are playing other games, you are inspired constantly. Every week there is a new idea that would be so cool in the game. The temptation to build it is enormous — the idea is fresh, the enthusiasm is high, the opportunity cost feels low. ("I can build this in a weekend.") Defense: write the idea in a "for next game" notebook. Do not put it in this game. The notebook exists so you can save the idea without implementing it. Ideas in notebooks do not cost scope. Ideas in engines do.

Team-creep. Collaborators have ideas too. Artists want to add a new animation set. Programmers want to refactor the combat system "while we're in there." Designers want to add a new mechanic. All of these feel like contributions. They are all, technically, new features. Defense: run every new proposal through the Must-Have / Nice-to-Have / Cut list. Does it make the list? If so, where? If it makes Must-Have, why? What gets demoted from Must-Have to make room? The exercise prevents creep because it forces conscious accounting.

Publisher- or investor-creep. If you have a publisher, they will have ideas. If you have investors, they will have feedback. Some of it will be genuinely useful. Much of it will be "have you considered adding multiplayer?" — which is the single most destructive suggestion in the history of games, because it tends to triple your scope overnight for a feature you have no time to make good. Defense: treat external suggestions exactly like internal ones. They get the same list-based accounting. "Great idea, let me check whether we can fit it — what would we cut to make room?" puts the ball back in the requester's court. They will rarely have an answer, which is often the right outcome.

Playtester-creep. When you playtest, players will tell you things they wish the game had. Most of these are not creep — they are valid feedback about what the game needs to work. But some are aspirational: "I love it, and I think it would be even better if you added X." X is a new feature. It is creep. Defense: distinguish between "the game is not working, X would make it work" (respond to this) and "the game is working, X would make it even better" (don't respond to this; X goes on the Nice-to-Have list at best, and probably doesn't).

"Wouldn't it be cool if..." creep. This is the most socially insidious form. A team member says "wouldn't it be cool if the boss had a second phase where he grows wings and summons a storm?" The room lights up. Everyone wants to build that. Defense: the Must-Have / Nice-to-Have / Cut list. "Cool" is not a tier. Cool is a sensibility that should shape the tiers, not a justification that skips them. If the storm phase is Must-Have, fine — what does it replace? If it's Nice-to-Have, write it down. If it won't get built, say "cool idea, not in this one." The team may be disappointed, but disappointment is survivable. Unshipped games are not.

The discipline of saying no is the designer's most important skill in the later stages of production. You will say no to yourself, to collaborators, to outside voices, to players, to your own taste. You will say no to ideas you think are good. This is not a failure of creativity; it is the expression of creativity. Every "no" protects the game that is being built. The shipped game is the intersection of the ideas you had and the ideas you defended from cuts. It is not the union of all ideas. It cannot be.

Cutting Your Darlings

Stephen King, in his memoir On Writing, gives the famous advice: kill your darlings. He meant that the passages of a book a writer loves most — the beautiful sentence, the elaborate metaphor, the scene they've been waiting to write for years — are often the passages that serve the book least. They are the writer's indulgence, not the reader's need. Cutting them is painful and usually correct.

Game design has its own version, and it is brutal. The feature you love most is often the feature you need to cut. Not always; sometimes your darling is the soul of the game and must be defended. But surprisingly often, the feature you are most precious about is the one that is slowing everything else down, distorting the rest of the design, and introducing bugs that would not exist without it. The fact that you love it does not exempt it from analysis. If anything, your love for it should increase your suspicion — because the thing you most want to be in the game is the thing you are least able to evaluate objectively.

Case examples from shipped games, documented in postmortems and developer retrospectives:

BioShock 2 originally had a multiplayer saga — a narrative-driven multiplayer component where players would experience alternate perspectives on the Rapture civil war. Large portions of the team were excited about it. It was, internally, considered the "bold" feature of the game. During production, the multiplayer was cut from the single-player team and given to an external studio, and eventually most of the ambition was pared back to a more conventional competitive multiplayer mode — which shipped, was fine, and was mostly forgotten. The cut of the narrative saga was painful but correct. The remaining single-player campaign was stronger for the scope retrieval.

Final Fantasy XV famously cut major story chapters during production. Director Hajime Tabata's team reworked the game multiple times across its decade-long development. What shipped in 2016 was significantly smaller than what had been designed; the missing pieces were distributed later as paid DLC chapters. The cuts are debated to this day — many players felt the story had holes — but Tabata has been clear in interviews that without the cuts, the game would not have shipped. The tradeoff was an incomplete story that existed versus a complete story that didn't.

Duke Nukem Forever is the anti-case. 3D Realms spent fifteen years unable to cut anything. Every time the engine was upgraded, they rewrote the game to fit the new engine. Every cool feature that came out in a competitor's game, they tried to add. The game finally shipped in 2011 after the studio collapsed and the IP was transferred to Gearbox, and it shipped to brutal reviews, in part because the fifteen years of indecision were visible in the final product. No darlings were ever cut. The project died of its inability to cut.

Stardew Valley, on the other end, is a game where a solo developer — ConcernedApe — actually did cut his darlings repeatedly over four years of development. Features came in and went out. Systems were tried and abandoned. The final shipped game is enormous, but the designed game was larger still, and the cuts were what let it ship. He has discussed this in interviews: the scope of the final game is half of the scope he originally planned.

The pattern: shipped games have cut darlings. Unshipped games have not. The correlation is strong enough to be called causal.

When cutting a darling, be honest about why. "I love this feature" is not a reason to keep it; it is a reason to suspect your judgment about it. Ask a collaborator — someone you trust who will tell you the truth — whether the feature is pulling its weight. If they hesitate, it probably isn't. Cut. Feel the grief. Build the next thing. The game will be stronger.

Re-Scoping Mid-Project

Sometimes you start a project with good scope, and by month six you realize the scope is wrong. Maybe it was wrong from the start and you couldn't see it; maybe it was right at the start but circumstances changed (a teammate leaving, a technical dead-end, a market shift); maybe the game turned out to be bigger than you thought once you got into it. Re-scoping mid-project is normal. Refusing to re-scope is how projects die.

The signals that you need to re-scope are not subtle if you look for them.

Milestones are slipping repeatedly. Not once — that can be normal variance. But if every milestone is missed by 30-50%, the schedule is not wrong, the scope is. The project is not capable of delivering at the rate you planned.

Morale is dropping. People who were excited in month one are tired in month six. This is partly normal — everything gets old — but persistent and increasing morale drops often signal that the scope has outgrown what the team can imagine completing. The team is losing faith that the project will ever ship, and their output is reflecting that despair.

"Just this one more feature" is happening repeatedly. You notice that every week, someone (maybe you) is pushing another feature in. Not adding one-off; adding steadily. That is creep in action.

You have stopped playtesting. Nobody is playing the build because it is too broken, too unfinished, too unstable to show anyone. Playtests have slipped out of the schedule. This is a sign the project has grown beyond your team's capacity to maintain a playable state.

You cannot imagine the final product. You used to have a clear vision of what the shipped game would look like. Now you don't. The scope has grown so much that the game's identity has become unclear.

When these signals show up, you hold a re-scoping meeting. This is not a feature meeting. This is a meeting where you look at the Must-Have / Nice-to-Have / Cut list and you make hard decisions. You demote. You cut. You restructure. You may need to change the ship date. You may need to cut a major feature. You may need to accept that the game is smaller than you originally imagined. All of these are preferable to the alternative, which is not shipping.

No Man's Sky is the instructive example of late re-scoping — specifically, of not re-scoping enough before launch. Hello Games spent years building a procedurally-generated universe of enormous ambition. As launch approached, Sean Murray had publicly promised more features than the team could actually ship. Rather than delay the launch aggressively and re-scope publicly, the team shipped the game on schedule, and the game's launch scope was a bitter disappointment to players who had been promised more. The post-launch recovery — eight years of free updates — eventually delivered most of what had been promised, but the launch reputation never fully healed. The correct move was a longer delay, paired with public re-scoping, admitting that some promises could not be kept. Hello Games did not do this. They should have. It is a textbook example of when re-scoping, publicly and painfully, would have been cheaper than shipping and recovering.

Contrast this with Hollow Knight — the subject of Case Study 37.1 — whose team re-scoped upward in a deliberate, careful way across two Kickstarter delays. Team Cherry decided during production that the game was going to be bigger than they had promised, they delayed accordingly, they communicated with backers, and they shipped a tripled-scope game to acclaim. The scope grew, but the re-scoping was conscious, not default. Every new area was a choice. Every boss was a choice. The process was still painful, but it was not chaotic.

Re-scoping is a tool, not a failure. Used early and honestly, it saves projects. Avoided, it kills them.

Honest Timelines for Game Types

Let me give you numbers — real numbers, based on what shipped games actually took. These are not aspirational. These are sobering. If your plan is shorter than the number listed, you are not on the short end of variance; you are underestimating.

Hobbyist first game, evenings and weekends. Three to six months for a very small game — a game jam project extended. Think 30 minutes of content, one mechanic, no narrative. VVVVVV, Terry Cavanagh's breakout, was made in the evenings over a few months and has perhaps two hours of content. That is a realistic floor. If your first game is something more ambitious than this, plan a year minimum of evenings, and know that most hobbyist first games never finish.

Indie full-time solo. One to three years for a first indie game of meaningful scope. Stardew Valley: four years (and ConcernedApe was learning to code as he went, so adjust). Celeste began as a four-day game jam and was expanded to full release over two years. Braid: three and a half years. Spelunky (original freeware version): one year, solo, with much less polish than the later remake. Undertale: about two and a half years. The pattern: a solo developer making a full game, even a small one, takes between one and four years. Anything faster is either a jam-size game or a sequel to a mature codebase.

Indie team of 3-5, full time. Two to four years for their first game. Hollow Knight: approximately three years from Kickstarter to launch, and the team had been working on it prior. Ori and the Blind Forest (Moon Studios, a small distributed team): about four years. Dead Cells (Motion Twin, a small co-op studio): about three years with two years of active Early Access. Hades (Supergiant, a veteran small team): two years in Early Access on a mature engine. A small team working full time and reasonably coordinated can ship a meaningful game in about three years. Less than that requires unusual circumstances (mature tech, prior prototypes, a very tight scope).

AA studio, 20-50 people. Three to five years for a full project. Spiritfarer (Thunder Lotus, a small-to-mid studio): about four years. Cuphead (StudioMDHR): seven years, because its hand-animated art was extreme. A Plague Tale: Innocence (Asobo Studio, AA-scale): about three years. Hi-Fi Rush (Tango Gameworks, AA team inside a AAA structure): about four years. AA studios have scale to deliver higher production values, but they also carry more process overhead and more coordination cost.

AAA studio, 100-500+ people. Five to seven years, often more. The Witcher 3: about three and a half years of production (with pre-production and prototype periods extending it further). Cyberpunk 2077: more than six years. Red Dead Redemption 2: approximately eight years. Elden Ring: about five years of active development. Horizon Zero Dawn: about six years. Assassin's Creed Valhalla: about two and a half years, but leveraging a mature engine and pipeline. AAA development has gotten longer, not shorter, as fidelity expectations have risen. The five-year baseline is normal.

If your team is smaller and your game is as ambitious as any of these, you are underestimating. Period. Make the game smaller than what a similarly-sized team has shipped; those teams also had advantages you probably don't. Every commercial game is cheating in some way — leveraging prior tech, prior skill, prior team, prior IP, prior funding. Your first game has none of those cheats. Budget more time.

The "One Game a Year" Philosophy

There is a counter-movement to dream-game scoping, and it has saved many designers' careers. Call it the one game a year philosophy, after Daniel Cook's old Lostgarden blog posts, the Ludum Dare community, and the broader game-jam culture that values finishing over grandeur.

The philosophy says: finish small games frequently. Do not build one massive unfinished game. Build five small finished games. The finishing is the skill; the finishing is the education; the finishing is what makes you a designer. Most of the value in making a game is in the last 20% — the debugging, the polishing, the shipping, the responding to feedback. If you never reach the last 20%, you never develop the skills that last 20% requires. A designer who has shipped five small games has skills a designer who has half-built one big game does not have, no matter how impressive the half-built big game looks.

Terry Cavanagh is the poster child. VVVVVV (2010), At a Distance (2011), Super Hexagon (2012), Don't Look Back (old flash game), plus Ludum Dare submissions, plus the Dicey Dungeons development (2019), plus uncounted experiments. He ships. He has been shipping for fifteen years. He is, by almost any measure, one of the most successful solo indie developers of the past two decades. The secret is not that Super Hexagon is a masterpiece (though it is); it is that he shipped it, and then he shipped the next thing, and then the next. The shipped catalog compounds into a career.

Compare this to the many-years-in-hiding developer who is working on the Big Project. The Big Project may be genuinely great. It may even eventually ship and succeed. But across a thousand Big Project developers, the success rate is low. The cumulative output of the ship-five-small-games developer is higher, in both total output and in career resilience.

For a first-time designer trying to figure out what scope to target, the one-game-a-year philosophy suggests a stark answer: make the game you can finish in a year, not the game you would most love to make. Because the game you can finish in a year will ship. The game you would most love to make probably will not.

This does not mean you never build the dream game. It means you build it later, when you have the skills of ten shipped games behind you, and when the dream game is less dream and more plan. The designers who ship the big games almost always started with small games. Derek Yu (Spelunky) started with small freeware. ConcernedApe (Stardew Valley) started with modest hobby projects. Toby Fox (Undertale) started with music and mods. Phil Fish (FEZ) started with jams. There is a pattern. Big games come after small games, not before them.

Game jams are the training ground. A 48-hour jam teaches you more about scope than a six-month project does, because at 48 hours you cannot lie to yourself about what scope you can hit. You have 48 hours. If it doesn't fit, it doesn't fit. You cut ruthlessly because you have to. The habits of ruthless cutting you develop in jams — the reflex to trim, to simplify, to ship — transfer to your longer projects. Designers who come up through jam culture are almost universally better at scoping than designers who don't.

🛠️ Practitioner Tip: Do Ludum Dare. Or Global Game Jam. Or any 48-hour jam. Do one at least once a year, even after you are making "real" games. The jam rhythm is the rhythm of shipping, compressed. It keeps the shipping muscle warm.

Scope and Your Progressive Project

You've been building a 2D action-adventure game in Godot across thirty-six chapters of this book. Movement in Chapter 3. Core loop in Chapter 6. Juice in Chapter 8. Emergence in Chapter 9. Difficulty and assist mode in Chapter 11. Levels in Chapter 17. Dialogue and NPCs in Chapter 21. Cutscenes in Chapter 23. Economy in Chapter 24. Combat and bosses in Chapter 26. AI in Chapter 27. UI in Chapter 29. Audio in Chapter 30. Playtesting in Chapter 31. Balancing in Chapter 32.

That is a lot. By the strict accounting of this chapter, that is probably more than you actually built to shippable quality. If you built everything in the progressive-project spec to a shippable bar, you have produced something close to a commercial indie game, which would mean you are at month 18-36 of development if you worked full time. If you are doing this alongside a job, you are probably somewhere in the middle — some systems working well, some half-built, some skipped, some built but unpolished.

That is fine. The progressive project is a learning exercise, not a commercial product. But now we reach the chapter where we scope for shipping, which means we take an honest look at what we have and decide what to ship.

Here's the exercise. Open your project. Actually open it. Play it, end to end, right now. Write down what you see. Then answer these questions honestly.

1. What is unambiguously working? The movement feels right. The combat is at least functional. One boss is actually fun. A specific level reads well. List what is good.

2. What is kind of working but not polished? Dialogue exists but reads awkwardly. UI exists but is clumsy. The shop exists but the item icons are placeholder. List what is there but weak.

3. What is half-built or broken? The second boss has a bug where it gets stuck. The cutscene triggers unreliably. The save system loses state sometimes. The assist mode doesn't actually change difficulty meaningfully. List what is unstable.

4. What is missing from the spec? The spec called for environmental storytelling in every level; you only did it in one. The spec called for a third NPC; you only have two. The spec called for a boss rush mode; you never started it. List what is not there.

5. If you had to ship this in 30 days, what would you cut? Not what you want to cut — what you could survive cutting while still having a complete game. The second boss, if broken, might be better cut than shipped broken. The third NPC might be cut. The boss rush mode stays cut. The cutscene system might be reduced to a single cutscene instead of three. List what you would cut.

6. If you had to ship this in 30 days, what would you polish? The top one or two things from list #1 that deserve another pass. The single most common UI screen that players see. The core combat loop. List what you would polish.

7. If you had to ship this in 30 days, what could you leave as-is? Most of the game. Most things are fine at current state. If you try to polish everything, you won't polish anything. List what you could live with.

This is the scope audit. It is the skill this chapter is teaching. It is the skill you will use on every game you ever make. It is honestly the single most practical scope exercise you will do in this book.

Progressive Project Update — Chapter 37: Scope Audit and Cut List

Formally, for this chapter, produce three documents and store them in your project repository.

Document 1: The Scope Audit Sheet. A spreadsheet (or text file) with every feature, every system, every piece of content in your current project. For each, mark:

• Status: Complete / In Progress / Broken / Not Started
• Polish Level: Shippable / Rough / Placeholder
• Time to Ship-Quality: Days/weeks required to bring to shippable polish, honestly estimated

Count: how many features are shippable? How many are not? What would the total polish-time be to get everything to shippable? (If that number is more than three months, you are overscoped.)

Document 2: The Must-Have / Nice-to-Have / Cut List. Apply the framework from this chapter to your actual project. List everything. Put each item in exactly one tier. Justify every Must-Have (one sentence: why does the game not ship without this?). Justify every Cut (one sentence: why is the game okay without this?). The Nice-to-Have tier can be unjustified; its items just wait their turn or get cut later.

Document 3: The Ship-in-30-Days Plan. Imagine you have 30 days from today to ship something playable to itch.io. What is the minimum version of your game you could ship? Write it out, feature by feature, level by level, and give each piece an estimated polish-time. If the total is more than 30 days of work, cut more. Repeat until you have a plan that fits in 30 days. This plan should not be the game you want to ship. It should be the game you could ship, given real time constraints. You may not actually ship in 30 days — that's fine — but the exercise clarifies what the actual shippable version looks like.

Commit all three documents to your repository. When you reach Chapter 40 (the capstone), you will revisit them and compare them to what you actually shipped. The comparison will teach you more about scope than any chapter of any textbook can.

Common Pitfalls

A short list of the ways scope discipline breaks down in practice, drawn from watching many first-time games succeed and fail.

Perfectionism. The designer cannot leave a feature alone. They keep polishing the first level while ten more remain unbuilt. The result is that level one is perfect and nothing else exists. Cure: commit to a rough pass across the whole game before polishing any piece. Polish is the last phase, not the only phase.

Feature creep disguised as iteration. The designer tells themselves they are iterating on existing features, but what they are actually doing is adding new ones. Iteration refines what exists; creep adds what doesn't. Cure: track your changelog. If every week's entries say "added X," you are creeping. If they say "refined X, fixed Y, balanced Z," you are iterating.

Cutting too late. The team knows they are overscoped but keeps hoping they can finish it all. Cuts are deferred until the last possible moment, at which point the cuts are emergency cuts, rushed and painful. Cure: cut early, cut regularly. Each monthly scope review should cut something. If a month passes without cuts, the project is creeping.

Confusing scope with quality. "Cutting scope" feels like "making the game worse." It is not. Scope is what the game contains. Quality is how well it delivers what it contains. A smaller, more polished game is higher-quality than a larger, sloppy one. Cutting scope usually increases quality, because it returns time to the remaining features.

Treating polish as optional. This is the killer. "We'll polish later" means "we'll never polish." Polish has to be scheduled, budgeted, and protected. If polish is what you do after everything else is done, you will not polish, because everything else is never done.

Measuring scope in content when you should measure in mechanics. Beginners describe their scope as "ten levels and five bosses." A better description is "one mechanic, explored across ten levels with five bosses." The first framing invites adding levels and bosses. The second framing invites deepening the mechanic.

Summary

Scope is the constraint that makes games possible. Every game that has ever shipped has shipped because its scope was compatible with the time, money, and team available. Every game that has not shipped has failed that compatibility in some way. You are not exempt from the pattern. Your first game will be bad — if you ship it. If you do not ship it, you will not know whether it would have been bad, because it will never have met a player.

The disciplines:

• Understand that scope is three-dimensional (content, systems, polish) and that expanding any one of them costs time.
• Apply the 3x rule: everything takes three times longer than you think.
• Build a vertical slice early. If the slice is not fun, the game will not be fun.
• Scope by mechanics, not by content. One deep mechanic beats ten shallow ones.
• Maintain a living Must-Have / Nice-to-Have / Cut list, and cut regularly.
• Remember that every feature carries forever-maintenance cost, not just implementation cost.
• Budget polish at 2-3x implementation time, or the polish won't happen.
• Reach a playable prototype by week two, or the project is at risk.
• Resist scope creep from all sources — yourself, your team, your stakeholders, your playtesters.
• Cut your darlings when they are slowing the project, even when you love them.
• Re-scope mid-project when signals say so. Re-scoping is a tool, not a failure.
• Use honest timelines: solo indies ship in 1-3 years, small teams in 2-4, AAA in 5-7. Plan for reality.
• Ship small. Ship often. Finish games. Your shipped catalog is your career.

The next chapter, on publishing and marketing, will ask you to actually put your game in front of players. Everything about that process — the Steam or itch.io page, the trailer, the pitch — assumes you have a game to ship. The scope discipline in this chapter is what makes that assumption true. Without scope discipline, Chapter 38 is irrelevant to you, because the game it wants to market does not exist.

Your first game will be bad. Ship it anyway. The bad first game is the foundation of the good second game. The designer who has shipped, even once, is a different designer than the one who has not. Cross that threshold. Cut what you have to. Save what you must. Ship.