Chapter 37 — Quiz

Fourteen questions testing your grasp of scope management, the rule of 3x, vertical slices, feature cost, and the Must-Have / Nice-to-Have / Cut discipline. Answer before checking the answer key at the bottom.

Questions

1. The chapter describes the first-time designer's most common error as the dream-game fallacy. What is the dream-game fallacy?

a) Designing a game whose mechanics you have never prototyped. b) Imagining the shipped result without budgeting the labor that produces it. c) Targeting a genre you have not played extensively. d) Using engines you do not yet understand.

2. The chapter identifies three dimensions of scope. Which of these is NOT one of them?

a) Content volume. b) System depth. c) Polish bar. d) Marketing budget.

3. The "Rule of 3x" states that:

a) You should ship three games before trying a large project. b) Everything takes approximately three times longer than you initially estimate. c) A team of three is the optimal indie team size. d) You need three milestones before cutting any feature.

4. A vertical slice is:

a) A short playable demo produced for marketing purposes. b) A narrow but polished piece of the game at final shippable quality. c) A document describing the full scope of the game. d) The minimum viable product with placeholder art.

5. The chapter distinguishes a vertical slice from an MVP. An MVP proves which of these?

a) The moment-to-moment feel of the game is good. b) The art direction reads correctly. c) The overall structure of the game holds together end-to-end. d) The engine can handle the final feature list.

6. Which of the following games is cited as an example of scoping by one deep mechanic explored exhaustively?

a) The Witcher 3. b) Grand Theft Auto V. c) Baba Is You. d) Starfield.

7. In the Must-Have / Nice-to-Have / Cut framework, what is the correct definition of Must-Have?

a) A feature the designer would most enjoy playing. b) A feature that the game cannot ship without. c) A feature that is already implemented. d) A feature that was in the original design document.

8. The chapter argues that the real cost of a feature includes:

a) Only its implementation time. b) Implementation time plus integration, testing, balancing, teaching, and forever-maintenance. c) Only the time it takes to playtest. d) Only the time to build plus one pass of polish.

9. The chapter uses Star Citizen as the canonical example of which failure mode?

a) Shipping a broken product and recovering through patches. b) Continuous scope expansion with no shipping discipline. c) Cutting so aggressively the game lost its identity. d) Misjudging the target market.

10. The chapter recommends that polish time be budgeted at roughly:

a) The same amount of time as implementation. b) Two to three times the implementation time. c) One-quarter of the implementation time. d) Polish cannot be budgeted; it happens when it happens.

11. According to the chapter, by the end of week two of a new project, you should have:

a) A completed design document. b) A playable prototype, however rough. c) Your full asset pipeline established. d) All hiring decisions finalized.

12. Which of the following is an honest estimate for a first-time solo indie game of meaningful scope (per the chapter)?

a) 3-6 months. b) 1-3 years. c) 6-12 weeks. d) 5-7 years.

13. The chapter recommends "scope by mechanics, not by content." The underlying reason is:

a) Mechanics are more fun for designers to build than content. b) Adding mechanics is always cheaper than adding content. c) One deep mechanic can carry an entire game via explored variations, while shallow mechanics compound scope cost. d) Publishers prefer mechanics-driven pitches.

14. The chapter describes the "one game a year" philosophy as:

a) A restriction on how frequently you can release. b) A practice of finishing small games frequently to build shipping skill. c) A marketing strategy for building audience. d) A legal requirement for Steam developers.

Answer Key

1. (b) Imagining the shipped result without budgeting the labor that produces it. The dream-game fallacy is the gap between seeing the final game in your head and measuring the years of implementation that would be required to build it. The dream is inspiring but not a scope document. It always describes more than can be shipped.

2. (d) Marketing budget. Marketing is important, but it is not a dimension of scope in the sense the chapter uses. Scope is what the game contains and how finished it is. The three axes are content volume, system depth, and polish bar. Marketing is a separate dimension of the project, discussed in Chapter 38.

3. (b) Everything takes approximately three times longer than you initially estimate. Hofstadter's Law, compounded. Teams consistently estimate the happy path, ignoring the edge cases, refactors, and dependencies that define the average development week. Multiply initial estimates by three to get a realistic baseline.

4. (b) A narrow but polished piece of the game at final shippable quality. A vertical slice is production-quality in a limited scope — a complete level, not a placeholder prototype. It proves the feel of the game and sets the polish bar the rest of production will match.

5. (c) The overall structure of the game holds together end-to-end. An MVP is the ugliest but functional whole game. It tests structure: is the arc right, does the pacing work, do mechanics pay off each other? A vertical slice tests feel: does the moment-to-moment play satisfy? They answer different questions.

6. (c) Baba Is You. Baba Is You is one mechanic — pushing the words that make the rules — explored across hundreds of puzzles. Braid, Celeste, and Downwell are also cited as examples of the same philosophy. Large open-world AAA games like The Witcher 3 and Starfield are scoped along different axes.

7. (b) A feature that the game cannot ship without. Must-Have means the game is not a game without this feature. Be ruthless here; most designers overpopulate Must-Have. If the game would still function, even worse, without the feature, it is Nice-to-Have at best.

8. (b) Implementation time plus integration, testing, balancing, teaching, and forever-maintenance. Implementation is maybe 10% of the true cost of a feature. Everything else is the hidden cost that shows up later — in tuning, in UI, in tutorial, in maintenance across patches. Features are debts that compound.

9. (b) Continuous scope expansion with no shipping discipline. Star Citizen has raised over $700 million, promised increasingly ambitious features, and has not fully shipped after more than a decade. It is the canonical case of a project that cannot cut and therefore cannot finish. Anthem is also cited in the chapter as a related but distinct case — it shipped, but broken.

10. (b) Two to three times the implementation time. Polish consistently takes longer than construction. If a feature takes two weeks to build, plan four to six weeks to polish it. Projects that do not budget for this die in the polish phase, often with the construction "done" but the game unshippable.

11. (b) A playable prototype, however rough. The two-week prototype milestone is a diagnostic. If you cannot get something playable in two weeks, the scope or tech stack is probably wrong. Discovering this early is cheap. Discovering it at month six is expensive.

12. (b) 1-3 years. Solo indie games of meaningful scope consistently take 1-3 years, sometimes longer. Stardew Valley took four. Celeste took two. Braid took three and a half. Anything faster is a jam-size project or a sequel on mature tech. Plan accordingly.

13. (c) One deep mechanic can carry an entire game via explored variations, while shallow mechanics compound scope cost. Adding mechanics is expensive in hidden ways — every mechanic must interact well with every other, and the content produced for each mechanic multiplies testing and balancing cost. One deep mechanic gives you hundreds of variations essentially free; ten shallow ones give you the cost of ten mechanics and the depth of none.

14. (b) A practice of finishing small games frequently to build shipping skill. Daniel Cook, the Ludum Dare community, and jam culture broadly advocate finishing many small games rather than perpetually polishing one large one. The skill of shipping lives in the last 20% of a project; a designer who has shipped five small games has learned more than a designer who has half-built one big game.