6.7 Advanced Input

Step 1 — Recall the definition: world.getSpriteAt(x, y) performs hit testing at a world position and returns the top-most (highest layer) sprite whose shape covers the point \((x, y)\).

Step 2 — The empty case: If no sprite overlaps that position, it returns undefined. This is why hit-test code usually compares the result against a specific sprite (=== startButton) or checks truthiness (if (hit)) before using it.

Answer: world.getSpriteAt(x, y) returns the top-most sprite at that world position, or undefined if there is no sprite there.

Step 1 — Define hit testing: Hit testing is the process of checking whether a point — such as the mouse cursor position \((\text{mouse.x}, \text{mouse.y})\) — overlaps with any sprite in the world. world.getSpriteAt(x, y) is the function that performs it.

Step 2 — Why it matters: Mouse interaction needs to translate "the user clicked at pixel \((x, y)\)" into "the user clicked on this object." Without hit testing, a click handler would fire identically everywhere on the canvas with no way to know which sprite (if any) was under the cursor. Hit testing is what makes buttons clickable, sprites selectable, and drag-and-drop possible — every mouse interaction in a game builds on it.

Answer: Hit testing is checking whether a point (like the cursor) overlaps any sprite; it's essential because it lets the game determine which object the mouse is interacting with, enabling clicks, selection, and dragging.

Step 1 — What mouse.presses() alone tells you: mouse.presses() only reports that the mouse button went down somewhere on the canvas. It carries no information about where the click landed or what was under the cursor.

Step 2 — What the comparison adds: world.getSpriteAt(mouse.x, mouse.y) === startButton answers two questions at once:

• Was anything clicked? (getSpriteAt returns undefined if not.)
• Was it specifically the Start button? (Strict equality against startButton.)

Step 3 — Why both are needed together: Combining them with && means startGame() runs only when the press happened and the press landed on the button. Checking mouse.presses() alone would start the game no matter where the player clicked — even empty background — making the button meaningless.

Answer: Because mouse.presses() only detects that a click occurred anywhere; the hit test confirms the click actually landed on the Start button before triggering the action.

Phase 1 — Press (grab): Runs once when mouse.presses() fires. Code: hit-test the cursor with world.getSpriteAt(mouse.x, mouse.y), check the result belongs to the draggable set (e.g., coins.includes(hit)), and store it as the currently dragged sprite (dragging = hit).

Phase 2 — Hold (drag): Runs every frame while the button stays down (mouse.pressing()). Code: snap the dragged sprite to the cursor each frame (dragging.x = mouse.x; dragging.y = mouse.y;) and zero its velocity (dragging.vel.x = 0; dragging.vel.y = 0;) so physics doesn't fight the snap — without it, a sprite still carrying momentum keeps drifting after each frame's snap. The coin example skips those two lines because its coins run collider = 'none' at world.gravity.y = 0, so nothing is pushing them; any draggable sprite with a real collider needs them.

Phase 3 — Release (drop): Detected when mouse.pressing() becomes false. Code: clear the drag reference (dragging = null), leaving the sprite wherever it was dropped.

Answer: Press → grab via hit test and store the sprite; Hold → snap its position to the cursor each frame while the button is down; Release → stop dragging by clearing the reference when the button comes up.

Step 1 — What could go wrong without it: On the title screen there are multiple sprites: the coins and the Start button. If the code started a drag whenever world.getSpriteAt returned any sprite, clicking the Start button would set dragging = startButton, and the button itself would get dragged around the screen instead of being clicked.

Step 2 — What the check guarantees: coins.includes(hit) verifies the hit sprite is actually a member of the coins group before assigning it to dragging. Only genuine coins can be picked up; everything else (button, background) is ignored as a drag target.

Step 3 — Bonus benefit: Because the check filters drags to coins, the same mouse.presses() event can safely also be used for the Start-button click logic without the two features interfering.

Answer: It ensures the grabbed sprite really belongs to the coin group, so clicking other sprites (like the Start button) never accidentally starts a drag of the wrong object.

Step 1 — Understand hover vs. press: Hovering means the cursor is over the button without clicking. So we must hit-test every frame in draw(), not just inside an if (mouse.presses()) block — a press happens once per click, but hover state changes continuously.

Step 2 — Write the code:

▶ Press Run to see the output…

Step 3 — Explain the key line: The ternary sets the color each frame based on the current hover state: lighter green ('mediumseagreen') while the cursor is over the button, normal 'seagreen' otherwise. Since this runs in draw(), the color updates instantly as the mouse moves in and out.

Answer: Store the per-frame result of world.getSpriteAt(mouse.x, mouse.y) === startButton and use it to set startButton.color to a lighter green when true and the original color when false — see the code above.

Step 1 — Track the selection: We need a variable holding whichever sprite the user last clicked. Clicking one of the three sprites selects it; clicking elsewhere deselects.

▶ Press Run to see the output…

Step 2 — Select on click: On mouse.presses(), hit-test and accept the click only if it landed on one of our three sprites:

function draw() {
  background('#112');

  if (mouse.presses()) {
    const hit = world.getSpriteAt(mouse.x, mouse.y);
    if (hit === a || hit === b || hit === c) {
      selected = hit;
    } else {
      selected = null;
    }
  }

Step 3 — Delete on keypress: When Delete is pressed and something is selected, remove it from the world and clear the selection:

  if (kb.presses('Delete') && selected) {
    selected.remove();
    selected = null;
  }
}

Step 4 — Verify the flow: Click a sprite → it's stored in selected; press Delete → selected.remove() destroys exactly that sprite; pressing Delete with nothing selected does nothing because of the truthiness guard.

Answer: See the full code above — click to select via world.getSpriteAt, then kb.presses('Delete') calls selected.remove() and clears the selection.

Step 1 — mouse.presses(): Returns true for exactly one frame, at the moment the mouse button transitions from up to down. Use it for one-time events: grabbing a sprite, registering a click.

Step 2 — mouse.pressing(): Returns true continuously for every frame the button is held down. Use it for ongoing states: checking whether a drag is still active.

Step 3 — Why the drag code uses both:

• mouse.presses() starts the drag: it fires once, so the grab logic (hit test + storing dragging) runs a single time rather than repeatedly.
• !mouse.pressing() ends the drag: since it's true every held frame, the moment it flips to false we know the button was released, so we clear dragging.

Using presses() for the release check wouldn't work (it doesn't detect release), and using pressing() for the grab would re-run the grab logic every frame.

Answer: mouse.presses() is true only on the single frame the button goes down (edge-triggered); mouse.pressing() is true the whole time it's held (level-triggered). The drag code uses presses() to begin the drag once and pressing() to detect when the button is released and end it.