Adding an Event

An event is anything that can happen in a chamber that is not a monster. A trap, a fountain, a merchant, a lever, a place to sleep. Each one is a file, and that is the whole design.

This is the cheapest thing in the project to extend. Adding an event costs one file and changes nothing else — no schema edit, no floor rewrite, no risk to the eight floors that already exist. Removing one costs deleting a file.

Why it works this way

It did not always. Until recently a room carried two fixed lists — feature could be treasure or fountain, hazard could be trap or warp — and that was the entire vocabulary. Adding a merchant meant editing the structure every floor depends on, and adding a lever after that meant editing it again.

The lesson generalises past this project: when a field's enum is the thing you expect to keep extending, it should have been a reference to a file all along. Monsters were files from the start and nobody ever had to widen an enum to add one.

The fields

Those four booleans and one check cover every event authored so far, which is the test a small schema has to pass. @Missing file is on-entry, not optional, one-shot, WITS against 12. @Missing file is the only one that is not one-shot, which is exactly what makes a warp room permanently a mistake. @Missing file is the shape most new events will take: when-safe, optional, one-shot, one roll.

Writing the resolution

onSuccess and onFailure are read by the GM at the table and followed literally. Write them the way you would write a rule, not the way you would write a scene.

State every number. Name every field that gets written. Say what happens on the sheet, not what it feels like:

Restore hp to _maxHp anyway — the water always pays out. Then take 1 point off ONE of the six on stats. You choose which, and it is permanent for the rest of the run.

That is a rule the GM cannot get wrong. "The water exacts a terrible price" is not.

Pools, not stock lists

An itemPool is what an event can produce, never what it holds. The GM draws drawCount entries from it and is told, in the rules, to vary the draw every time.

That indirection is doing real work. A language model asked to pick three items freely will pick the first three in the list, avoid the repeats that real chance produces, and drift toward whatever suits the delver's current build. Giving it a pool and a count removes all three failure modes at once. It is the same reason floors are chosen from a seed rather than by taste.

Events that sell

@Missing file is the only one so far, and it works because items carry a value in gold. Price is value × priceMultiplier, rounded up, and the multiplier lives on the event rather than the item — so a second, greedier merchant is one more file and no change to any item.

If you add anything that trades, put the price rule in the resolution text explicitly and never let it be inferred. An improvised price is the fastest way to make gold feel meaningless.

Adding one

1. Write the file into Room Events/. Give it a description a builder can read and a prompt a GM can compress.
2. Set the four behavioural fields honestly. In particular, do not mark something optional that the delver cannot actually refuse — an event that is presented as a choice and is not one is worse than an event that simply happens.
3. Place it. A room's event must name it, or nobody will ever see it. This is the step people forget: pushing the file makes it exist, and nothing more.
4. Give it an image. Events show a cover like anything else.

The one rule the GM has

It reads the file. It never runs an event from memory of what traps usually do, never puts two in one room, never adds one to a room that has none, and never quietly drops one that is inconvenient — [ID: EVNT].

That is what makes deleting an event safe: the rules for it left with the file.