…#242) (#243) * docs: fix the run instruction — the game cannot start from file:// Both README and CONTRIBUTING told people to open index.html directly. It has never worked: the game is native ES modules, browsers fetch module scripts in CORS mode, and a file:// origin is opaque, so the module graph is blocked outright. Verified in Chrome — the request fails with a CORS error and you get the UI shell over an empty canvas, which reads as a broken checkout rather than a wrong URL. Playing needs no setup at all, so that link now leads. Running your own copy needs a static server, which is one line and already installed. * fix: three places where the UI promised what the sim never did (#242) All three were found while diagnosing #74 ("bored in 10 minutes") and each one is a case of the game advertising a behaviour it did not implement. Each is pinned by a test that fails on the old code (mutation-verified: reverting any one fix reddens exactly its own two tests). 1. Memory Cache tier upgrades did nothing at all. src/sim/handlers/cache.js rolled job.req.cacheHitRate — a per-traffic -type constant (STATIC 0.9 / READ 0.4 / SEARCH 0.15) — and never looked at the node. So a $180 Tier-3 cache had exactly the hit rate of the free Tier-1 one, while the tooltip printed "65%" and cache_desc_long sold "upgrade tiers for higher hit rates". The CDN handler had always read the SERVICE's rate; this is Memory Cache catching up to it. A cache hit needs BOTH cacheable content and a cache big enough to still hold it, so the tier is applied as a multiplier against tier 1: min(0.95, req.cacheHitRate * (service quality / tier-1 quality)). Tier 1 resolves to exactly x1.00, which is deliberate: no shipped campaign level pre-builds an upgraded cache, so every level plays bit-for-bit as before and only a player who spends $120/$180 sees a difference. READ now goes 40% -> 57% -> 74%; the 0.95 cap keeps a tier-3 cache from retiring the origin for STATIC (0.9 unclamped would be 1.67). The tooltip now prints the rate the sim will actually roll for the commonest cacheable traffic instead of the raw tier quality, and cache_desc_long is corrected in all 11 locales (each translated in its own file's register, reusing that file's established glossary). 2. Random events expired on the wall clock. Deadlines came from Date.now(), so an event kept ticking while the game was paused and a "30-second" outage lasted 90 seconds of game time at timeScale 3 — three times the intended punishment, measured in the only clock the player experiences. Deadlines are game-time seconds now. The pause handler in game.js converts with it, and saves are unaffected (intervention state is rebuilt on load, never restored). This also makes events testable headlessly for the first time: tests/sim/achievements-proofs.test.mjs had conceded the bug in a comment ("times out events on the wall clock, which a headless run cannot advance"). 3. The survival ramp was frame-rate dependent. currentRPS closed 1% of the gap to target per FRAME, so a 144 Hz machine reached any given traffic level ~2.4x sooner in game time than a 60 Hz one — two players at the same elapsed time faced different games. Now exponential over dt, calibrated so one 60 fps frame still closes exactly 1% (shipped feel preserved on the reference machine, now identical everywhere). Because dt carries timeScale, fast-forward advances the ramp by game time rather than by frames drawn. smoothTowardsRPS and calculateTargetRPS are exported so tests pin the shipped curve instead of re-deriving it. Verified: 826/826 x5, eslint clean, mutation-tested per fix, and checked in the live browser modules (event deadline reads 130 game- seconds rather than an epoch stamp; the ramp lands identically at 30, 60 and 144 fps). * fix: end a live random event at the run boundary (#242 review) Adversarial review of the commit above found a REGRESSION it introduced, and it was the worst kind: invisible, and triggered by the most common action in the game. resetGame() zeroes STATE.elapsedGameTime but never touched STATE.intervention. Once event deadlines became game-time stamps, an event that was live when the player died and hit Restart had its deadline measured against a clock that had just restarted at 0 — so a TRAFFIC_BURST fired at t=400 held its 3x traffic for the next 430 seconds of the FRESH run, along with COST_SPIKE's doubled billing or a disabled node. Measured on this branch before the fix: before restart: {deadline: 430, burst: 3} after restart: {elapsed: 0, active: TRAFFIC_BURST, deadline: 430, burst: 3} t=1 .. t=429.9: burst still 3 Under the old wall clock the same stranded event self-cleared within 30 real seconds, which is why it had never been noticed. The fix is at the source rather than in the timing code: a run boundary ends the run's event. resetGame now calls endRandomEvent() (which reverses the effects) BEFORE the clock rewinds, and clears the deadline, the interval timer and the parked-event fields so a half-elapsed interval cannot fire early into a fresh session. Every reset path benefits — Restart, retry with the same architecture, New Game, and startCampaignLevel — including openMainMenu, which pauses through setTimeScale rather than handleGameState and so never ended events at all. Also fixed while the lines were open (pre-existing, reported by the same review): pausing an already-paused game overwrote the parked event with null, so the event never came back on resume. The guard sits INSIDE the pause branch — putting it on the branch condition would have fallen through to the resume branch and restarted the parked event while the game was still paused. Both are pinned by tests that fail on the unfixed code (mutation- verified). 820/820 x5, and confirmed in the live browser modules: restart clears burst 3 -> 1, and a double pause keeps the event parked without resuming it early.

Uh oh!

Getting bored in 10 minutes #74

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions