Chapter 31 — Quiz

Thirteen questions, in roughly increasing difficulty. The answers and explanations follow at the end of the document. Try the questions first; the explanations include design reasoning that is easier to absorb after you have committed to an answer.

1. The chapter argues that "your opinion about your game is wrong." What is the underlying mechanism that makes this true?

A. Designers tend to be pessimists who undervalue their own work. B. Most designers do not have professional training in critique. C. Expert blindness — extended exposure to a complex creative work makes it impossible to perceive it the way a first-time observer would. D. Players in 2026 have shorter attention spans than designers expect.

2. Playtesting and QA are often confused. What is the core distinction the chapter draws?

A. QA is for shipped games; playtesting is for unshipped builds. B. QA tests correctness (does it crash, does the save work); playtesting tests design (is it fun, clear, motivating). C. QA uses paid testers; playtesting uses volunteers. D. There is no real distinction; the words are interchangeable in modern practice.

3. A "kleenex test" gets its name from which property of the test?

A. It produces results that should be discarded after one read. B. Each tester is single-use, because once they have played the first five minutes they can never again be a first-time player of your game. C. The tester is brought to tears by the experience. D. It is named after the disposable culture of mobile games.

4. The chapter recommends against playtesting with friends, family, or coworkers as your primary source of design data. Why?

A. Friends are unreliable about scheduling. B. Friends do not own gaming hardware. C. The cost of honest criticism in a friendship is high; friends will blunt their feedback whether they intend to or not, producing systematically biased data. D. Friends are too critical, exaggerating problems out of jealousy.

5. According to Jakob Nielsen's classic finding, roughly how many testers are needed to surface ~80% of the major usability issues in an interface?

A. 2-3 B. 5 C. 15-20 D. At least 50 for any reliable signal.

6. During a playtest session, what is the chapter's most emphatic instruction to the moderator?

A. Take detailed notes on every keystroke. B. Encourage the tester with frequent reassurance. C. Shut up. D. Ask "did you like it?" at frequent intervals.

7. Which of the following is the strongest example of the "Two Questions Rule" applied well?

A. "Did you like the boss fight?" B. "Was the boss too hard?" C. "What were you thinking when you died at the boss?" D. "Don't you think the boss design is innovative?"

8. A tester says, "the combat felt floaty." How should you record this in your findings?

A. As the finding: "Combat is floaty; fix it." B. As a report from one tester, separated from the design problem it might describe; the actual finding requires further investigation into what specifically about the combat (hit-stop, screen shake, audio impact, input response) is failing. C. As a contradiction to your vision; ignore. D. As a vote in favor of changing the combat.

9. You have collected eight playtest sessions. Tester three said the music was too loud. None of the other seven testers mentioned music. How should you treat this finding?

A. Critical — fix immediately. B. Important — schedule for next sprint. C. Worth noting but unlikely to be a strong pattern; do not let one tester's report drive a major change unless it describes a critical blocker. D. Ignore — testers always complain about music.

10. The chapter classifies findings into four triage tiers. What are they, in priority order?

A. Easy / Medium / Hard / Impossible. B. Critical / Important / Nice-to-have / Ignore. C. Bug / Feature / Polish / Cut. D. Day-1 / Week-1 / Patch / Sequel.

11. The chapter describes analytics and in-person playtesting as complementary tools. The analogy used is:

A. Analytics is the camera; in-person playtesting is the microphone. B. Analytics is the telescope; in-person playtesting is the microscope. C. Analytics is the doctor; in-person playtesting is the patient. D. Analytics is the architect; in-person playtesting is the carpenter.

12. Which of the following counts as a valid reason to not act on a playtest finding?

A. The finding contradicts the designer's personal preferences. B. The finding came from a tester whose demographic does not match the target audience and the same finding has not appeared in any in-target tester. C. The team is tired and does not want to revisit that area. D. The publisher has not budgeted time for the change.

13. The chapter introduces a Telemetry.gd script. What format does the script write events in, and why?

A. CSV, because it is easy to import into Excel. B. Binary, for speed. C. JSON Lines (one JSON object per line), because each event can be parsed independently and the file remains valid even if a session crashes mid-write. D. XML, for compatibility with industry tools.

14. (Bonus, scenario.) You run an alpha playtest of your prototype. Five testers complete the session. Four say the core loop is fun and they would play more. One says the entire premise is uninteresting and they would not play it under any circumstances. Two say the third level is too hard. One says the controls feel laggy. What is the most defensible reading of the data?

A. The game is broken — start over. B. The core loop has signal (4 of 5); investigate the difficulty finding (2 of 5) further; flag the input lag for technical review (1 of 5 but possibly a real bug); the premise objection is one tester's view and worth noting but not yet a pattern. C. Listen to the most negative tester; they are the only one being honest. D. Average the responses to a 7/10 score and continue as planned.

15. (Bonus, ethics.) You ship telemetry that captures every action a player takes in your game, including chat messages and time-of-day patterns. Players have not been informed of the telemetry. What is the chapter's stance on this?

