6.3 Physics Applications

Step 1 — Recall what gravity does: world.gravity.y pulls every dynamic sprite in the vertical direction each frame.

Step 2 — Interpret the value 0: Setting it to 0 means there is no downward pull at all, so sprites stay wherever they are placed (or keep moving only under forces you apply directly).

Step 3 — Identify suitable games: Top-down games — a maze game viewed from above, a Pac-Man-style game, or any game where "up" and "down" on screen aren't directions things should fall. Gravity would make characters slide to the bottom of the screen for no reason.

Answer: world.gravity.y = 0 turns off vertical gravity entirely; sprites don't fall. It suits top-down games (mazes, arcade classics) where falling makes no sense.

Step 1 — Define kb.pressing: It returns true every frame while the key is held down — continuous behavior.

Step 2 — Define kb.presses: It returns true only on the first frame the key is pressed — one-shot behavior.

Step 3 — Match each to a use case: Use kb.pressing('space') for something that should happen continuously while held, like charging up a jump or flying upward while space is held. Use kb.presses(' ') for a one-time action per press, like triggering a single jump — otherwise holding space would re-trigger the jump every frame.

Answer: pressing is true every frame the key is held (use for continuous actions like moving or flying); presses is true only on the first frame of the press (use for one-shot actions like jumping or shooting).

Step 1 — State the purpose of the check: player.colliding(ground) confirms the player is touching solid ground before allowing a jump.

Step 2 — Explain what happens without it: Every frame you press space — including mid-air — vel.y would be reset to -8, canceling the downward pull from gravity before it accumulates.

Step 3 — Describe the result: The player could jump repeatedly in mid-air (double-jumping, triple-jumping, infinite flight), rising as long as they keep tapping space. The ground check ensures the jump only fires when there's something solid beneath the player.

Answer: The check prevents mid-air jumps. Without it, pressing space repeatedly while airborne would keep resetting vel.y = -8, letting the player fly by canceling gravity's effect every frame.

Step 1 — Plan the logic: Check kb.pressing('d') first, then kb.pressing('a'), using an if/else-if chain so only one direction applies at a time, with an else branch stopping the player.

Step 2 — Write the code:

if (kb.pressing('d'))       player.vel.x = 4;
else if (kb.pressing('a')) player.vel.x = -4;
else                        player.vel.x = 0;

Step 3 — Verify behavior: Pressing D sets velocity right (+4), pressing A sets it left (-4), and releasing both keys hits the else, setting vel.x = 0 so the player stops immediately.

Answer: The if/else-if chain above gives A/D left-right movement with an automatic stop when neither key is held.

Step 1 — Name the property: .vel stands for velocity.

Step 2 — State its structure and units: It is a vector with .x and .y components describing how fast and in what direction a sprite moves.

Step 3 — Give the unit: Velocity is measured in pixels per frame, so vel.x = 4 means the sprite moves 4 pixels to the right each frame.

Answer: .vel is velocity — a vector measured in pixels per frame, with separate x and y components.

Step 1 — Trace the motion after the assignment: Setting vel.y = -8 launches the sprite upward at 8 pixels per frame (negative y means up on screen).

Step 2 — Bring in gravity: While airborne, world.gravity.y subtracts from vel.y every frame, so the upward speed shrinks: -8, then less negative, then zero at the peak of the arc.

Step 3 — Explain why it doesn't fly forever: Once vel.y reaches 0, gravity keeps working and makes it positive, so the sprite falls back down. Gravity acts continuously, so no constant velocity can hold forever unless you keep re-setting it.

Answer: The sprite rises, slows because gravity reduces vel.y each frame, momentarily stops at the arc's peak, then falls back down. It can't rise forever because gravity continuously opposes the upward velocity.

Step 1 — Locate the jump code: The jump sets player.vel.y = -8 when space is pressed and the ground check passes.

Step 2 — Identify the control value: The magnitude -8 is exactly what determines jump height — a larger negative number means more upward speed, so gravity takes longer to bring it to zero and the arc peaks higher.

Step 3 — Choose the change: Increase the magnitude, e.g. player.vel.y = -12.

Answer: Change the jump impulse value — make -8 more negative (e.g. -12) so the player launches faster and jumps higher.

Step 1 — Consider what happens each frame: Inside draw, vel.y = -8 runs every single frame, unconditionally.

