7.1 Arcade Cabinet — Q2 Synthesis

Step 1 — Recall what every earlier Try It Now looked like: Each earlier Try It Now practiced exactly one technique in isolation, and it came with scaffolding: starter code to begin from, a walkthrough of the steps, and a worked solution to check your result against. You were also always building the book's running example alongside it, so there was a known-correct answer to compare against.

Step 2 — Recall the definition of a synthesis project: The Definition box in §7.1.1 states that a synthesis project "requires combining multiple previously-taught techniques into one original piece of work," and adds that "the design decisions are the exercise, not a single correct answer to check against."

Step 3 — State the contrast on three axes:

• Techniques: one technique in isolation versus several (physics, groups, camera/state machine, persistence) combined into a single working whole.
• What's actually being exercised: reproducing a taught technique versus making design decisions — the choices are the work, and there is no answer key for them.
• Scaffolding: no starter code, no walkthrough, no running example to build alongside, because the finished thing is genuinely yours.

Answer: An earlier Try It Now practices a single technique in isolation, with starter code and a worked solution to check against; a synthesis project requires combining multiple previously-taught techniques into one original work, where the design decisions themselves — not a single correct answer — are the exercise.

Step 1 — Note that there is no single correct answer: This question asks about your design, so the solution below models one complete answer — a hot-air-balloon canyon climb — so you can see the shape of a full response, the way Try It Now 7.1.1's worked example used a delivery-cart game. Your specifics should differ.

Step 2 — Write the one-sentence pitch: "A one-button game where you pilot a hot-air balloon up a canyon, grabbing fuel canisters and dodging birds, trying to reach the cloud deck before your fuel runs out." It passes the §7.1.2 test: sayable out loud in five seconds, and compressible to exactly one repeated action.

Step 3 — Identify the genre separately: A vertical one-button ascent game (dodge-and-collect).

Step 4 — Identify the core mechanic separately: Firing the burner in short bursts to control the climb. That is the one action the player repeats; fuel, birds, and the canyon layout all exist to make that thrust-timing interesting.

Step 5 — Identify the win condition separately: Reach the cloud deck at the top of the canyon before the fuel gauge hits zero. (The recommended lose condition falls out of the same design: birds cost fuel on contact, so if the fuel reaches zero first, you lose.)

Answer: Pitch: "A one-button game where you pilot a hot-air balloon up a canyon, grabbing fuel canisters and dodging birds, trying to reach the cloud deck before your fuel runs out." Genre: a vertical one-button ascent game. Core mechanic: firing the burner in bursts to control the climb. Win condition: reach the cloud deck before the fuel runs out.

Step 1 — Note that the honest answer depends on your concept: There is no universally correct row to pick — the question is testing whether you can assess your own design. Below is one worked answer using the balloon game, showing how to justify the choice rather than just name it.

Step 2 — Check each of the five rows against the concept: 1. Physics response — easy: the game is literally gravity plus applyForce (the burner), the exact Chapter 5 pattern. 2. Group with overlaps() — easy: two groups, two checks — the fuel group adds fuel on overlap, the birds group subtracts it. 3. Camera or state machine — hard: this concept needs the camera option, since the whole point is climbing a world taller than the canvas. 4. Persistence — easy: one number (best altitude reached) saved with storeItem. 5. Original win/lose — already settled at design time in §7.1.2; it's fuel-managed, not a copy of the courtyard's \(x = 820\).