A. Standard practice; do not mention it. B. Disclose what you log and why; never log more than you will analyze; never log anything the player would be uncomfortable with you knowing. For shipped games, full opt-in consent (per GDPR and similar regulation) is required. C. Ethically neutral; players accept this implicitly when they download the game. D. Only a problem if the data is sold; collection itself is fine.

Answers and Explanations

1. C. Expert blindness is the structural reason. Time inside the work changes how you perceive it; you cannot see your own affordances the way a stranger would. Options A, B, and D are surface explanations; C names the underlying mechanism the chapter develops.

2. B. QA tests correctness; playtesting tests design. Both are valuable, but they answer different questions and have different protocols. Conflating them is a common failure mode at small studios — designers ask QA testers "is it fun" or ask playtesters to file bug reports, and neither activity produces good data because the questions are mismatched to the practice.

3. B. Each tester can give you one true first-time experience and only one. After they have played the first five minutes, they are no longer a kleenex tester for that game. This is why kleenex tests are so valuable and so finite — your supply of "people who have never seen the game before" is, by definition, draining.

4. C. Friends provide systematically biased data because the social cost of honest criticism in a friendship is real. They are not lying; they are softening, qualifying, and emphasizing the positives because that is what friends do. Their feedback is not data; it is love. Useful as a sanity check after strangers have spoken; dangerous as a primary source.

5. B. Five users will surface roughly 80% of major usability issues — Nielsen's well-known finding from the usability research tradition. For games, the chapter recommends going slightly higher (closer to 10) because gameplay variance is higher than interface variance. Below 5, you are at risk of mistaking one tester's quirks for a pattern. Above 20, you are spending money faster than you are learning.

6. C. Shut up. The single most important moderation skill, and the one most designers cannot master. Every word you speak during play is data destroyed; the moment you explain something, you have told the tester something real players will never be told, and everything they do afterward is compromised.

7. C. "What were you thinking when you died at the boss?" is a process question about a specific moment, which produces specific recall and bypasses the social-performance layer. A is a polite-yes magnet. B is leading. D is doubly leading and actively performative. The Two Questions Rule's whole point is to extract experience, not preference.

8. B. The tester's words are the starting point of your investigation, not the finding itself. "Floaty" is a vague experiential descriptor; the actual design problem could be one of several things. The chapter is emphatic that you separate "a tester said X" from "the design has problem Y" — the gap between report and finding is where good interpretation lives.

9. C. One-tester reports are weak signal unless they describe a critical blocker. They should be noted, in case the same report appears in subsequent rounds, but should not drive major work on their own. The pattern across testers is what you act on; one-offs are noise until they recur.

10. B. Critical / Important / Nice-to-have / Ignore. Each tier has different urgency and different actionability. The discipline of triage — explicitly classifying every finding — is what separates teams that ship from teams that drown in their own feedback.

11. B. Analytics is the telescope (where, how often, at scale), in-person playtesting is the microscope (why, what was the player thinking, what specifically went wrong). The two together give you both halves of "where + why"; either alone leaves you half-blind.

12. B. A demographic mismatch is a defensible reason to deprioritize a finding if the same finding has not appeared in in-target testers. The other options are non-reasons: A is designer ego, C is fatigue management, D is a budget problem disguised as a design decision. The chapter is careful, however, to warn that constantly invoking demographic mismatch to dismiss inconvenient findings is itself a failure mode (the inverse of friends-and-family syndrome).

13. C. JSON Lines (.jsonl) — one JSON object per line, with flush() after each write — so that the file remains parseable even if the session crashes mid-stream. Each event is self-contained, which means you do not lose the entire log to one corrupted entry. The chapter shows the implementation explicitly; the design choice is about robustness in messy real-world testing conditions, not about elegance.

14. B. The core loop has signal (4/5 say it is fun); the difficulty finding is worth investigating (2/5 is real signal at that sample size); the input lag is a single report but may be a real technical issue (lag is binary — either the build has it or doesn't, regardless of how many testers noticed); the premise objection is one tester's view and is worth recording but not actionable as a pattern at this point. A overreacts, C cherry-picks the angriest voice, D treats the data as numerical when it is in fact qualitative.

15. B. Disclose, minimize collection to what you will analyze, never log anything that would surprise the player. For shipped games, regulatory consent (GDPR, CCPA-equivalent in the US, etc.) applies. The chapter takes the principle position that even small indie devs should disclose telemetry, both because it is the right thing to do and because the alternative is a privacy scandal one screenshot away. "Never log more than you will analyze" is also a discipline against scope creep — collecting data you will not use is a liability with no offsetting benefit.

Self-scoring

13/15 or higher: you have internalized the chapter's framework. Move to the exercises and start running sessions.

10-12/15: solid grasp of the major principles, a few sharp edges to revisit. Re-read the sections on triage and the Two Questions Rule before running your first session.

Below 10/15: re-read the chapter, focusing on the distinction between playtesting and QA, the moderation discipline (especially the silence rule), and the difference between a tester's report and a design finding. These are the load-bearing concepts; without them, the rest of the practice does not work.