Writing GM Instructions

The GM instructions are the actual rules engine. There is no hard-coded movement system, no combat resolver, no state machine — there is a set of markdown documents an agent reads and follows.

The index and the tags

[ID: CORE] is pinned and always in context. It is the master index: the loop in order, the standing rules, and a pointer to every other document. Everything else is loaded when it becomes relevant.

Each instruction is tagged [ID: TAG] and cross-references others by that tag. Keep them consistent — a body referencing [ID: FLOOR] after you have renamed the document to [ID: REGION] sends the GM looking for something that is not there.

The current set: CORE, MOVE, TILE, REGION, MAP, TOKN, SURVEY, EVNT, CMBT, LOOT, CHAR, NARR, NARR-BYTE, REG, and three TRG- triggers.

Triggered instructions have a hard limit

TRG- documents fire automatically — TRG-MOVE after every player message, TRG-HP and TRG-LOOT on file writes.

Their body cannot exceed 500 characters. The server rejects the push outright. Write the short version in the trigger and put the real explanation in the document it points at.

Triggers are configured with craft meta set-gm-trigger, not by editing the file.

Write prohibitions, not suggestions

The documents that work are the ones that say what must never happen, in language with no give in it. "Never compute a token position yourself" survives a long session; "try to use the computed fields" does not.

State the consequence when there is one. The map instruction explains that recalculating geometry lands tokens between hexes — the GM follows a rule better when it knows what breaks.

Give the reasoning for anything counter-intuitive

Two things in Tesserae read as bugs unless the instruction defends them:

Standing features never clear. Every instinct from dungeon crawling says a used thing is spent. [ID: TILE] and [ID: EVNT] both state the opposite explicitly, because the GM will otherwise mark a spring cleared and quietly delete the best tile in the region.

Nothing resets. [ID: SURVEY] spends its opening section on the fact that there is no run, no seed, and no start-of-game reset, because a GM carrying dungeon habits will helpfully wipe the player's save.

The register is a document too

[ID: REG] governs tone: materials over moods, one wrong thing per tile, evidence over atmosphere, daylight as the default state.

It is worth keeping separate from the length rule in [ID: NARR-BYTE]. One says how long, the other says what kind. Merged, both get ignored.