Chapter 37 — Exercises

Four exercises, organized by rising difficulty. The first is an audit of your own project. The second is comparative — you analyze scope decisions in shipped and cancelled games. The third is the shippable-in-30-days writing exercise, which is the hardest thing in this chapter because it forces commitment. The fourth is a critical-ethics exercise about when scope ambition crosses into fraud. Budget 12-18 hours total. Do them in order.

Exercise 37.1 — Audit: Scope Audit of a Game You Are Planning

This is the big one. Complete this exercise even if you skip the others.

Pick a game you are currently planning or actively building. Not a dream game. A real project. If your progressive project is that game, use it. If you have a different project going, use that. If you are between projects, use the most recent one you actually worked on.

Open a spreadsheet. You will be here for a while.

Step 1: Enumerate everything. Go through your design documents, your feature backlog, your commit history, your sketches, and your head, and write down every feature the game has or wants to have. Not a category like "combat" — every specific feature. The attack mechanic. Each weapon. Each enemy type. Each boss. Each level. Each UI screen. Each audio track. The save system. The options menu. Each accessibility feature. Each localization. Each cutscene. Each piece of dialogue branch. Each NPC. Each unlock. Each achievement. Everything.

For most projects this list is between 80 and 300 items long. If yours is shorter than 50, you are missing things; go back. If it is longer than 500, you have a serious scope problem (which this exercise will help you confront).

Step 2: Rate each item on four axes.

  • Status. Done / In Progress / Stub / Not Started.
  • Polish Level (if built). Shippable / Rough / Placeholder. (Skip if not built.)
  • Estimated time to ship-quality. In days. Be honest — use the 3x rule. If you think something will take a day, write three days.
  • Tier (you decide now). Must-Have / Nice-to-Have / Cut.

Go through the list and fill in all four columns for every item. This will take several hours. Do not rush it. The honesty of this exercise is where the value lives, and the honesty is hard to sustain for 300 items in a row. Take breaks.

Step 3: Sum the time. Add up the "time to ship-quality" column, but only for items tagged Must-Have or Nice-to-Have. The Cut items don't count; you are not building them. Cut items are free.

What is the total? Is it a number you can deliver, given your real available hours per week and your target ship date?

If yes: your scope is probably okay, though continue with step 4 anyway as a sanity check.

If no — if the total polish-time exceeds what you have available — you are overscoped. Proceed to step 4.

Step 4: Rebalance. You need to move items from Must-Have to Nice-to-Have, or from Nice-to-Have to Cut, until the total Must-Have + Nice-to-Have polish time is achievable in your available hours. Be ruthless. Every move you make is a feature you will not ship as planned, and that is how projects ship.

When you rebalance, apply the rules:

  • Every Must-Have must justify itself with one sentence: the game does not ship without this because ___. If you cannot complete that sentence, demote to Nice-to-Have.
  • Every Cut is final. You are not promising to add it back later. Say goodbye.

Keep rebalancing until the numbers work. This may require two or three passes. Your first rebalance will probably be too gentle; you will still be overscoped afterward. Do it again.

Step 5: The final audit document. The deliverable is your final scope audit spreadsheet, with a summary at the top showing:

  • Total items
  • Must-Have count + total polish-time
  • Nice-to-Have count + total polish-time
  • Cut count
  • Your available hours per week × weeks to ship
  • The delta between available and required

The delta should be zero or positive. If it is negative, you still have work to do.

Reflection (300-500 words). Write a short reflection on what you learned. Which items did you most resist cutting? What does that resistance tell you about your attachment to this project? Which items, when you finally cut them, were a relief? What does that tell you? What would you do differently on your next project's scope, knowing what this exercise revealed?

Submit: the scope audit spreadsheet + reflection.

Why this exercise matters. The scope audit is not an abstract exercise; it is the actual deliverable that determines whether your game ships. Every professional studio does some version of this — sometimes formally, sometimes as a chaotic meeting room full of sticky notes, but always, always, before a project ships. Doing it yourself, for your own project, lets you experience the specific discomfort of cutting things you love, which is the skill the chapter is teaching. It cannot be taught by reading. It can only be taught by doing. So do it.