Step 3 — Pick the hardest and justify it specifically: The camera row (§6.4), for three reasons: the follow logic is subtler in a vertical world (the camera should track the balloon's \(y\) only when it's in the upper part of the screen, or sinking wouldn't feel like sinking); canisters and birds must be spawned in world coordinates above and below the current view, so positions can't be tested against the canvas the way Chapter 6's example did; and the cloud deck and start line are world coordinates too, so a camera bug silently breaks the win/lose condition, not just the view.

Answer: The camera requirement (§6.4) — it's the one row where correctness isn't locally checkable, because it interacts with spawning, the win trigger, and the lose trigger all at once. Your own answer should name a different row only if you can point to a specific reason, not a vague feeling.

Step 1 — State the recommendation precisely: §7.1.4's build order puts the title screen (and persistence) at step 4, after the core mechanic and the win/lose loop are working — with the warning that a title screen "feels like real progress" even though it isn't the game.

Step 2 — Give the scheduling reason: The Insight Note makes the stakes concrete: building in this order means that if you run out of time, what exists is playable; building title-screen-first means that if you run out of time, what exists is "a menu in front of nothing." Polish is the last 10% of the work but the first 10% of what a player notices — so it's precisely the part that can safely wait.

Step 3 — Give the design reason: You can't build a good title screen before the game exists, because the title screen's job is to teach the finished game: the real controls, the real win/lose condition, the real art direction. Build it last and it's a short task describing something you know; build it first and you'll either guess wrong or redo it.

Answer: Because the title screen is polish, and §7.1.4's ordering guarantees that whatever exists when time runs out is playable. Building it last also means it can teach the actual finished game — controls, win condition, art — instead of a guessed-at version, so it's both the safer order and the better result.

Step 1 — Define cutting scope: Scope is "the set of features a project commits to" (Key Terms). Cutting scope means removing a planned feature — deciding the game ships with four finished features instead of five.

Step 2 — Define compressing time: Compressing time keeps every feature on the list but rushes each one — starting everything and finishing nothing properly. The schedule keeps its promises on paper while the work stops keeping them in reality.

Step 3 — Explain why §7.1.4 recommends cutting: Its stated standard is that "a three-requirement game that fully works beats a five-requirement game where two are broken," and two facts make that trade correct. First, each requirement in §7.1.3 is all-or-nothing: a half-built feature earns no credit but still costs the same debugging time. Second, broken features don't stay contained — a half-finished joint hazard or a state machine with a missing break can crash the features that did work, so rushing everything can destroy what was already finished.

Answer: Cutting scope = removing a planned feature so the remaining ones get finished properly; compressing time = keeping every feature and rushing each, leaving them half-done. §7.1.4 recommends cutting because finished, working requirements are what the project is graded on — a smaller complete game beats a bigger broken one, and half-built features can even take working features down with them.

Step 1 — Check the constraint: Chapter 6 means §6.1–§6.9: groups and overlaps(), the camera, storeItem/getItem, state machines, world.getSpriteAt(), joints, and timed events. Plain sprites and gravity are Chapter 5 material, so they don't count here even though the game uses them.

Step 2 — Name one Chapter 6 technique the design actually uses: The camera (§6.4). The canyon in the balloon game is several times taller than the canvas, so the camera follows the balloon's \(y\) position as it climbs — the world scrolls vertically past it exactly the way §6.4's example scrolled horizontally.

Step 3 — Confirm the citation is specific: The section number is §6.4. (The same design also uses a three-state title/play/end machine from §6.6 and storeItem from §6.5, so either of those would be an equally valid answer to this question.)

Answer: The camera that follows the balloon up the canyon — a technique learned in §6.4. Any Chapter 6 technique with an honest section number and a concrete use in your game is a correct answer.

Step 1 — Apply the concreteness test: The solution to Try It Now 7.1.2 sets the bar: a useful playtest finding names something specific and testable ("a first-time player didn't realize pressing space would jump until they'd already lost once"), not an impression ("it felt fine"). So the answer must start with an observed behavior, not an impression.

Step 2 — Report one concrete finding: In my playtest, the first playtester steered away from the fuel canisters — they read the bright canisters as hazards because the birds were drawn as small bright shapes too — and ran out of fuel two-thirds of the way up the canyon. Per §7.1.5's checklist, that's a design gap, not a bug: the player didn't know what to do, and nothing on screen corrected them.

Step 3 — Name the specific one-hour change: Make the two groups visually unambiguous and add one line of instruction: darken the birds to silhouettes, give the canisters a slow pulsing halo, and print "Grab fuel before it runs out!" at the top of the play state. That's about an hour of work, it attacks exactly the observed failure, and it needs no new API — §7.1.5 points out the fix is usually making something you already built more visible.

Answer: I'd make the fuel canisters unmistakably collectible — dark bird silhouettes, a pulsing halo on the canisters, and a one-line "Grab fuel!" prompt in the play state — because my playtester avoided the canisters as if they were hazards and ran out of fuel partway up. Your answer must come from your own playtest; the test of concreteness is that someone else could implement and verify your change from your description alone.