6.2 Overlaps and Collisions

Step 1 — Define the overlap: An overlap is a geometry question — two sprites occupy the same space on screen, detected with overlaps(), which compares positions directly and does not require either sprite to have any physics at all.

Step 2 — Define the collision: A collision is a physics question — a solid contact between two sprites with physics bodies, resolved by the engine so that they push each other apart, detected with colliding().

Step 3 — State the practical difference: An overlap only notices the player (the coin); a collision stops or moves the player (the wall or crate). That is why a sprite with collider = 'none' can be overlapped but can never be collided with.

Answer: An overlap is two sprites sharing the same space, detected by position alone with overlaps(); a collision is a solid physical contact resolved by the physics engine so the sprites push apart, detected with colliding().

Step 1 — Apply the test to each object: Ask of each one: does it stop or move the player (collision), or does it only notice the player (overlap)?

• Coin: overlaps() — you run through it and collect it, so it must not push back.
• Wall: colliding() — it is solid and must stop the player.
• Cutscene trigger: overlaps() — an invisible, passable zone that only reports being entered.
• Pushable crate: colliding() — it is solid, and the push is a physics contact that moves it.

Answer: Coin → overlaps(); wall → colliding(); cutscene trigger → overlaps(); pushable crate → colliding().

Step 1 — Recall what colliding() asks: It asks the physics engine whether it recorded a solid contact between two bodies.

Step 2 — Recall what collider = 'none' does: It removes the sprite from physics entirely — there is no body for the engine to track, touch, or resolve.

Step 3 — Put the two together: Since the engine never sees the sprite, it can never record contact with it, so colliding() reports 0 for it forever. Only overlaps(), which compares positions directly, can find it.

Answer: A collider = 'none' sprite has no physics body, so the physics engine never registers a contact with it — and colliding() only reports contacts the engine registered. Detect such sprites with overlaps() instead.

Step 1 — Recall how the draw loop runs: It executes about 60 times per second, and every if inside it is re-tested on every frame.

Step 2 — Recognize overlaps() as a state: overlaps() answers "are we overlapping right now?", so while the player sits on the coin the answer stays true frame after frame — roughly sixty prints per second of contact. It is a kb.pressing()-style state question, not a one-off event.

Step 3 — Apply the simplest fix: Remove the coin inside the branch:

if (player.overlaps(coin)) {
  coin.remove();
  score = score + 1;
}

Once the coin is removed there is nothing left to overlap, so the branch cannot run twice — removing the collected thing is both the game behaviour you wanted and the repeat-stopper.

Answer: Because overlaps() is a state that stays true for every frame of contact, and the loop re-tests it 60 times a second; the simplest fix is coin.remove() inside the branch, so the coin stops existing after the first touch.

Step 1 — Recall the group form: player.overlaps(coins) with a Group returns true if the player overlaps any member of the group, and false otherwise — one line covers all the coins.

Step 2 — Note what is missing: The boolean tells you that something was touched but not which one — you get no handle on the specific coin, so you cannot remove it, score against it individually, or act on it in any way.

Step 3 — Name the tool that fills the gap: The callback form, player.overlaps(coins, (self, coin) => { ... }), runs once per actually-touched coin and hands you that specific sprite.

Answer: It returns a single boolean — true when the player touches any coin in the group. It cannot tell you which coin was touched, so it gives you nothing to remove or act on.

Step 1 — Diagnose the original: The boolean group form cannot tell you which coin was touched, so there is no sprite to remove — and the score would keep climbing every frame the player touches any coin.

Step 2 — Switch to the callback form: The callback runs once per actually-touched coin and hands you that specific sprite, which is the handle you need in order to remove it:

player.overlaps(coins, (self, coin) => {
  coin.remove();
  score = score + 1;
});

Step 3 — Check the behaviour: coin.remove() deletes the coin from the world and from the group, so each coin can be collected exactly once, the score rises by 1 per coin, and the overlap cannot repeat on a coin that no longer exists.

Answer: Use the callback form and remove the specific coin:

player.overlaps(coins, (self, coin) => {
  coin.remove();
  score = score + 1;
});

Step 1 — Identify self: It is the sprite you called the method on — here, the player. moSHion always passes that as the first argument.

Step 2 — Identify coin: It is the specific member of the coins group that the player is currently overlapping. The callback runs once per touched coin, and each run gets its own coin bound to that run's sprite.

Step 3 — Note that the names are yours: (self, coin) could equally be (a, b) — only the order is fixed: first the sprite you asked about, second the group member it touched.

Answer: self is the player (the sprite the method was called on); coin is the particular coin from the group that self is touching on that callback call.

Step 1 — Recall the return type: colliding() returns a number — the count of consecutive frames of solid contact, starting at 1 — not a boolean.

Step 2 — Apply strict equality: === compares without any type conversion, and a number is never strictly equal to a boolean, so 1 === true evaluates to false.

Step 3 — Trace the consequence: On the first frame of contact colliding() returns 1, and 1 === true fails; on every later frame it returns 2, 3, 4…, which also fails. The branch never runs, the jump never fires, and nothing anywhere reports an error.

Answer: Because colliding() returns a frame count (a number), and 1 === true is false under strict equality — the comparison can never succeed. Test truthiness directly with if (player.colliding(ground)), or compare against a number such as === 1.

Step 1 — Characterize the bare call: player.colliding(ground) is truthy for the entire contact — every frame from the first until the sprites separate — because any number except 0 is truthy. It answers the state question "am I touching the ground right now?"

Step 2 — Characterize the === 1 test: player.colliding(ground) === 1 is true only on the very first frame of contact. It answers the event question "did I just land this frame?"

