5.2 Physics Feel

Step 1 — What the property controls: world.gravity.y is the downward pull applied to every dynamic sprite. Setting it to 0 removes that pull entirely, so a sprite stays exactly where its velocity puts it and never drifts toward the bottom of the canvas.

Step 2 — What that feels like to play: With no vertical pull, "up" and "down" stop being special — the canvas reads as a floor seen from above rather than a wall seen from the side.

Answer: It turns gravity off, so dynamic sprites no longer fall. Top-down games use this setting: a dungeon crawler, a racing game seen from above, or a puzzle game where pieces stay put until the player moves them.

Step 1 — What the check asks: player.colliding(ground) is true only while the player sprite is actually touching the ground sprite. Guarding the jump with it means "only launch from a surface."

Step 2 — What happens without it: The jump would fire on any space-bar press, including mid-air ones. Each press would reset player.vel.y to -8 before gravity had finished pulling the player back down, so repeated presses would carry the player upward indefinitely.

Answer: The check makes the ground a precondition for jumping. Without it the player could jump in mid-air, and repeated presses would let them climb off the top of the canvas instead of arcing back down.

Step 1 — The name: .vel is short for velocity. It is a vector with two components, .vel.x and .vel.y, describing how fast the sprite is moving and in which direction.

Step 2 — The units: Velocity in moSHion is measured in pixels per frame — not per second. player.vel.x = 4 moves the sprite 4 pixels to the right on each of roughly 60 frames a second.

Answer: .vel stands for velocity, measured in pixels per frame.

Step 1 — What the assignment does: Setting player.vel.y = -8 replaces the sprite's vertical velocity outright with 8 pixels per frame upward (negative y is up).

Step 2 — What gravity does next: world.gravity.y keeps acting every frame after that. It adds a small downward amount to .vel.y on each frame, so -8 becomes -7, then -6, and so on.

Step 3 — The turning point: Once .vel.y passes through 0 the sprite is momentarily at the top of its arc; gravity keeps adding, .vel.y goes positive, and the player falls.

Answer: Vertical velocity shrinks toward zero, crosses it, and then grows downward. The player does not keep rising because the jump sets velocity once, while gravity changes it every frame.

Step 1 — Locate the value that sizes the jump: The whole jump is one line: player.vel.y = -8;. That -8 is the launch speed, and nothing else in the jump code affects how high the player goes.

Step 2 — Change it in the right direction: Negative y is up, so a more negative number is a faster launch and a higher arc — -12 instead of -8.

Answer: Change -8 to a more negative number, e.g. player.vel.y = -12;. (Lowering world.gravity.y would also produce a higher jump, but it changes how every sprite falls, not just this one.)

Step 1 — How often draw runs: draw is called about 60 times a second, so an unguarded line in it runs on every frame.

Step 2 — What that does to velocity: Gravity nudges .vel.y downward each frame, but the assignment immediately overwrites it back to -8 before that nudge can accumulate. Vertical velocity is pinned at -8 forever.

Answer: The player would rise at a constant 8 pixels per frame and never come down — straight off the top of the canvas. Gravity is still being applied, but the assignment discards its effect every frame, so the arc never forms.

Step 1 — .bounciness: Also called restitution, it is how much speed a sprite keeps after a collision — 0 sticks on impact, 1 rebounds at full speed.

Step 2 — .friction: It resists sliding along a surface rather than bouncing off it — 0 is frictionless, higher values drag horizontal motion to a stop.

Step 3 — The distinction: Bounciness acts on the impact itself; friction acts on the contact that follows it.

Answer: .bounciness governs how much speed survives a collision; .friction governs how much a sprite resists sliding along a surface. A rubber ball has high bounciness; sandpaper (or a rough concrete floor) has high friction.

Step 1 — Bounciness combines by taking the higher value: Between 0.2 and 0.8, the engine uses 0.8. One bouncy surface is enough to produce a bouncy collision.

Step 2 — Friction combines by geometric mean: Friction instead uses the geometric mean of the two values: \(\sqrt{0.2 \times 0.8} = \sqrt{0.16} = 0.4\).

Step 3 — Why they differ: Bounciness describes a rebound either surface can supply on its own, so the greater value wins. Friction describes how two surfaces drag against each other, so both contribute.

Answer: The collision uses bounciness 0.8 (the higher of the two). With those same numbers as friction it would use 0.4, the geometric mean of 0.2 and 0.8.

Step 1 — player.vel.x = 4 commands the motion: It sets velocity directly, in pixels per frame, replacing whatever the sprite was doing horizontally. The result is exact and immediate, and it ignores the sprite's mass.

Step 2 — player.applyForce(4, 0) requests the motion: It applies a push measured in Newtons and lets the physics engine work out the resulting velocity from the sprite's mass and current motion. It adds to existing movement rather than replacing it.

Step 3 — Note the units do not match: Pixels per frame and Newtons have no fixed conversion, so 4 in one is not 4 in the other. Expect to tune a force by a large factor, not a small one.

Answer: .vel overrides physics with an exact speed — right for direct player control, where the input should feel immediate and predictable. applyForce layers a push on top of existing motion and respects mass — right for environmental effects like wind, explosions, or thrust.

Step 1 — What the wind code does: player.applyForce(0, -3) runs every frame the player is above y = 200. It adds an upward push to whatever velocity the player already has.

Step 2 — Why the jump survives it: Because applyForce adds rather than assigns, the jump's upward velocity is still there underneath. Setting .vel.y instead would discard the jump arc and pin the player to one wind-driven speed.

Answer: applyForce adds to existing motion instead of replacing it, so the wind's push accumulates on top of the jump's velocity. A jump made inside the zone hangs noticeably longer, which is the effect layering rather than overwriting.

Step 1 — visible = false hides the sprite: Drawing stops, but the sprite is still in the world. It keeps updating, and its physics body still collides — an invisible wall the player can walk into.

Step 2 — delete() removes it: Drawing stops, updating stops, and the physics body is gone. Nothing is left to collide with, and there is no undo.

Answer: delete() removes the sprite's physics body and stops it updating; .visible = false only stops it being drawn, leaving an invisible but fully solid sprite in the world. Use .visible when you want the sprite back later, delete() when you do not.

Step 1 — What the win check reads: The block computes a distance from goal.x and goal.y. Once goal.delete() has run, the code also sets goal = null — the variable no longer holds a sprite.

Step 2 — Reading a property off null: Without the if (goal) guard, the next frame would evaluate goal.x on null and throw a TypeError, stopping draw from that frame onward.

Step 3 — Why sitting on the old position matters: It guarantees the failure. The player is still within 25 pixels of where the goal used to be, so the check runs again on the very next frame instead of the player wandering out of range first.

Answer: draw would crash with a TypeError — reading .x of null — on the frame after the win, and the game would stop rendering. The if (goal) guard exists so the distance check stops running once there is no goal left to measure against.