Exercise 37.2 — Analysis: Four Postmortems

Pick four postmortems to read or watch — two from games that shipped, two from games that were cancelled. Your goal is to identify the scope decisions that differed between "shipped" and "cancelled."

Good options for shipped-game postmortems:

  • Celeste — Matt Thorson's GDC talks and blog posts on scope and cut features.
  • Hollow Knight — Team Cherry's retrospective on the scope expansion and delayed launch.
  • Stardew Valley — ConcernedApe's extensive interviews on solo scope.
  • Hades — Supergiant's Early Access scoping and live-development approach.
  • Into the Breach — Subset Games' "scope down, depth up" philosophy.
  • Undertale — Toby Fox's interviews on scope choices in the music and narrative.

Good options for cancelled-game postmortems:

  • StarCraft Ghost — the Blizzard console shooter that was cancelled after years of work.
  • Prey 2 (Human Head) — cancelled after scope chaos at Bethesda.
  • Silent Hills (Kojima/del Toro/Konami) — cancelled after the P.T. demo.
  • Anthem NEXT — the cancelled revamp of a shipped-but-broken game (technically a post-launch scope decision).
  • Scalebound — Platinum Games' cancelled Xbox One game.
  • Duke Nukem Forever (the fifteen-year development, since it effectively died and was revived).
  • Star Citizen (a work-in-progress that may or may not ever ship — a perpetual cautionary tale).

Pick any four (two shipped, two cancelled). For each, read what is publicly available — postmortems, GDC talks, Jason Schreier articles, developer interviews, Kotaku reporting, dev-blog retrospectives. Spend 45-90 minutes per game.

For each game, answer in a short writeup (200-300 words):

  • What was the original scope?
  • What was the final scope (or, if cancelled, the scope at time of cancellation)?
  • What were the scope decisions that most affected the outcome — cuts that saved the project, additions that destabilized it, re-scopes that came too late or too early?
  • What was the relationship between scope and the final outcome? Did the project ship because of, or despite, its scope decisions?

Then write a fifth comparative section (500-700 words):

  • What patterns distinguish the shipped games from the cancelled ones?
  • Do the shipped games share a scope philosophy? Do the cancelled games share a failure mode?
  • What would you do differently in your own project as a result of this comparison?
  • Are there any cases where you think the shipped game was over-cut (it shipped but lost something important) or the cancelled game had a defensible scope (it was going to be great, if only it had shipped)?

Submit: the five-part analysis (1,300-1,900 words total).

Why this exercise matters. Every project you work on will include people who have strong opinions about scope. Some will be right. Some will be wrong. Your ability to evaluate scope arguments depends on your pattern-recognition across many projects, not just the one in front of you. Reading postmortems builds that pattern recognition. Watching shipped-vs-cancelled pairs builds it faster, because the comparison is explicit. Do this exercise, and every future scope conversation you have will be informed by the fifty or a hundred case studies you've internalized.

Exercise 37.3 — Practical: The Ship-in-30-Days Plan

This is the hardest exercise, and its difficulty is not technical — it is emotional. You will write a plan that sacrifices most of what you want your game to be.

Imagine you have been told, by a publisher, a partner, a personal-finance emergency, or your own health, that your current game project must ship in 30 days. Not 30 days of ideal focused work — 30 days of calendar time, including whatever else is in your life. You will ship whatever you can ship in 30 days.

Write the ship-in-30-days plan in exactly 200 words.

Structure (approximate):

  • Opening sentence: What the game now is. In a single sentence, describe the cut-down version of your game. What is it about? How long is it? What is the one thing it does well?
  • Two sentences: What is in. The Must-Have features, in compressed form. The core mechanic, the core content, the minimum UI.
  • Two sentences: What is cut. Everything else. The features you loved, the systems you built, the content you designed — all cut. Name them specifically. The grief is the point.
  • Two sentences: Why it can still be good. Argue, honestly, that the 30-day version is still a defensible game. Not a complete vision, but a real thing.
  • Closing sentence: How you feel about shipping this. Be honest. Excited? Sick? Resigned? Relieved? The emotion is data about your project.

