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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user