6.8 Joints

Step 1 — Recall the definition: A joint is a permanent relationship between two sprites — a constraint such as a shared pivot (HingeJoint), a fixed separation (DistanceJoint), or a sliding track (SliderJoint). Every joint connects exactly two sprites and is created once with new SomeJoint(spriteA, spriteB).

Step 2 — Explain what "enforced" means: Enforced means you state the rule a single time, at creation, and the physics engine applies it on every frame from then on. You never re-position the sprites yourself to maintain the connection — whatever else happens (gravity, collisions, other forces), the engine keeps the two sprites connected exactly as specified: the door stays on its hinge, the wrecking ball stays on its chain.

Answer: A joint is a constraint connecting two sprites so the physics engine keeps a fixed relationship between them (a shared pivot, a fixed distance, a slide track). "Enforced" means the rule is applied automatically every frame after being stated once — you never do per-frame work to maintain it.

Step 1 — State the default: By default, a HingeJoint's pivot is at the centre of the first sprite — the one written first in new HingeJoint(spriteA, spriteB).

Step 2 — Explain how to move it: Since the pivot is the first sprite's centre, you control the pivot by positioning that sprite: place the first sprite's centre exactly where you want the hinge point. That is why the chapter's examples hinge the bar to a small static post placed at the desired hinge location (e.g., post = new Sprite(450, 150, 12) puts the pivot at (450, 150)).

Answer: The pivot defaults to the centre of the first sprite passed to the joint. To pivot somewhere else, place the first sprite so its centre sits at that point — typically a small static "post" sprite at the spot you want the hinge.

Step 1 — Recall what a hinge does and does not do: A HingeJoint pins two sprites together and allows rotation — it enforces the connection, but it provides no support. A hinge holds two sprites together; it does not hold them up.

Step 2 — Apply that to a dynamic anchor: If the anchor sprite were dynamic, gravity would act on it too. The whole assembly — anchor plus bar — would stay connected but fall out of the sky together, swinging as it dropped.

Step 3 — Conclude why static is used: Making the anchor static fixes it in place, giving the moving sprite a fixed point to pivot around. That is what "stops the whole assembly falling out of the sky."

Answer: Because the hinge only connects the sprites — it doesn't support them against gravity. A static anchor is what holds the assembly up; without it, the entire hinged pair falls.

Step 1 — Recall the default rule: A DistanceJoint's length defaults to however far apart the two sprites already are at the moment the joint is created.

Step 2 — Spell out the consequence: Create the joint while the sprites are 80 pixels apart and the rope's length is 80; create them touching and it's 0. The length can then be read or changed afterwards through the joint's length property.

Answer: The current separation between the two sprites at the instant the joint is created — whatever gap they already have becomes the joint's length.

Step 1 — Describe the DistanceJoint: It keeps two sprites a fixed distance apart — like a rope. The ends can swing, rotate, and move anywhere at all, but they cannot separate further than the joint's length allows. Relative motion between the two remains free.

Step 2 — Describe the GlueJoint: It fuses the two sprites rigidly at their current positions — they become one solid object. There is no relative motion of any kind: the pair translates and rotates together as a single shape.

Step 3 — State the one-line contrast from the chapter: DistanceJoint says "stay this far apart, however you get there"; GlueJoint says "become one object." That's why the weight on a DistanceJoint lags behind the swinging bar, while a GlueJoint-fused weight moves exactly with it.

Answer: A DistanceJoint fixes only the separation, leaving both sprites free to swing and rotate relative to each other (a rope); a GlueJoint rigidly fuses them into a single object with no relative motion at all.

Step 1 — Identify what needs to change: The rope's length is the joint's length property, which is settable while the program runs. "Lengthen while the key is held" therefore means increasing joint.length on every frame the down arrow is down.

Step 2 — Pick the right keyboard check: kb.pressing('down') is true on every frame the key is held (unlike kb.presses('down'), which fires once per press) — exactly what "while the down arrow is held" requires.

Answer:

if (kb.pressing('down'))
  joint.length += 1;

where joint is the variable holding the DistanceJoint. Each frame the key is held, the length grows a little, so the rope continuously lengthens.

Step 1 — Identify what delete() affects: joint.delete() breaks the connection — nothing more. It does not reset, stop, or redirect either sprite.

Step 2 — State what survives: Both sprites keep exactly the velocity (and rotation) they had at the instant of deletion and continue moving unconstrained. A bar cut loose mid-swing flies off on a tangent rather than continuing to pivot.

Answer: Nothing — delete() only removes the constraint. The sprites carry on with whatever motion they had at the instant of release, now unconstrained.

Step 1 — Check what each class actually defines: Sprites define both remove() and delete() — two names for the same cleanup (§6.2.4). Joints define only delete().

Step 2 — Explain the error: Calling joint.remove() attempts to call a method that does not exist on joint objects, so JavaScript throws an error (joint.remove is not a function). Nothing is wrong with the idea of removing a joint — the method simply has a different name.

Answer: Because joints have no remove() method — only delete(). Sprites have both (as aliases), so sprite.remove() works, but joint.remove() calls an undefined method and errors.

Step 1 — Recall the danger: Calling delete() on an already-deleted joint is an error. A variable that still points at a deleted joint is a trap waiting for a second delete.

Step 2 — See what null buys you: Setting the variable to null does two things: it stops you reusing a dead joint reference, and it makes truthiness guards work correctly — if (kb.presses('x') && hinge) passes only while a live joint exists, so the delete() line is skipped once hinge is null. If the stale reference were left in place, the guard would still pass and the second delete() would crash the sketch.