Keep it to 200 words. The constraint is deliberate. In real shipping decisions, you will not get to write a thousand-word justification; you will get three sentences in a project meeting. Practice the compression.

Now — and this is the exercise's second part — answer two follow-up questions (150 words each):

  1. Would shipping this be worth doing? If the publisher-partner-emergency were real and you had to actually ship this 30-day version, would it be the right call? Or would the cut version be so much worse than the full version that you would rather delay / cancel / walk away?

  2. What does this exercise tell you about your actual project? The 200-word plan is a fiction — but your real project is going to face compressed versions of this same decision. Which features of the 30-day plan should probably be the actual plan, because they are the defensible core? Which of the "cut" features are ones you should cut, in real life, even if you are not literally shipping in 30 days?

Submit: the 200-word plan + two follow-up answers.

Why this exercise matters. Many designers cannot imagine their game in any form smaller than its dream-spec version. This inability is itself a scope failure — the designer has lost track of what the game's core is. The 30-day exercise is a forcing function. It asks: if you had to pick one thing to keep, what would it be? Designers who can answer that question quickly and honestly ship games. Designers who cannot do not. This exercise builds the skill by practicing it directly.

Exercise 37.4 — Critical: The Star Citizen Question

This exercise is a writing prompt. It has no right answer. It is here to sharpen your thinking about the ethics of scope.

Star Citizen has raised over $700 million in crowdfunding since 2012. As of this writing in 2026, the game has not fully released, though parts of it have been playable in perpetual alpha for years. Many features that were originally promised in the Kickstarter are still not delivered. Chris Roberts and Cloud Imperium Games have repeatedly expanded the scope rather than cut to ship. Some backers have funded the project with thousands of dollars. Some of those backers are happy; some are furious; some have died while waiting. The game may ship eventually. It may never ship. The legal question of whether CIG has fulfilled its obligations is contested.

Write a 1,200-1,500 word essay addressing some or all of the following:

  • At what point does an expanded scope become a broken promise? Is it when the original promise is no longer deliverable at all, or earlier, or later?
  • Is Star Citizen's situation a failure of scope management, a success of ongoing funding, both, or neither?
  • How does the distinction between "not yet delivered" and "never delivered" affect your judgment? A game that takes 15 years to ship is a very different ethical case than a game that never ships.
  • How should a designer who is taking crowdfunding money think about their scope obligations? Is there a professional ethics of scope?
  • Compare Star Citizen to Hollow Knight. Team Cherry expanded their Kickstarter scope significantly, delayed accordingly, and shipped a game that tripled the promised content. Why did that work where Star Citizen seems not to be working? Is the difference about scope discipline, honesty, communication, team size, funding structure, or something else?
  • What is your own ethical stance, as a designer, on taking money for a game whose scope might grow beyond what you can deliver?

You do not need to answer every sub-question. Pick the threads that matter to you and develop them. Quote specific facts from the public record where possible — there are many articles, CitizenCon talks, and Kotaku reports on the state of the project.

Submit: the essay (1,200-1,500 words).

Why this exercise matters. Scope is usually taught as a production problem: how do I manage it? It is also an ethical problem: what do I owe the people who gave me money or attention? Crowdfunding, Early Access, Kickstarter, patronage — all of these put the designer in a relationship with backers that includes a scope promise. When the scope expands or contracts, the promise is renegotiated, often without the backer's consent. Designers who have not thought about this carefully end up in trouble. Designers who have thought about it develop an ethics of production that keeps them honest. This essay is where that thinking starts. If you ever take money for a game, you will need the answers this essay makes you work out.

Exercise Completion Checklist

  • [ ] 37.1 — Scope audit spreadsheet + reflection
  • [ ] 37.2 — Four-game comparative analysis
  • [ ] 37.3 — 200-word ship-in-30-days plan + follow-ups
  • [ ] 37.4 — Star Citizen ethics essay

Keep these deliverables. Chapter 40 (the capstone) will ask you to revisit them, and they become part of your final portfolio. A designer whose portfolio shows they have done real scope work is a designer studios hire, because scope discipline is one of the rarest and most valuable skills in the field.