Chapter 1

Why TropeLang

Every story has shapes moving inside it — a con, a betrayal, a mentor who turns out to be something else. A writer can name those shapes, but the names do no work on their own: they don't check the draft, don't notice when a setup never pays off, don't reveal that a quiet scene is secretly three tropes deep.

The premise behind TropeLang is that none of that labelling should be necessary. You can describe what happens — who is in the scene, what they are to each other, what they do — and TropeLang's evaluation engine recognizes the patterns. The project is therefore two parts: a small descriptive language for writing a story down as facts, and the engine that reads those facts for the tropes they satisfy.

The payoff runs deeper than recognition. Prose is built for a person to read top to bottom; a graph of facts is built to be worked with — queried, checked, reshaped, recombined. Once a story is structured, a dangling setup, a scene seen through one character's eyes, every story of a given shape — each becomes something you can find and act on directly, rather than re-read to reconstruct. TropeLang is, in the end, a way to accelerate how people work with narrative — to make it tractable as data without flattening what makes it a story.

Write what happens

A TropeLang source file (.trl) records what is so. It names a character, vale, a protagonist and a grifter; renn, his mark; in the first beat vale earns his trust, and in the next he betrays it. These are declarative facts about a graph — no control flow, no "if this then narrate that."

char vale [+Protagonist] [+Grifter]
char renn [+Mark]
scene the_con {
  beat 1 { vale -- renn : "earns his trust" }
  beat 2 { evt the_switch [&Betrays(agent=vale, target=renn)] }
}

The strip under the snippet is the second half at work. Nothing in the text names a trope, yet the engine reads the shape — trust given, then broken by the same hand — and confirms the turn outright, while listing larger tropes still in flight, each labelled with the beat it awaits. The strip recomputes on every edit. (How recognition decides is Chapter 4.)

The two halves

The two halves run at different times. The descriptive half is the language and its compiler: an author writes .trl text, which parses and validates into a graph and a network of recognition rules. The operational half is the engine: it watches facts arrive — from typing in this page, or from a host application emitting events — and matches them against those rules as they go, reporting what it sees.

That separation is the central idea. Whatever produces the events — a game's physics, a person at the keyboard — stays "blind": it knows nothing about narrative. TropeLang sits on top as the observer, reading a stream of plain facts as meaning. Everything else in this guide refines that one idea: what the facts are, how vocabulary works, how shapes are recognized, and how far the model reaches — into what characters know and stories nested inside stories.