Stage 06 — Score, Feedback, Calibration

You will build: the feedback loop that makes a rhythm game learnable — combo, accuracy, a live early/late readout — and a calibration screen that adapts the game to any player's hardware. You'll learn: scoring math · designing feedback that teaches the player — and you'll make design decision 2 from the architecture doc. Warm-up — from memory: your judgment signal carries an enum and one more value. What is it, and why does this stage depend on it?

Why this exists#

Perfect/good/miss tells the player what happened; it doesn't tell them how to improve. The number that does is the signed timing error: "−23ms" means early, consistently — press later. Every serious rhythm game surfaces this, because it converts frustration into practice. And calibration is the same number aimed at hardware instead of habit: measure the player's total latency once, store it, subtract it always. Without it, your game is precisely wrong on every setup that isn't yours.

Build it#

A — Scoring#

Combo (consecutive non-misses), best combo, and accuracy — decide the formula deliberately: simple hit-rate, or weighted (perfect worth more than good)? Real games weight. Write the formula in a comment before the code; make the code match the comment. Display all three live; they reset per song.

B — The early/late readout#

On every judged hit, show the signed error briefly near the judgment line — early on one side, late on the other, faded quickly so it informs without nagging. Then play one song watching only that readout. You will find your own bias inside two minutes — that moment is the whole feature justified.

C — Calibration (decision 2)#

A screen: steady metronome tick (the conductor is already a metronome — reuse it), the player taps along, you collect the errors, and after ~16 taps the median is their offset. (Why median and not mean? One flubbed tap answers this — reason it out before looking anything up.) Store it in user://settings.cfg via ConfigFile; load it at startup.

Where the offset applies is the architecture's decision 2 — judgment only, or display too. Test both with your worst audio setup (Bluetooth if you have it), pick, record the choice and your reason.

D — Commit#

git add . && git commit -m "stage 06: scoring, timing feedback, latency calibration"

Checkpoint — definition of done#

• Combo, best combo, and accuracy — by whichever formula you chose and wrote down — display live and reset correctly per song
• The early/late readout works, and one play-session with it measurably changed your own timing bias (write the before/after feeling down — one line)
• Calibration measures, stores, survives restart, and visibly changes judgment when set to something absurd (±200ms — prove the plumbing with an extreme)
• Decision 2 recorded with your reason
• The judgment signal itself didn't change shape to support any of this — if it did, explain why the stage-03 design missed something (that's a real finding, write it down)

Stretch (no instructions)#

Grade the whole song at the results moment — S/A/B/C from accuracy — with thresholds you can defend out loud.

If you get stuck#

• Accuracy over 100% or negative → your weights and your divisor disagree; recompute one song entirely by hand on paper, then find where the code diverges from the paper.
• Calibration feels wrong even after measuring → is the offset applied with the correct sign? Flip it deliberately and observe; one direction obviously worsens things.
• The readout flickers or stacks → you're spawning a label per hit and never freeing them, or reusing one and fighting its tween. Pick one strategy on purpose.