Measure the container count instead of guessing it, and recalibrate - #203
Merged
Conversation
Owner asked, twice, whether Playwright could test this too. It can, and the answer changed a shipped balance number. The Vault Fragment thresholds rested on one figure: how many interactive containers a bunker actually holds. I had ESTIMATED it at 8-15 by reading spawnDecorInto, and said so in the code and the doc. Measured, it is about 7. Two runs of 200 generated floors landed at 6.3 and 7.4 — the estimate was between 1.3x and 2.4x too high. That was not a cosmetic error, because the vault needs BOTH items. At 28, the Golden Key took roughly 4.4 completely-cleared bunkers; a player opening a realistic ~70% of what they find had to play close to every day of the week to reach it. Anyone playing three to five sessions got the Paper, missed the Key, and therefore earned NOTHING — which is exactly the outcome this whole mechanic was built to make impossible. My own wrong estimate had reintroduced the failure it was fixing. Recalibrated to 8 and 18: the Paper lands on day one so the mechanic teaches itself early, the Key falls mid-week, and a four-session week clears both. That matches the arc in GAME-DESIGN.md §4. The measurement is kept as npm run measure:containers rather than thrown away, because props.js gaining or losing an interactive type silently moves the reward curve and nothing else would notice. It does not reimplement the generator: it builds a throwaway page carrying every DOM id DungeonGame.tsx renders — read out of that file, so it cannot drift — loads the fourteen real engine scripts into it, and mounts the engine at each depth. newGame -> descend -> ensureFloor is the same path a player takes. The award tests still pass against the new thresholds. The numbers remain a model, not player data: they assume one bunker per session and ~70% of containers opened, and both assumptions want a real week to check.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You asked, twice, whether Playwright could test this too. It can — and the answer changed a shipped balance number.
The measurement
The Vault Fragment thresholds rested on one figure: how many interactive containers a bunker actually holds. I had estimated 8–15 by reading
spawnDecorInto, and said so in the code and the doc.Measured with the real generator: about 7. Two runs of 200 generated floors landed at 6.3 and 7.4. The estimate was 1.3–2.4× too high.
Why that was not cosmetic
The vault needs both items. At 28, the Golden Key took ~4.4 completely-cleared bunkers. A player opening a realistic ~70% of what they find had to play close to every day of the week to reach it.
Anyone playing three to five sessions got the Paper, missed the Key, and therefore earned nothing — precisely the outcome this mechanic was built to make impossible. My own wrong estimate had reintroduced the failure it was fixing.
At 8 and 18 the Paper lands on day one so the mechanic teaches itself early, the Key falls mid-week, and a four-session week clears both — the arc in §4.
The measurement is kept, not thrown away
npm run measure:containers.props.jsgaining or losing an interactive container type silently moves the reward curve, and nothing else in the repo would notice.It does not reimplement the generator. It builds a throwaway page carrying every DOM id
DungeonGame.tsxrenders — read out of that file, so it cannot drift — loads the fourteen real engine scripts into it, and mounts the engine at each depth.newGame → descend → ensureFlooris the same path a player takes. The harness is deleted in afinally.Verification
Award tests re-run against the new thresholds — 12/12 pass, grants land on exactly 8 and 18, exactly once, never re-granted for an item already held by luck.
tsc --noEmitclean · lint 34 errors, unchanged frommain.Honest limits
The thresholds are still a model, not player data. They assume one bunker per session and ~70% of containers opened. Both assumptions want a real week to check — and the two measurement runs differing by 17% (6.3 vs 7.4) says the per-floor variance is high enough that a single bad week is possible.
Generated by Claude Code