2 files changed, 193 insertions, 0 deletions
diff --git a/wiki/if/messages-and-announcements.md b/wiki/if/messages-and-announcements.md
new file mode 100644
index 0000000..d4e0958
--- /dev/null
+++ b/wiki/if/messages-and-announcements.md
@@ -0,0 +1,78 @@
+# Messages and Announcements
+
+## Motivation
+
+Maintain a prosaic tone and delivery throughout interactions with the simulation.
+
+Support gameplay elements that alter the character's perception of the world, and represent those effects to the player.
+
+## Ultimate Disposition
+
+All messages are eventually disposed in one of two ways:
+
+* displayed, marked up, on the web UI, or
+* discarded.
+
+For the purposes of the following, the builtin function `notify()` delivers raw Markdown to the UI, which handles markup conversion and presentation. The method `:notify(args...)` applies unspecified transformations on `args...` before delivering the result to `notify()`.
+
+## Kinds of Messages
+
+* Diegetic messages deliver an approximation of the sensory response to events in the simulated environment.
+
+    * Diegetic messages should be tagged, internally, with the sense or senses perceiving the events, so that simulated sensory effects can modulate the message. It should be possible for a deaf character's player to "see" lips moving, while a fully-hearing character's player should insead "hear" the words spoken.
+
+* Non-diegetic messages deliver information about the state of the simulation, or about the player's interaction with the simulator.
+
+## Processing Models
+
+### Parallel Entry Points
+
+In this model, there are separate entry point methods for diegetic and for non-diegetic messages. Each entry point performs appropriate processing, then calls into internal methods shared by both message forms to deliver messages to the UI.
+
+This model requires more names and is slightly more complex to explain, but splits the responsibility for output delivery from the responsibility for accepting non-diegetic messages, leaving each piece conceptually simpler.
+
+### Diegetic Filter Methods
+
+In this model, the internal methods are the entry point for non-diegetic messages directly, as they have no processing to perform. Diegetic messages instead call the non-diegetic machinery after performing any diegetic message effects.
+
+This model requires fewer names, and avoids what will in practice be a layer of "do-nothing" methods where non-diegetic entry points blindly call internal helpers, but combines the responsibility for non-diegetic output with message delivery.
+
+## APIs
+
+### Primary Diegetic Verbs
+
+* `recipient:you_SENSE(args...)`: a family of methods for delivering diegetic messages. Each SENSE (`you_hear`, `you_see`, `you_smell`, `you_feel`, `you_taste`) either delivers args to `recipient:notify` (see below) and returns `$true` (indicating that the recipient was capable of experiencing that sense) or ignores the arguments and returns `$false` (indicating that the recipient was not capable of experiencing that sense).
+
+    The default implementation is equivalent to `return this:notify(@args);`.
+
+* `recipient:you_SENSE_lines(lines)`: applies with `you_sense` to the elements of `lines` in order, each of which must either be a single string (passed as the first argument of the corresponding `you_SENSE`) or a list (passed as the argument list to the corresponding `you_SENSE`). Returns `$true` if every line is accepted by `you_SENSE`, or `$false` if any line is rejected. Processing stops at the first rejected line.
+
+These methods are designed to be chained, to make it simpler to simulate partial impairment while allowing the game's prose to focus on the most appropriate "available" sense for each character.
+
+```
+player:you_hear(spoken_message) || player:you_see(lips_moving_message);
+```
+
+In spite of the names, these methods _do not_ prepend "You hear" to the output. The naming distinguishes single-recipient messages meant to be sensed by a single object from messages to be delivered to the occupants of a container or room:
+
+* `room:SENSE(args...)`: calls `you_SENSE(args...)` on every occupant of `room` who is not than `player`. Returns a list of objects for which `you_SENSE` returned `$false`, for use in `room:SENSE_only` (below). Skips `player`, to ease simulating situations where the character's self-perception has unique prose ("You say" vs. "Toby says").
+* `room:SENSE_all(args...)`: calls `you_SENSE(args...)` on every occupant of `room`. As with `room:SENSE`, this returns a list of objects that were unable to sense the simulated event.
+* `room:SENSE_all_but(nonrecipients, args...)`: calls `you_SENSE(args...)` on every occupant of `room` that is not in `nonrecipients`. As with `room:SENSE`, this returns a list of objects that meet those criteria that were unable to sense the simulated event.
+* `room:SENSE_only(recipients, args...)`: calls `you_SENSE(args...)` on every occupant of `room` who is in `recipients`. Returns a list of objects that are in `room`, which are in `recipients`, which could not `you_SENSE` the message.
+
+As with the single-recipient methods, these are meant to be chained, but the structure of a chain is different:
+
+```
+player:you_hear(you_say_message) || player:you_feel(your_lips_move_message);
+unsensed = room:hear(heard_say_message);
+unsensed = room:see_only(unsensed, lips_moving_message);
+unsensed = room:smell_only(unsensed, smelly_breath_message);
+```
+
+### Primary Non-Diegetic Verbs
+
+* `recipient:tell(args...)`: a method for delivering non-diegetic messags. Delivers `args` to `recipient:notify` unaltered. Returns nothing.
+
+* `recipient:tell_lines(lines)`: applies `tell` to the elements of `lines` in order, each of which must either be a single string (passed as the first argument of `tell`) or a list (passed as the argument list to `tell`). Returns nothing.
+
+* `room:announce(args...)`, `room:announce_all(args...)`, `room:announce_all_but(nonrecipients, args...)`, and `room:announce_only(recipients, args...)` mirror the behaviour of their diegetic equivalents, calling `tell` on each appropriate occupant. However, these methods return nothing, as they are not expected to be chained.
diff --git a/wiki/if/narrative-in-muds.md b/wiki/if/narrative-in-muds.md
new file mode 100644
index 0000000..72cc262
--- /dev/null
+++ b/wiki/if/narrative-in-muds.md
@@ -0,0 +1,115 @@
+# Narrative in MUDs
+
+Design notes towards narrative conventions.
+
+## What?
+
+MUDs are engines of narration. The human interface to one is, to a first approximation, literary: everything that happens is realized as words, which are read, and the user's actions on the system are performed through writing.
+
+MUDs are a distinct subform of interactive fiction. In classic IF, the IF engine produces a single narrative, with which a single player interacts (usually synchronously - each narration by the engine leads to a single reply from the player, which then leads to further narration). MUDs, by contrast, produce _parallel_ narratives. Each player receives their own, distinct narrative, which depicts events happening in a shared fictional space. Furthermore, these narratives conventionally occur asynchronously, with replies from each player injecting further text into many players's narratives.
+
+For example, the following three narratives depict the same sequence of events, as presented to three distinct players.
+
+First, Alice's perspective:
+
+> You open the door and enter the house.
+>
+> -----
+>
+> **Living Room**
+>
+> You're in the sparsely-furnished living room of an insipidly-generic student apartment. A TV sits on a bench, opposite a cheap and decrepit sofa. The front door opens to the south; beside it is an indifferent pile of salt-stained boots.
+>
+> Bob is here. cherise is here, seated on the sofa.
+>
+> -----
+>
+> You say, "Hello."
+>
+> cherise says, "Called it."
+>
+> Bob walks out through the front door.
+>
+> You ask, "What's his problem?"
+
+Then, Bob's:
+
+> cherise sighs. "I'm sure she'll be here soon."
+>
+> Alice walks in through the front door.
+>
+> Alice says, "Hello."
+>
+> cherise says, "Called it."
+>
+> You open the front door and walk out.
+>
+> -----
+>
+> **Hallway**
+>
+> You're standing in a grungy apartment hallway. It smells faintly of mildew and old cigarettes. An apartment's front door opens to the north.
+>
+> -----
+
+Finally, cherise's perspective:
+
+> You sigh. "I'm sure she'll be here soon."
+>
+> Alice walks in through the front door.
+>
+> Alice says, "Hello."
+>
+> You say, "Called it."
+>
+> Bob walks out through the front door.
+>
+> Alice asks, "What's his problem?"
+
+I've intentionally used widespread MUD narrative conventions to illustrate some points.
+
+In daily life, this sort of parallel experience of overlapping events and partial perspectives is unremarkable. In interactive fiction, it's nearly unheard-of, outside of MUDs, and in the context of literary fiction, it raises some complex questions:
+
+* Who is Alice's narrator? Or cherise's?
+* Just how many narrators _are_ there? Do the participants share a common narrator, or are they each an independently narrated story?
+* The three perspectives shown here are the limited perspectives of each participant in the scene. Is there also an omniscient perspective? If so, does it have a coherent narrative? Is there anything about the scene that one narrator might omit, where another would include it?
+* Why does the narrator present those specific elements of the _places_ each perspective visits, and how do those choices related to choices of perspective, tense, and person? Do Alice and cherise see the living room the same way? Should they?
+* Why the second person?
+* Why the present tense?
+
+## Some Bad History
+
+MUD narrative conventions largely arise from technical choices themselves motivated by the context MUDs arose in. MUDs originated as the product of a literarily-unsophisticated technical community: early MUDs were engines for sharing swords-and-sorcery adventures with friends, little more than multiplayer-enabled versions of Zork or Colossal Cave (themselves somewhat limited renditions of a quest story).
+
+Even later "talker" MUDs, designed specifically around social interaction rather than around adventure, and "VR" MUDs, designed around simulating elements of a shared space through text, derive a lot of narrative conventions from those ancestors.
+
+This ancestry has some consequences.
+
+The narrators of Zork and Colossal Cave speak in the second person; the protagonist character is a faceless, ageless, genderless proxy for the player, and this allows the narrator to conflate the two to effectively engage the player with the fictional world. Early MUDs ape this convention, but MUD characters _require_ names, since it's impractical to describe more than two characters in a narrative without some way to identify each character. The second person convention persists in those systems, even though the player and the character could (and often did) have divergent identities.
+
+Not every game uses the second person effectively. Games with a freeform 'pose' affordance allow players to inject player-constructed prose into the narrative to reflect actions not pre-envisioned by the game's authors. This almost universally breaks from the second person; a single line of prose provided by the player is not usually corrected for personal pronouns by the game before being delivered back through player narratives. If cherise runs the command
+
+> `pose waves at Alice.`
+
+most MUDs will generate the prose
+
+> cherise waves at Alice.
+
+in all three of Alice, Bob, and cherise's narratives, even though cherise's other actions in cherise's narrative are presented using the pronoun "You."
+
+This can be particularly jarring when some poses have codified support (and correctly substitute pronouns) and others do not (and rely on a generic `pose` system).
+
+## Extra-narrative Information
+
+Interactive fiction mixes narrative and extra-narrative information into the prose freely. Even discounting the player's input (which generally has a different tone and structure than the game's narrative), various gameplay situations require the presentation of non-narrative information. For example, nonsense inputs require _some_ response, so that the player understands that the game hasn't understood hem, but that response describes the input-processing behaviour of the game, and doesn't narrate the story the game is telling.
+
+Most IF games present this output through the same prose flow as the game's narrative, mixed indifferently with descriptive text. The obvious alternatives (of non-textual or non-narrative output) is, empirically, distracting: it forcibly reminds players that they're interacting with a machine, while prosaic output blends acceptably with the narrative. Thus:
+
+> `> flarp`
+>
+> I didn't understand that.
+
+is preferable to a beep, or to turning the input region another colour.
+
+For some reason, this is one of the few situations where IF narrators refer to _themselves_. Is the narrator in fact a mediator, with an active role in the story being told?
+