Step 3 — Match each to its use: Use the bare state for continuous conditions — for example, allowing a jump only while grounded. Use === 1 for one-off actions — for example, playing a landing sound once instead of sixty times a second.

Answer: colliding(ground) is a state, truthy for the whole contact; colliding(ground) === 1 is an event, true only on the landing frame. Use the state for "while grounded" logic and the event for "on landing" actions like a sound effect.

Step 1 — Pick the event test: The landing frame is the first frame of contact, and colliding() counts contact frames starting at 1, so comparing with === 1 isolates exactly that frame.

Step 2 — Write the condition:

if (player.colliding(ground) === 1) {
  landSound.play();
}

Step 3 — Verify it fires once per landing: On later frames of the same contact the count is 2, 3, 4…, so the condition is false and the sound cannot repeat; a fresh landing restarts the count at 1, so the sound plays again exactly once.

Answer:

if (player.colliding(ground) === 1) {
  landSound.play();
}

Step 1 — Plan the pieces: A player sprite, a coins Group with collider = 'none' (so the coins are passable pickups that only overlaps() can see), 6 coins spawned in a loop, arrow-key movement, and the callback form of overlaps() to remove each coin and raise the score.

Step 2 — Write the code:

▶ Press Run to see the output…

Step 3 — Check the mechanics: collider = 'none' means the player passes through the coins, so detection must use overlaps(); the callback removes each touched coin (which also stops the state repeating) and adds 1 to the score; the score is drawn every frame.

Answer: The game above — 6 gold, passable coins worth 1 point each, collected through player.overlaps(coins, ...) with coin.remove() inside the callback.

Step 1 — Identify the signal: coin.remove() takes the sprite out of the world and out of the group, so coins.length falls by one per pickup and reaches 0 exactly when every coin has been collected.

Step 2 — Add the check to draw(): After the overlaps callback, test the length and draw the message when the board is clear:

  if (coins.length === 0) {
    text('All collected!', 150, 200);
  }

Step 3 — Full extended code:

▶ Press Run to see the output…

Answer: Watch coins.length — it falls as coins are removed — and draw the win message when it reaches 0:

if (coins.length === 0) {
  text('All collected!', 150, 200);
}

Step 1 — Mirror the coin group: A bomb is the same shape as a coin with a different colour and effect: a bombs Group, 'crimson', collider = 'none', and its own short spawn loop.

Step 2 — Give it its own callback: Because you call overlaps() on a group, the group you ask about is the answer — so a second call on bombs subtracts 5 for each bomb touched, and you never have to ask what kind of thing you hit:

  player.overlaps(bombs, (self, bomb) => {
    bomb.remove();
    score = score - 5;
  });

Step 3 — Full code:

▶ Press Run to see the output…

Answer: A bombs group with collider = 'none' and its own overlaps callback that removes the bomb and subtracts 5 — one group per object type means the call site itself tells you what was hit.

Step 1 — Keyboard input: kb.pressing() is a state — true the whole time a key is held. The event version is kb.presses(), and the trick is the engine's built-in edge detection: it fires exactly once, on the frame the key goes down.

Step 2 — Overlap pickup: overlaps() is a state — true every frame of contact. The trick is to remove the sprite inside the branch or callback, so after the first frame there is nothing left to overlap and the condition cannot be true again. You build the one-off yourself by destroying the thing you touched.

Step 3 — Collision landing: colliding() is a state — a count that stays nonzero for the whole contact. The trick is comparing with === 1, which is true only on the first frame of contact, turning the ongoing contact into a single landing event.

Answer: (1) kb.presses() vs kb.pressing() — the engine's edge detection fires once per key-down; (2) the repeating overlaps() — remove the overlapped sprite so the state cannot recur; (3) the contact count — test colliding() === 1 to catch only the first frame. In every case a per-frame state had to be converted into an event by noticing the frame it started.

Step 1 — Remember a Group is an array: bullets extends JavaScript's Array, so deleting a member splices it out of the sequence and every later bullet shifts down one index.

Step 2 — Trace the skip: Suppose the loop is at index 2 and deletes that bullet. The bullet that was at index 3 now moves into index 2 — but the loop has already finished with index 2 and advances to index 3, which now holds what used to be at index 4. The bullet that shifted into index 2 is never visited, silently and with no error.

Step 3 — Explain the snapshot: [...bullets] evaluates the spread once, making a plain copy of the group's current contents. The loop walks that unchanging snapshot while the original group shrinks underneath it, so shifting indices in the group cannot move anything inside the snapshot — every bullet captured at the start is visited exactly once.

Answer: Deleting during a direct loop shifts later elements down one index while the loop counter keeps advancing, so the element that moved into the just-deleted slot gets skipped; [...bullets] loops over an unchanging copy, so the group can shrink safely underneath the loop without losing its place.

Step 1 — Define group.remove(sprite): It unparents the sprite from that one group only — the sprite still exists in the world, still draws, still runs physics, and remains a member of any other group it belongs to.

Step 2 — Define sprite.delete(): It destroys the sprite entirely — removed from the world and from every group it belonged to. Beware the near-identical names: sprite.remove() is an alias for sprite.delete(), while group.remove(sprite) is the genuinely different operation.

Step 3 — Answer the screen question: The ghost-drawing operation is group.remove(sprite) — the sprite keeps drawing and keeps colliding, it is just quietly untracked by whatever group code was watching it.

Answer: group.remove(sprite) detaches the sprite from one group but leaves it alive in the world; sprite.delete() destroys it everywhere. group.remove(sprite) is the one that leaves a sprite still drawing on screen.