JesseMarkowitzandClaude Opus 5
4cab9fc41e
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
188 lines
6.9 KiB
Markdown
188 lines
6.9 KiB
Markdown
# The Ladder
|
|
|
|
A turn-based career simulation game that runs entirely in the browser. You
|
|
start at the bottom of an organisation and play turns — a day at a time —
|
|
making choices that move your money, your skills and your standing with the
|
|
people around you. There is no win state and no game over: a bad run means
|
|
worse options, not an ending, and you can stop whenever you like and read the
|
|
retrospective.
|
|
|
|
The engine knows nothing about offices, mailrooms or bosses. A **setting is a
|
|
content pack** — characters, events, choices, stat names and tuning, all data.
|
|
`corporateladder` is the default pack; a Wild West or lemonade-stand pack would
|
|
be new data and no new code.
|
|
|
|
## Status
|
|
|
|
Engine and the first content pack are built and tested. No UI yet — the game is
|
|
currently playable only from a test harness.
|
|
|
|
| Piece | State |
|
|
| --- | --- |
|
|
| Path-addressed state, conditions, effects | done |
|
|
| Seeded RNG, save/resume | done |
|
|
| Event selection, option gating | done |
|
|
| Turn loop, per-turn upkeep | done |
|
|
| Content validator + reachability tests | done |
|
|
| Corporate Ladder pack — 31 events, two tiers | done |
|
|
| Turn screen, retrospective, feedback widget | done |
|
|
| Local-storage save, file export/import | done |
|
|
| Single-file build | done |
|
|
| Calendar, scheduled wages and rent | done |
|
|
| Promotion from the mailroom to Dispatch | done |
|
|
| Repetition analytics (`npm run analyze`) | done |
|
|
| Played in a real browser | done — first playtest 2026-09-09 |
|
|
|
|
The first playtest confirmed the interface, saves and the exported log all work
|
|
in a real browser. Its findings — an unexplained daily drain, no sense of the
|
|
week, and an economy nobody could get ahead in — are what the calendar and the
|
|
retuned economy are for.
|
|
|
|
Note that the development machine has no browser that can render a page, so the
|
|
UI tests drive the real modules against a minimal fake DOM. That covers wiring,
|
|
not layout: **styling and dark mode are only ever verified by a human opening
|
|
it.**
|
|
|
|
## Playing it
|
|
|
|
```sh
|
|
npm run serve # then open http://localhost:8080
|
|
```
|
|
|
|
A server is needed during development because browsers refuse ES module imports
|
|
over `file://`. If port 8080 is taken, run `python3 -m http.server <port>`
|
|
instead.
|
|
|
|
To hand the game to someone else:
|
|
|
|
```sh
|
|
npm run build # writes dist/theladder.html
|
|
```
|
|
|
|
That is one self-contained file with the stylesheet and every module inlined.
|
|
It plays by double-clicking it — no server, no network, nothing installed.
|
|
|
|
```sh
|
|
npm test # 114 tests: engine, content, UI wiring, and the build
|
|
```
|
|
|
|
To see what a playtest actually did — turns against distinct situations, how
|
|
often each recurred, which locked gates players kept meeting, and anything they
|
|
typed into the feedback box:
|
|
|
|
```sh
|
|
npm run analyze -- theladder-feedback-2026-09-10-11-04-22.json
|
|
```
|
|
|
|
There are no runtime dependencies and no build step for development. Node is
|
|
used only to run the tests, the single-file build, and the log analyser.
|
|
|
|
## Layout
|
|
|
|
```
|
|
src/engine/ the game engine — imports nothing from content/, or from src/ui/
|
|
paths.js dotted-path get/set over state
|
|
conditions.js generic predicates: { path, op, value }, all/any/not
|
|
effects.js generic mutations: add/set/push/remove, with clamping
|
|
state.js pack -> schema and initial state
|
|
select.js which event fires this turn, which options are available
|
|
game.js the turn loop
|
|
rng.js seeded, serializable RNG
|
|
validate.js load-time content checking
|
|
src/ui/ screens, formatting and the app controller
|
|
app.js the only module that names a content pack
|
|
screens/ the turn screen and the retrospective
|
|
format.js state paths and conditions rendered as English
|
|
src/io/ local-storage save, file export/import, the feedback log
|
|
content/ content packs (settings)
|
|
tools/build.js flattens everything into one self-contained HTML file
|
|
test/ engine tests against a fixture pack; content and UI tests
|
|
docs/ DECISIONS.md — why things are the way they are
|
|
Planning/ the original design documents
|
|
```
|
|
|
|
**The rule that keeps this honest: nothing in `src/engine/` may import from
|
|
`content/`.** The engine names no stat, no character and no setting of its own.
|
|
|
|
## How content works
|
|
|
|
A pack declares what state exists and what it starts at, the relationship stats
|
|
every character carries, the characters, and the events. Everything else falls
|
|
out of that.
|
|
|
|
```js
|
|
export default {
|
|
id: 'corporateladder',
|
|
startingStage: 'mailroom',
|
|
|
|
state: {
|
|
'money': { initial: 1200, min: -5000, max: 1000000 },
|
|
'skills.negotiation': { initial: 1, min: 0, max: 100 },
|
|
'flags.took_loan': { initial: false },
|
|
},
|
|
|
|
// Expanded per character into relationships.<id>.<stat>, so adding a
|
|
// character adds its relationship state automatically.
|
|
relationshipStats: {
|
|
likes_you: { initial: 50, min: 0, max: 100 },
|
|
fears_you: { initial: 50, min: 0, max: 100 },
|
|
wants_to_help_you: { initial: 50, min: 0, max: 100 },
|
|
},
|
|
|
|
characters: [
|
|
{ id: 'boss', name: '...', role_type: 'boss', description: '...' },
|
|
],
|
|
|
|
events: [
|
|
{
|
|
id: 'mail_run',
|
|
stage: 'mailroom',
|
|
weight: 100, // relative likelihood among eligible events
|
|
description: 'A cart of mail and two hours to move it.',
|
|
options: [
|
|
{
|
|
id: 'hustle',
|
|
label: 'Get it done fast.',
|
|
requires: [{ path: 'skills.negotiation', op: '>=', value: 3 }],
|
|
effects: [
|
|
{ path: 'money', op: 'add', value: 40 },
|
|
{ path: 'relationships.boss.likes_you', op: 'add', value: 3 },
|
|
],
|
|
},
|
|
],
|
|
},
|
|
],
|
|
};
|
|
```
|
|
|
|
An event may also carry `once: true`, a `cooldown` in turns, and `requires`
|
|
conditions of its own. There is no separate notion of a random event: every
|
|
turn draws from the whole eligible pool by weight.
|
|
|
|
Conditions may read engine bookkeeping (`turn`, `stage`, `seen.<eventId>`,
|
|
`lastSeen.<eventId>`) as well as pack state. Effects may not write it.
|
|
|
|
A pack also declares `upkeep` — a list of `{ label, requires?, effects }`
|
|
applied at the end of a turn, after the choice. Adding `every` and `offset`
|
|
makes an entry periodic rather than daily: Corporate Ladder pays wages on
|
|
alternate Fridays (`{ every: 14, offset: 4 }`), charges rent every Monday, and
|
|
adds a loan service charge that steps up as the debt grows.
|
|
|
|
A pack may also declare a `calendar`:
|
|
|
|
```js
|
|
calendar: {
|
|
cycleLength: 7,
|
|
cycleName: 'Week',
|
|
unitNames: ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday'],
|
|
},
|
|
```
|
|
|
|
The engine derives `calendar.index`, `calendar.cycle` and `calendar.name` from
|
|
the turn number before each event is drawn, so content can require a Friday and
|
|
the interface can title the turn. Declare no calendar and there is no week.
|
|
|
|
Run `validatePack(pack)` when loading in development — it catches undeclared
|
|
paths, unknown characters, unusable ids, unreachable events and stages with no
|
|
fallback event, all of which otherwise fail silently mid-playthrough.
|