Malte Langkabel
b0fffdb00f
Second seam of the GameWorldView decomposition: the view no longer owns a scroll position, only the pan intent and the bounds. WorldCamera works purely in world units — tiles and tiles per second, never pixels. That is what keeps it independent of WorldCoordinates: the two meet only where GameWorldView feeds getViewCenterXTiles() into the transform, and neither knows the other exists. Two things are passed in rather than reached for, both so the camera stays a plain value with no simulation dependency: - ScrollBounds, because the pan limits move with asteroid expansion and with pushes. The camera clamps on every advance(), not only when panning, so the view follows the bounds inward when they shrink. - PanDirection, because pan intent is not the camera's business. Today GameWorldView collapses its two held-key flags into it; if controls become rebindable the camera's interface does not change. The config structs are referenced, not copied: they live inside the Simulation's GameConfig, which is assigned in place on restart (REQ-CFG-RELOAD), so reloaded scroll tuning takes effect without rebuilding the camera. A test pins that. The pan-speed curve (REQ-UI-SCROLL-SPEED) had no coverage at all and is the least obvious code in the file — two ramps combined by min, with a peak below the fast speed where the bands overlap in a narrow contest zone, and a hard step when the band width is zero. All of that is now tested. Behaviour is unchanged, including the cases worth naming: holding both keys still cancels out, and the moved/not-moved result that drives the box-select refresh still counts movement caused purely by the bounds changing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K