Step 2 — Compare against gravity: Gravity adds its pull once per frame, but your assignment overwrites vel.y back to -8 every frame, so gravity never gets to accumulate.

Step 3 — Describe the result: The player rises at a constant 8 pixels per frame indefinitely — off the top of the screen and gone — regardless of keys or ground contact.

Answer: The player flies straight up forever at constant speed, because the per-frame assignment keeps resetting vel.y to -8 and gravity never gets a chance to slow it down.

Step 1 — Define setting .vel: Assigning .vel replaces the sprite's current motion — "you are now going this speed," full stop. Physics contributions get overwritten.

Step 2 — Define applyForce(): A force adds a push to whatever motion the sprite already has, and the physics engine computes the resulting movement. Units are Newtons, not pixels per frame.

Step 3 — Match situations: Direct key-driven walking suits .vel — the player should stop instantly when the key releases. A bomb knockback suits applyForce — you want to shove the player away on top of their existing movement, not erase it.

Answer: Setting .vel replaces current motion (good for direct controls like arrow-key walking); applyForce() adds a push to existing motion (good for knockbacks, explosions, or wind), letting physics blend it in.

Step 1 — Compare the units: vel.x = 3 means 3 pixels per frame — a visible, brisk walk. applyForce(3, 0) applies a force of just 3 Newtons.

Step 2 — Explain the mismatch: There is no conversion between pixels-per-frame and Newtons; force values work on a completely different scale, and typical useful forces are in the tens-to-hundreds range (the section's example used 120).

Step 3 — Practical takeaway: Expect to try a number, watch the result, and scale up — often by a factor of ten or more.

Answer: Because applyForce uses Newtons, not pixels per frame — 3 Newtons is a tiny push on that scale, so the barely-visible nudge needs a much larger force value to feel like movement.

Step 1 — Identify the goal: The knockback must push the player away from the bomb, whichever side they approached from.

Step 2 — Explain the comparison: If player.x < b.x, the player is to the left of the bomb, so pushing them away means pushing further left — the negative x direction. If player.x is greater, the player is to the right, and away means pushing right, the positive x direction.

Step 3 — Connect to the code: That is exactly what const direction = player.x < b.x ? -1 : 1; produces: -1 when the player is on the left, 1 when on the right. Multiplying by 120 in player.applyForce(direction * 120, -60) turns that into a push of the right size in the right direction, and the -60 adds a consistent upward lift on top of it.

Answer: Comparing player.x and b.x tells you which side of the bomb the player is on, so the sign of the horizontal force can be flipped to always push them away from the bomb rather than in one fixed direction. Without the comparison, a player hit from the right would be shoved further into the bomb.

Step 1 — Recall the defaults: Both bounciness and friction default to 0 in shPlay.

Step 2 — Apply the definition: bounciness = 0 means the sprite keeps none of its speed in a collision — it lands with a thud and stays put.

Step 3 — Conclude: Nothing is broken; the ball simply has the default bounciness of zero. To see a bounce, set ball.bounciness to something between 0 and 1.

Answer: The ball doesn't bounce because bounciness defaults to 0 — sprites keep none of their collision speed unless you explicitly raise bounciness.

Step 1 — Think about what a putt needs: After being struck, the ball should roll along the green and gradually slow down and stop — that's friction's job.

Step 2 — Assign friction: The green (ground) should carry friction. Giving the surface friction slows anything sliding across it, which is exactly how a real putting green behaves.

Step 3 — Consider bounciness: A golf ball does bounce slightly when it lands, but during a putt the important contact is rolling, not bouncing. If anything, modest bounciness belongs on the ball (it's the object whose rebound character matters), but for a pure putt simulation, friction on the green is the essential property.

Answer: Put friction on the green/ground so the rolling ball slows and stops naturally; bounciness, if modeled at all, belongs on the ball since it describes how the ball itself rebounds on impact.

Step 1 — State the units: angularVelocity measures turning speed in degrees per frame.

Step 2 — Interpret positive values: A positive value spins the sprite clockwise (increasing its rotation angle) — e.g., angularVelocity = 3 rotates the sprite 3 degrees clockwise each frame, like the spinning warning signs in §6.3.7.

Step 3 — Interpret negative values: A negative value spins the opposite way — counterclockwise — at the corresponding rate. E.g., -3 rotates 3 degrees counterclockwise per frame.

Answer: angularVelocity is in degrees per frame; negative values spin the sprite counterclockwise instead of clockwise.