story-to-pack
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 JesseMarkowitzandClaude Opus 5
|
4cab9fc41e |
Add promotion to Dispatch, and measure how repetitive a run is
The mailroom is no longer the whole game. Around turn 50, a player who has
built standing and either Marlene's goodwill or the nerve to ask gets offered
the Dispatch post — and can take it, take it and put Trevor up for the mailroom,
or turn it down, which is a real strategy rather than a mistake and comes back
after a cooldown.
Dispatch is eleven events of its own. The money problem is largely solved up
there and replaced by other people's days depending on yours, including the
mailroom's — which you used to be. Trevor branches on whether you recommended
him: he either runs the mailroom and has opinions about how it used to be run,
or he stays put and starts addressing you by your full title, kindly, in front
of people.
None of this is a promotion mechanic in the engine. It is
`{ path: 'stage', op: 'set', value: 'dispatch' }` on an option, since `stage`
was already how events are filtered. The reserved-write rule now allows it
narrowly — `set` only, and only to a stage that has events, both checked by the
validator, so a typo cannot strand the player in an empty pool. Wages differ by
rank through two upkeep entries gated on `stage`. The hard-times events dropped
their stage entirely: rent is due wherever you work.
The second half of this is the thing the last playtest asked for. A 183-turn
session, and no way to see how much of it was new ground.
`npm run analyze <exported-log.json>` now reports turns against distinct
situations, how often each recurred, which options were most used, which locked
gates players kept meeting, and anything they typed. The retrospective shows the
player-facing version.
It found a regression in this very change on its first run. Dispatch started
with eight events against the mailroom's nineteen, so its two floor events were
46% of every promoted run — one every three turns. Promotion was moving the
player into *thinner* content. Three more events and a weight rebalance took the
top two to 24.5%, and the heaviest recurrence from every ~3 turns to every ~5.
A test now holds that line.
Also corrected: the coverage test was asking whether an archetype ever *took* an
option, which is a property of the bot, not the pack. It had flagged
`rent_bounced.ask_trevor` as dead content when it had been offered, unlocked,
419 times across a sweep and simply never chosen. Options are now checked on
availability; events are still checked on firing.
114 tests. Reasoning in docs/DECISIONS.md §22-24.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMSFHyVPitUoosW5wyEADj
|
||
|
JesseMarkowitzandClaude Opus 5
|
e482f07157 |
Add the interface, then rebuild the economy around the first playtest
The MVP is playable: a turn screen, a career retrospective, an optional feedback widget, local-storage autosave with file export/import, and a build that flattens everything into one self-contained HTML file. A turn has two phases — the scenario and its options, then what the choice did and, separately, what the day cost regardless. Numbers that move without the player seeing why are most of what makes them meaningless. Locked options are shown greyed with the requirement spelled out rather than hidden, so a player can see the door they cannot open yet. The interface is named entirely by the pack. `pack.display` maps a state path to a label, a format and an order, which is why the header reads "Standing" for a path called `reputation` and why debt disappears while it is zero. The first playtest then found three things, all of them fair. *"Wasn't clear what daily drain was for."* The ledger was labelling changes by the path that moved — "Money −$18" — when the upkeep entry that caused them had a perfectly good name. It now says "Coffee, transit, lunch". The labels were in the data the whole time and never reached the screen. *"Should probably pay rent weekly / get paid every other week… would be good to have day of week and week # shown."* Packs can now declare a calendar, and the engine derives the day name, cycle and index from the turn number before the event is drawn — so content can require a Friday and the header can say "Thursday · Week 2 · Day 12". Upkeep entries take `every` and `offset`, making wages fall on alternate Fridays and rent every Monday. The turn screen carries a diary line — "Wages tomorrow · Rent in 4 days" — computed generically from whatever a pack schedules. *"Always in debt — could never get ahead."* The old economy bled $25 a day regardless of play. It is now roughly break-even at baseline, with a `spare_shift` event that appears *because* you are broke: the way out of a hole should be visible from inside it. Across archetypes a careful player ends around $1,400, an unplanned one treads water, and a careless one sinks into real debt. That retune broke the coverage test, usefully. Random play stopped reaching hard times at all, which made the entire debt branch look dead — it was not, since random play is not a plausible player. Coverage is now the union across five archetypes, including one that is broke *and* well-liked, because the "ask a friend for money" options sit in a state no single-axis strategy reaches. Not covered by any of this: styling and dark mode, which only a human with a browser can check. This machine has none that can render a page. 109 tests. Reasoning in docs/DECISIONS.md §14-21. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VMSFHyVPitUoosW5wyEADj |
||
|
JesseMarkowitzandClaude Opus 5
|
1d4ac0fdbd |
Add the Corporate Ladder pack, and two engine features it needed
Seventeen events across the mailroom: ordinary days, Marlene Hobb and Trevor Pike, a misrouted envelope that can be delivered or kept, and a hard-times branch that fires on negative money and always leaves an ungated way out. Writing real content turned up two things the engine could not express. Per-turn upkeep (`pack.upkeep`): the MVP spec wants recurring income and costs, but effects only run when a player chooses something, and baking wages into every option would be tedious and easy to get wrong. Upkeep entries carry their own conditions, which turned out to be enough for the loan service charge to be a three-step function that escalates with the size of the debt — no multiply operation, no engine change. Upkeep changes are recorded separately from choice changes so the UI can distinguish them. Per-character starting relationships: Trevor starts below the pack default on `likes_you` because he arrived two weeks earlier and has priced that in. Characterisation as data rather than as an opening cutscene. Nobody starts feared, either — `fears_you` defaults to 10, since a midpoint default would mean every new hire arrives already intimidating. The content suite plays 60 seeded runs and asserts every event fires and every option is taken at least once. That caught real dead content: Trevor's favour chain sat behind a gate no plausible player could reach, taking two events and a hard-times escape route with it, and debt could pass 5,500 while the service charge stayed flat, so the failure spiral flattened out instead of tightening. Both fixed in the data — the gate softened and given another route up, the loan capped and its charge tiered. The validator also gained a real fix: it counted an event with a cooldown as a stage's fallback, but a cooldown can exclude it, so a stage could still run dry. 86 tests. Reasoning in docs/DECISIONS.md §11-13, including the seeding trap that makes a correlated chooser look exactly like a content bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VMSFHyVPitUoosW5wyEADj |
||
|
JesseMarkowitzandClaude Opus 5
|
cc59b81155 |
Add the engine core: path-addressed state, data-driven turns
The planning docs commit to one thing above all: adding content must never
require touching the engine. This lays the foundation that makes that true.
All game state is addressable by dotted path (money, skills.negotiation,
relationships.boss.likes_you, flags.took_loan), and conditions and effects are
generic operations over those paths. The schema in the planning docs had
`requires: { skill, min }` and `effects: { money, skills, relationships }`,
both of which hardcode the state shape into the engine; the first gate wanting
a relationship threshold or a flag would have meant an engine change.
There is deliberately no "random event" category. Every turn filters the whole
event pool by stage and conditions and draws by weight, so a routine turn, a
rare interruption and the hard-times branch differ only in their data.
Also here, neither in the planning docs but both cheap and load-bearing:
- A seeded, serializable RNG. Runs replay exactly from seed plus choices, which
makes tests deterministic and playtest reports reproducible. The generator's
position is one uint32 living in the save.
- A load-time content validator. Undeclared paths, unknown character ids, ids
that cannot be path segments, events that can never fire and stages with no
fallback event are all caught on load instead of forty turns into a game.
The turn loop is a pure function, so a saved game resumes into exactly the run
it left — covered by a test that plays thirty turns, plays the same thirty with
a JSON round trip in the middle, and deep-equals the two.
72 tests, no dependencies. Reasoning recorded in docs/DECISIONS.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMSFHyVPitUoosW5wyEADj
|