feat(motion): raise the cruising speed, and make the show gates follow it

Pieces still read as slow. Cruising speed goes from 120ms per unit to 85: the
median departure across the shipped fifty drops 970ms → 763ms and a level's
whole animation budget 15.6s → 12.7s, about 18% off. The longest departures do
not move — the cap holds them at 3.46s — so if those still drag, the dial is the
cap, which was settled separately and is left alone.

The gates that guarantee a level opens with something worth watching are stated
in milliseconds, and they were picked while a piece crossed a unit in 120ms.
Held fixed while the speed changes, they stop meaning what they meant: this
change alone made 20 of the 50 shipped levels "fail" an opening gate every one
of them had passed, purely from the unscaled number. Scaled to the dial, none
fail — the set is unchanged, and the alarm was an artifact of the constant. So
the cruise threshold and the opening floor now derive from the speed, naming
the speed they were calibrated at.

exitTiming takes msPerUnit the way it already took knee and maxMs, and the
comparison lab gets a speed slider, reads the levels actually shipping rather
than the prototype sweep they were selected from, and totals every route in the
campaign instead of the four on screen — those four skew long, where the cap
flattens any speed change to 6%.

The test that pins constant cruising speed now reads the dial from the token
instead of hard-coding 120, so tuning motion no longer looks like a broken
guarantee.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
cabinw
2026-09-14 18:46:32 +08:00
co-authored by Claude Opus 5
parent 34e6e73016
commit 073b682234
9 changed files with 88 additions and 43 deletions
+9 -5
View File
@@ -1,6 +1,6 @@
import test from 'node:test';
import assert from 'node:assert/strict';
import { PIGMENTS, LEVEL_THEMES, contrast, themeForScore } from '../src/design-tokens.js';
import { MOTION, PIGMENTS, LEVEL_THEMES, contrast, themeForScore } from '../src/design-tokens.js';
import { Game, clone, validateLevel, available } from '../src/core.js';
import { LEVELS } from '../src/levels.js';
import { drawExit, drawScene, CanvasPainter, exitGeometry } from '../src/renderer.js';
@@ -55,15 +55,19 @@ test('motion ramps gently at both ends, never reverses or overshoots',async()=>{
test('routes below the knee cruise at one speed; longer ones accelerate instead of dragging',async()=>{
const {exitTiming,travelProgress}=await import('../src/exit-animation.js');
// Below the knee the old guarantee still holds exactly: same cruising speed
// for every piece, no cap. distance*120 stays under 2400ms up to distance 20.
// for every piece, no cap. The speed itself is a tuning dial, so it is read
// from the token rather than written in — pinning the number here would make
// every speed change look like a broken guarantee.
const perUnit=MOTION.exitMsPerUnit;
assert.ok(20*perUnit<MOTION.exitMaxTravelMs,'距离 20 以内必须还在拐点以下,否则下面的匀速断言就测不到匀速段');
for(const distance of [1,5,15]){
const timing=exitTiming({travelPoints:[{x:0,y:0},{x:distance,y:0}],steps:[]});
assert.equal(timing.travelMs,distance*120+Math.min(80,distance*40));
assert.equal(timing.travelMs,distance*perUnit+Math.min(MOTION.exitRampMs,distance*perUnit/3));
const t=timing.travelMs*.5,dt=1;
const speed=(travelProgress((t+dt)/timing.travelMs,timing.travelMs)-travelProgress(t/timing.travelMs,timing.travelMs))*distance;
assert.ok(Math.abs(speed-1/120)<1e-9);
assert.ok(Math.abs(speed-1/perUnit)<1e-9);
assert.equal(travelProgress(0,timing.travelMs),0);assert.equal(travelProgress(1,timing.travelMs),1);
assert.ok(Math.abs(timing.duration-timing.travelMs-180)<1e-9);
assert.ok(Math.abs(timing.duration-timing.travelMs-MOTION.exitEffectMs)<1e-9);
assert.equal(timing.capped,false);
}
// Past the knee the piece speeds up so the journey stays watchable. Uncapped