2.5 — Physics & Stats Studio: Catch Up and Tune

Unit 2 is the heaviest unit of the semester, and it arrived in one week: a physics body, a coin, a spike, a death rule and a health cap. Today it settles. Finish what is unfinished, then re-tune your movement — because 2.2 handed the moving to a Rigidbody2D, and every distance-per-second number you chose in 1.5 was chosen for a body that no longer moves you.

In the Editor ~30 min

Three jobs, in this order: finish the unit, then tune, then fix one thing. Tuning before the unit is finished tunes a game that is still changing underneath you.

Hierarchy → Inspector → open the Player and confirm Unit 2's parts are all present: the Rigidbody 2D from 2.1, and the movement script from 1.4 and 1.5. If the body is missing, that is the catch-up job — 2.1 adds it, and 2.2 replaces the old movement line with body.linearVelocity = direction * moveSpeed;.
Inspector → Rigidbody 2D → read Body Type, Mass, Linear Drag and Gravity Scale. These are the fields that decide what the world does back to your number.
Game view → play one straight line on flat ground for three seconds and measure how far the player gets. Compare it to the same test in 1.5. Change exactly one field, then measure again — two fields changed and one measurement is a guess, not a tuning pass.
Scene view → if any of 2.1-2.4 is unfinished, finish it here. The coin's trigger and tag (2.1), the spike's solid collider and the death rule (2.2), the potion and its cap (2.3), the prefab and the spawner (2.4).
Game view → fix the item at the top of your 2.4 playtest notes, not the one that is easiest. Then play the beat that item is about and confirm the change did what you claimed.
GitHub Desktop → commit with a message that names the field you changed and the number you chose, so the next tune has something to compare against.

Knob	What moving it changes	What you measure
`moveSpeed`	How far the player travels each second.	Distance covered in three seconds on flat ground.
Rigidbody 2D → Mass	How hard a solid push shoves the player around.	How far a spike or wall moves you at the same approach speed.
Rigidbody 2D → Linear Drag	How quickly the player stops once input stops.	Seconds between releasing the keys and standing still.
Rigidbody 2D → Gravity Scale	Whether the body falls at all. In the top-down Overworld it is 0.	Whether the player drifts downward over time — it should not.
`health`'s starting value	How many hits the player survives.	Hits taken before the death rule fires.
The potion's heal amount (2.3)	How much one potion restores before the cap stops it.	Health after two potions taken at the maximum.

A speed number is only true for the body it was tuned on. In 1.5 you moved the Transform directly, so moveSpeed was the whole story. In 2.2 the Rigidbody2D took over the moving, and it consults mass and drag on the way. The same number now produces a different distance — which is why today is a re-measure, not a re-read of last month's notes.

In the Code ~20 min

Nothing new gets written today. Two decisions from this unit live in a file rather than in a field, and a tune is the moment to check you can still say what they are.

Specification: where the numbers live.

Name the file and the field that holds each of these: the movement speed, the current health, the coin count, and the maximum health. Say them from memory first, then open the file and check.
StatManager is still the empty stub it shipped as. 2.1 showed you the alternative: a number can live on the object that persists, or on the object that disappears. Where does health live today, and which of those two is it?
If you moved health into StatManager now, it would survive a scene change. Is that a feature this game wants yet, or is it the job the 5.3 refactor exists to do? What would moving it early cost you this week?
The cap from 2.3 is a rule, not arithmetic. Which form did you use — a plain if, Mathf.Min(a, b), or Mathf.Clamp(value, min, max) — and which of them says "this value has a ceiling" most plainly to the next person who reads it?

Specification: the death rule.

What does dying actually do in your build — reload the scene by index, reload a scene by name, or reset the player without reloading? State it in one sentence without opening Unity.
If you reload, everything on PlayerController resets, the coin count included. Is that the rule you meant to choose in 2.2, and can you defend it — or did you inherit it by accident?
The spike reports a collision and the coin reports an overlap. Which of the two needs Is Trigger ticked, and what goes wrong in your build if you tick the wrong one?
Where does the player reappear after dying, and is that the same place a spawned coin from 2.4 would land? If those two answers differ, decide which is correct and say why.

Socratic: Tuning Is a Measurement

You changed one field and the player now moves the way you wanted. Which did you actually change — the number, or the body underneath it — and how would you tell the difference from the Game view alone?Your answer
Tuning one variable at a time means one measurement per change. Why does changing Mass and Linear Drag together and measuring once teach you nothing about which of them did the work?Your answer
Unit 2 is the heaviest unit in the semester and it earned a day to settle. In CSP terms (CRD-2, testing and refinement), what is the difference between "the game works" and "the game works at a value I chose on purpose"?Your answer

Checkpoint — before moving on, you must be able to:

Say whether 2.1-2.4 are finished, and finish any that are not
Re-measure your movement as a distance rather than a number, and name the Rigidbody 2D field that changed it
Name the file and field behind all four values: speed, health, coins, max health
State your death rule in one sentence and say what resets when it fires
Fix exactly one item from your playtest notes, then verify that it worked
Commit and push

Reference Docs

Need a deeper explanation? These pages cover the same concepts:

Unit 2: Stats & Pickups — the whole unit this studio settles
Triggers vs Collisions — the trigger-versus-solid decision, in full
Unity + C# Quick Reference — Rigidbody2D fields, Mathf.Clamp(value, min, max) and the physics callbacks

Next: 2.6 — Unit 2 Review + Second Playtest, where a new partner plays the fixed build and the two sheets get compared.

Student name0/3 answered

Answers save on this device as you type. At the end of class, click Download and upload the file to the Canvas assignment.

I finished this lesson

Saved on this device only — the Dashboard tracks your progress.