oregon-trail: data-driven cover art per screen, event, and location

#19 in Riparion/riparion-retro — merged 2026-06-10

What

A build-time cover-art system for Oregon Trail. Drop a square .jpg into games/oregon-trail/assets/covers/ named for a screen or moment and it renders as that screen's cover — no code changes. build.rs scans the folder and generates cover_asset(key), so "render if the jpg exists" is resolved at compile time (asset!() can't probe the filesystem at runtime in wasm).

How keys resolve

Most-specific-first: a narrative key supersedes the general Mode key when art for it exists. None present → nothing renders.

• General: trail, steady, game-over, … (the screen's Mode, kebab-cased)
• Narrative: trail-kansas-plains, steady-snakebite, game-over-victory, interaction-wagon-wheel-breaks, …

To support per-ending and per-incident art:

• EndGame gains a GameOverCause tag (prose unchanged, now keyed)
• Interaction::Message carries an optional cover key (message_keyed)
• the trail hub keys on the existing terrain() bands, refactored into a Terrain enum so the on-screen label and the cover slug share one source of truth

Full key list: games/oregon-trail/OREGONTRAIL_IMAGE_KEYS.md.

Discover keys by playing

In debug builds a small strip at the bottom of each screen lists that screen's candidate keys, marking the one that resolved to art — so filenames can be read off in-game. Compiled out of --release.

Tests

cargo test -p oregon-trail — 45 passed, including a new cover_keys test covering the supersede→fallback order for trail-location, steady, interaction, and game-over keys. Build-time asset!() generation verified end-to-end with a real jpg.

🤖 Generated with Claude Code