Answer: So the variable stops referencing a dead joint. Since a second delete() on the same joint is an error — and a stale reference would still pass checks like if (hinge) — setting hinge = null after deleting makes the guard reliable and prevents the double-delete crash.

Step 1 — Create a static pivot sprite: A small sprite whose collider is 'static', so it holds the assembly up — remember, the hinge connects the sprites but does not hold them up.

Step 2 — Create the bar offset to one side: Place the bar's centre half its length to the right of the pivot, so its end sits at the pivot and it starts horizontal. A horizontal start means gravity has leverage on the free end, so it swings once released — a bar started hanging straight below the pivot would just sit there.

Step 3 — Join them with a HingeJoint: new HingeJoint(pivot, bar) — the first sprite is the anchor, and the pivot defaults to its centre.

Step 4 — Run it: The bar swings down and settles hanging straight below the pivot — a working pendulum from one joint and no motion code.

▶ Press Run to see the output…

Answer: The sketch above: a static pivot at (200, 80) and a 160-pixel bar hinged to it with new HingeJoint(pivot, bar). Released from horizontal, the bar swings down and settles hanging straight below the pivot.

Step 1 — Recall how often the callback can fire: draw() runs about 60 times per second, and an overlaps() callback fires on every frame the two sprites are overlapping — not once per touch.

Step 2 — Apply that to the swinging weight: The weight sweeps through the player's space, so a single pass can keep the two overlapping for many consecutive frames — a slow, long swing means a long overlap window.

Step 3 — Do the arithmetic: At 5 points docked per callback, even half a second of contact is roughly 30 callbacks — about 150 points gone for one brush past the hazard, instead of the intended 5.

Answer: Because overlaps() fires every frame of contact (~60 per second), one slow pass through the weight could dock the 5 points dozens of times — turning a 5-point penalty into 100 or more. A cooldown timer or a hit flag ensures the penalty applies once per contact.

Step 1 — List the four types with their jobs: All four are created the same way (new SomeJoint(a, b)) and removed with delete():

Answer: SliderJoint (a lift, piston, or drawer), WheelJoint (a vehicle's wheel on an axle), GrabberJoint (mouse-dragging a physics object), and GlueJoint (fusing several sprites into one solid shape).

Step 1 — Recall what a hinge controls — and what it doesn't: A HingeJoint only pins the two sprites at a point and allows rotation around it. It does not decide which way the bar swings; the swing direction comes from gravity acting on where the bar's mass starts relative to the pivot.

Step 2 — Locate the likely culprit: If the bar fires upward, its mass is starting on the wrong side of the pivot: the bar's new Sprite(x, y, ...) line has placed it above (or overlapping) the post instead of beside it at the same height. The physics solver starts from that bad configuration, and the correction plus gravity launches the bar up instead of letting it rotate down into a hang.

Step 3 — Classify the bug: The joint line, the argument order, and the static collider can all be perfectly correct — this is a positioning problem, not a joint problem. (A genuinely joint problem — swapping the arguments to new HingeJoint(bar, post) — would instead yank the assembly toward the post, since the pivot would jump to the bar's centre.)

Step 4 — State the fix: Match Try It Now 6.8.1's geometry: post at (450, 150), bar at (530, 150) — the bar's centre offset horizontally by half its length so its end sits at the pivot and the free end hangs down.

Answer: Most likely the bar's starting position — its new Sprite(...) coordinates put it above/overlapping the post rather than beside it at the same height. It's a positioning problem, not a joint problem: the hinge is created correctly, but the bar's mass starts on the wrong side of the pivot.

Step 1 — Recall what the correct vector points at: In the working code, dx = anchor.x - ball.x and dy = anchor.y - ball.y form the vector pointing from the ball toward the anchor — the recoil direction. Applying the force along it snaps the ball back through (and past) the anchor, like a released slingshot.

Step 2 — Work out what the reversed version computes: ball.x - anchor.x and ball.y - anchor.y point from the anchor to the ball — the same direction the player just dragged it. The magnitude is unchanged (it's the same stretch distance), but the direction flips by 180 degrees.

Step 3 — Predict the behaviour: On release, the force would push the ball further away from the anchor, continuing the direction of the drag: pull back and it sails away from you instead of launching forward. The slingshot fires backwards.

Answer: The ball would keep flying away from the anchor in the direction you dragged it, instead of launching back through the anchor — the shot is flipped 180 degrees. The launch speed would be the same; only the direction reverses.

Step 1 — Consider what the default length would be: Left at its default, the joint's length is whatever gap the ball and anchor had when the joint was created. Any nonzero value means the ball's resting position is a ring of that radius around the anchor, not the anchor itself.

Step 2 — See why that breaks the slingshot: The launch strength comes entirely from how far the player stretches the ball away from the anchor. With a nonzero resting length, small drags fall within the resting length — the joint isn't stretched, so nothing pulls back and releasing barely moves the ball. Only drags beyond the default would load the "band," and the ball would settle back onto a ring around the anchor rather than sitting on it.

Step 3 — Note why it's set explicitly, not just inherited: In the sketch the ball and anchor are both created at (100, 300), so the default distance happens to be 0 anyway — but writing joint.length = 0 makes the requirement explicit and robust: if you later nudge the ball's start position (say, so it's visible beside the anchor), the pattern still behaves as a zero-length tether where every pixel of drag is stretch.

Answer: Because the whole mechanism depends on the resting state being "ball exactly on the anchor." With length = 0, every bit of drag is pure stretch and the release force scales with the full pull-back; a leftover default length would give the ball a nonzero resting orbit, so small drags would store no pull and the launch would be weak or nonexistent.