Aims:
• Scene-based, not map-based.
• Partly intended to drive Inform 7’s development. Tool design via “write the manual first”
• Without variables for as long as possible.
• Without the 3D's -- doors, darkness, and directions -- for as long as possible.

Examples within won’t compile or work correctly (mostly on purpose).   Caveats:
• A room is required
• Can't refer to an unnamed room with "the location" like that.
• The block rules interfere with the perfect-present tense.  Only LOOK and WAIT actually work unless rules are written.
• “Instead of looking, do nothing.”  Needed
• The display banner rule is listed before the start in correct scenes rule in the startup rules.  [for neatness’s sake]
• assumes Glulx (uses indexed text quickly)
• assumes "we have waved the candle twice" and “we have snuck at least five times” works (bug reported, with possible solution, to Graham)
• assumes "Act I ends when the player's command includes..." works correctly
• assumes all those other bug reports I just sent to Graham work
• assumes “Entire game ends when Act III ends.” actually ends the game (postpones rules & phrases until much later!)
• assumes the slash works on verbs in Understand “go/leave” as…
• how much text can one say phrase take?
• assumes:  Inputting is an action applying to one topic. Understand "[text]" as inputting.

[TODO: check the variations on ended, has ended, ends, happened, happening, has happened, ended well, happened well, etc., etc., etc., in combination with scenes with one unnamed ending, one named ending, multiple named endings, multiple unnamed endings (illegal?), and mixed named & unnamed endings ]

Scenes 

Our first example will be minimally interactive.  

	 Act I  is a scene. [1] "Once upon a time, ..." [2]
	 Act I  begins when [3]  the entire game  begins. [4]
	 Act I  ends when [5]   the player’s command  includes “go” . [6]

	Act II  is a scene. "He arrived at her castle, but ..."
	Act II  begins when  Act I  ends. [7]
	Act II  ends when  the player’s command  includes  “enter”  .

	Act III  is a scene. "She could not tell him that..."
	Act III  begins when  Act II  ends.
	Act III  ends when   the player’s command  includes  “kiss”  . 

	The entire game  ends when  Act III  ends. [8]

• By sentence [1] we create and name a scene.  This line is necessary so the computer will know that that name refers to a scene, rather than a prop or action or character, etc.
• Immediately following [1], within the quotes at [2], we write.  The computer will quote us to the reader when that scene begins.
• Line [3] tells the computer when the scene begins.  "The Entire Game" at [4] is a scene built-in to Inform.  Our scenes divvy it up.  
• Line [5] tells the computer when the scene ends.  "The player's command" represents whatever our reader types in.  "Includes" asks if the following word(s) appears anywhere within what our reader typed in.  (We could also use "matches" instead of "includes" to require an exact match of the reader's entire written line, but inclusiveness is generally a good thing.) 

We then write the other scenes in the story similarly, daisy-chaining them with sentences like [7]. 

Finally, we again use the included Entire Game scene to indicate which of our scenes is the final one.

Now play the work by clicking the green PLAY or GO button. 

Alternate Scenes

For our fiction to become an interactive one, we should allow our readers some choice in how things play out.  To do this, we write more than one ends-when line for the preceding scene.  Using our previous example, we first remove the existing sentence that ends Act II by putting square brackets around it.  The text will turn green, and the computer will ignore it.  (This is handy in case we want to restore it later. It saves typing.) Then we define two ways that Act II can end, one sentence per each.  Finally, we remove the original Act III similarly, and write two versions of it named Act IIIa and Act IIIb. 

	Act II ends when the player’s command includes “enter”.
	Act II ends  well  when the player’s command includes “enter”.
	Act II  ends  poorly  when  the player’s command includes “leave” .

	Act III  begins when  Act II  ends  well .    [ named the ending “well” ]

	Act IIIb is a scene. "She could not tell him that..."
	Act IIIb begins when Act II ends  poorly .
	Act IIIb ends when  the player’s command includes “kiss” .

	The entire game  ends when Act IIIb ends. 

We have two sentences describing the end of Act II.  The middle blank names the particular ending, and as with all our earlier names for things, the computer does not presume to understand it.  We chose single adverbs "well" and "poorly" for names here, but phrases such as "in a dead panic" work just as well.  

Try playing through the example thus far.  

One standard Inform 7 testing command is the SCENES command.  When we, the author, are playing our work within the Inform 7 authoring tool, we have a handful of testing commands that will show us additional information about how our work is, well, working.  Though we enter them where our readers enter their text, these testing commands are automatically removed when we "release" (publish) the work.  Try entering scenes on the very first prompt, and playing through the above work to get a feel for what that testing command does.  When we encounter actual problems during authoring and play-testing, being comfortable with testing commands will help in diagnosis.

Clueing the Reader

In printed Choose-Your-Own-Adventure books, each page ended with an explicit list of actions with a new page number for each.  Frequently those choices had the typographical convention of boldface to make them stand out from the rest of the prose, perhaps to reinforce the reader's agency in the reader's own mind.  In our example so far, we have not explicitly told our reader what words advance the story.  Let's append that to our second scene now, complete with typographic convention.

Act II is a scene. "He entered the tower room, but she was not there.  Her makeshift prison included a bed, wardrobe, and hope chest.  Upon the wardrobe was a glass box, in which he saw her engagement ring.  Beside it was a ripe apple, apparently untouched.

He could [bold type]eat the apple[roman type] or [bold type]wear her ring[roman type]."

Square brackets within our prose are treated specially.  There they contain instructions to the computer, such as turning boldface on and off.  Other widely-used say phrases are [line break], [italic type], [‘], and [run paragraph on].  We will see more of these soon.

There is a reason that the multiple ways of ending a scene do not automatically display themselves for the reader:  flexibility.  Unlike printed books, we can offer secret actions that our reader must intuit for herself.  We can reward or require our reader's wits, empathy, or thoroughness in searching for a better answer than is initially offered.  

In the latter case, the reader may not guess the exact word for the hidden path.  For this, we have a way of indicating synonymous words and phrases.  

Act II ends insightfully when the player's command includes "leave/exit" or "walk away".

For words, placing a forward slash between them (without surrounding spaces) allows the reader to use either of them.  For phrases, a second quoted piece following an "or" is necessary, as the slash only treats as synonymous the single words it directly connects.  (Or to put that another way, the power of the slash ends at a space.)  This peculiar kind of text that recognizes other, written text, rather than being intended for itself being read, we call topics.  It isn't found outside of computing.  It is the most primitive example belonging to a discipline of artificial intelligence:  understanding natural language.

A Scene with Multiple Beginnings Join Together Disparate Endings

Allowing alternate scenes implies that many scenes we write won't be read on a particular read-through.  Plus, the number of scenes to be written, even if each one only allows two options, grows rather large rather quickly.  One solution for this appends a single scene after two (or more) others, effectively tying together multiple threads.  That scene will have multiple beginnings. 

	Act IV begins when Act IIIa ends.
	Act IV begins when Act IIIb ends.

Rather than writing two identical, or even slightly different versions of Act IV, we write only one. To smooth the transition from either preceding scene into this one, another pair of say phrases adapt the prose accordingly.  

Act IV is a scene. "[if Act IIIa has ended]Leaving Darla's apartment, you..[end if][if Act IIIb has ended]Leaving Joe's bar, you...[end if]  When, rounding a corner, you notice you are being followed..."

The combination of [if ...] and [end if] work as a pair, similar to [bold type] and [roman type].  Rather that the text between the insertions being in a different typeface, the text will either appear or not.  By wrapping each transition from the previous scenes with such a construction, our prose adapts to the history of the story so far with minimal work from us.  

We can also use this to reference earlier reader choices.  The say phrases can reference any scene, not just the preceding one(s).  Any scene can be asked whether or not it has happened (meaning begun), is happening, or ended (in a particular way).  

	"[if Act II ended well]…[end if]"
	"[if Act II ended poorly]…[end if]"
	"[if Act II ended on your own side]…[end if]"

Note that we cannot ask in what way a scene began.  But we can get the same effect by asking if each of the previous scenes ended.  ("Ended" implies that it began, of course.)  So instead of something like "if Act IV began with Act IIIa" we would use "[if Act IIIa ended]".

(“ended” requires the name of the ending. “has happened” will not allow the name of the ending.  But, “has happened” implies “ended in any way”?  Does "ended" mean any ending in the case where there is no unnamed ending? ..and the unnamed ending otherwise?)

Traveling Paragraphs

The preceding section gave us a technique to adapt some text according to which scenes have or haven't come before.  Occasionally we have the opposite situation:  some text needs to appear in multiple scenes.  This happens when it carries important story information but when to present it depends on extant concerns.  Perhaps the reader will see only one of those scenes, or perhaps a selection of several scenes need occur first.  Rather than copying the same text into multiple places, which is bothersome to remember every time we revise it, we can create a say phrase just for itself:

To say  the bit about the hotrod :  say "He had gotten a 1970 Pontiac Firebird on his sixteenth birthday as an old clunker, paid for by his own earnings from the bowling alley.  Many days were spent under the shade tree in the backyard, under the Firebird in its engine, or in its transmission, or its cabin, tinkering, tweaking, polishing.  Arnie spent most of his later teen years on that car, and thirty years of family, mortgage, and minivans had not dimmed his love for it one iota."

This creates [the bit about the hotrod] that we can place into whichever scenes we like.  If the scenes that have it are not necessarily exclusive to one another, we might wrap our new say phrase with [if ...] and [end if].  We could even place those inside our new say phrase, but it is sometimes wiser to let each enclosing scene decide whether the paragraph should be said or not, because the traveling paragraph doesn't know the various contexts in which it may appear. 

Act II is a scene. "In short, Arnie just didn't 'get' girls.  After each such failure, he would retreat home, grab his green steel toolbox with the chipped paint, and pull the Pontiac out of the garage.  [if Act I ended poorly][line break][the bit about the hotrod][end if]This, then, he is doing now."

Another handy pair of say phrases is [first time] and [only].  These cause the enclosed text to appear only the first time it is said.  While this isn't useful in a scene description which is said once anyway, it may be useful inside our own say phrases in case such a thing is attempted.

To say  the bit about the hotrod :  say "[first time]He got a 1970 Pontiac Firebird on his sixteenth birthday as an old clunker, paid for by his own money earned at the bowling alley.  Many days were spent under the shade tree in the backyard, under the Firebird in its engine, or in its transmission, or its cabin, tinkering, tweaking, polishing.  Arnie spent most of his later teen years on that car, and thirty years of family, mortgage, and minivans had not dimmed his love for it one iota.[only]"

Sideways Exploration via One-off Responses

It isn’t necessary that everything the reader enters advances the story forward.  Ancillary exploration is another pleasure of interactive fiction.  We could require the reader to find some of these responses before advancing the story, possibly embedding hidden options within them.  And many times a reader will re-enter whatever advanced previous scenes into a later scene, especially if he has no clear idea of what will advance that scene.  We create these things via “understand” lines.

Understand “ladybug/ladybugs” or "lady bug/bugs" as a mistake (“But ladybugs don’t light up.”).

Understand “kiss/smooch” as a mistake (“You think that ventilation system may get in the way of kissing Darth Vader.”) when the lightsaber duel is happening.

Understand lines connect a response to a topic.  If we wish, we can restrict the pair to particular scenes by appending a “when” clause.  Our options there restrict the response to a single scene (via “when X is happening”), to anytime after a particular scene (via “when X has ended”), or to anytime before a scene (via “when X has not happened”).  

Multiple understand lines usually put us in the position of repeatedly typing the same topic.  A shortcut for that is understand phrases, which look like say phrases but appear in topics, not prose.  Here is an example for a much-discussed man.

Understand "Gatsby", “Jay Gatsby”, or “the/our/-- host” as “[Gatsby]”.

Understand “kiss/smooch [Gatsby]” as a mistake (“...”).
Understand “sneer/ignore [Gatsby]” as a mistake (“...”).
Understand “talk/discuss about/-- [Gatsby]” as a mistake (“...”).

The understand phrases allow us to write many understand lines quickly, saving work.  Incidentally, the – double-hyphen we used as a synonym for "about" means the word is optional.

One standard understand phrase is [text] and it accepts anything.  It has an associated say phrase [the topic understood]  which will reproduce whatever [text] caught.  We can use this to write understand lines that respond appropriately to whole categories of things.   ((player's command includes.. -->  [the matched text]))

Understand “kiss/smooch [text]” as a mistake (“'There will be no kissing anyone here, young lady, least of all [the topic understood].'”).

Little Scenes Within Bigger Scenes: Dialogic Exchanges

It is said the three-act structure is fractal: the story as a whole follows an exposition, confrontation, resolution arc, as does each act sub-divide into three, as does each scene and so on right down to individual exchanges of dialogue.  We have connected our scenes in a kind of flowchart thus far, but we can define scenes that are comprised of smaller sub-scenes, or compose larger 'scenes'.  (Indeed, we have already seen one example of this in the all-encompassing scene called The Entire Game.  All of our scenes collectively comprise that scene.)  Until artificial intelligence progresses to the point of HAL and Star Trek, interactive dialogue is usually handled by a similar flowchart of mini-scenes. 

[use Gatsby's party as the example]

Act II scene 2 exchange 1 is a scene.
Act II scene 2 exchange 1 begins when Act II scene 2 begins.
Act II scene 2 exchange 1 ends decisively when the player’s command includes “yes/no”.
Act II scene 2 exchange 1 ends indecisively when the player’s command includes “maybe/possibly”.

Act II scene 2 exchange 2 is a scene.
Act II scene 2 exchange 2 begins when Act II scene 2 exchange 1 ends. [in any way]
Act II scene 2 exchange 2 ends decisively when the player’s command includes “yes/no”.
Act II scene 2 exchange 2 ends indecisively when the player’s command includes “maybe/possibly”.

Act II scene 2 ends consistently when Act II scene 2  ends like Act II scene 2 and the player’s command includes “bye/goodbye”. 
Act II scene 2 ends inconsistently when Act II scene 1 does not end like Act II scene 2 and the player’s command includes “bye/goodbye”.

It's useful for NPCs demanding clarity, extracting a promise or guarantee, interrogating for complex information, for debate & argument, etc.

Recurring Scenes for Important Exchanges

The flowchart-like progression of scenes we have examined so far have consistently flowed in one direction: forward.  Reader-led dialogue, especially when the reader doesn't quite catch the significance of something, may repeat itself or run in circles.  Ideally this won't happen but we should account for it, at least in important situations.  We do this by allowing exchanges to recur, via the word "recurring" when we declare the scene.  

	Act II scene 3 exchange 2 is a recurring scene. 

In general, allowing a scene to happen again is harmless.  The previous say phrases we’ve used will continue to work as expected – has happened and ended imply “at least once”.  But when the same scene recurs, it would be nice to vary the text on that and subsequent repeats.  We can do this with a multi-part say phrase:  “[one of] ... [or] ... [or] ... [stopping]“.  The first time the scene happens, only the first section is said (the part between [one of] and the first [or]).  The second time, the second section is said,  and so on until the last section (between the last [or] and [stopping]) which is said for all later repeats of the scene.  We can include as many [or] pieces as we would like. 

Act II scene 3 exchange 2 is a recurring scene. "[one of]'Yeah, I saw Marsha go to David's apartment last Tuesday.'[or]'As I said, she went there Tuesday.'[stopping]"

We also have available [cycling] as an alternative to [stopping] when, after all the contained phrases have been used once, they will repeat from the beginning rather than re-printing the final section. 

Relatedly, the [if ...] and [end if] pair may also have middle sections: [otherwise if ...] may occur many times, and [otherwise] may occur only once, just before [end if]. 

Exchange 5b is a recurring scene. "[if exchange 3b ended]'I saw her at David's apartment last Tuesday.'[otherwise if exchange 3e ended]'I heard something about a guy in Bremerton.'[otherwise]'I don't know a thing, detective.'[end if]"

Where the [or] phrases selected sections implicitly based on the number of times it had been requested to speak, this one makes its decision criteria explicit.  The final section, between [otherwise] and [end if] will only appear if no others did.

Recurring scenes are one way to keep together related lines.  They may be related as re-phrasings as shown first, or they may contain a progression of the same idea, or they may relate by being a different take on a situation in accordance with differing knowledge, as in the final example.  They are one tool to avoid needing a whole scene for every scrap of prose in the work.

Grouping Similar Scenes via Adjectival Tags

With parallel scenes and parallel dialogic exchanges, sometimes the same bit of story information can be dropped in vastly different places, and ensuring at least one of them has been said via conjunctive conditions like [if Act IIc ended or Act II scene 3 exchange 4 ended or Act II scene 4c exchange 2 ended] can be tiresome to type and difficult to be consistently correct.  To shortcut such things we can tag scenes with adjectives or adjectival phrases, then refer to a whole group of scenes via that adjective, like [if a clueing scene has happened] or "Act II investigation ends when every clueing scene has ended."

We define adjectives with a "can be" sentence, and every adjective in that sentence is considered mutually exclusive of the others in its sentence.  

A scene can be laconic or loquacious. 

One or two adjectives are typically given, and so they would act as antonyms of each other.  In the case of a lone adjective, "not" combines with it for the antonym.

A scene can be gossipy.  [most scenes are "not gossipy"]

All scenes are assumed to be tagged by the last adjective in the list (or the implied "not" for a loner) unless and until stated otherwise.

A scene is usually laconic.
Explaining your life is a loquacious scene. "..."

Owl-eyed man’s dialogue exchange 2b is a recurring, gossipy scene. "..."
Drunk girl’s dialogue exchange 3 is a recurring, gossipy scene. "..."

Adjectives are either-or.  But we can mix and match adjectives for even more specific groupings, similar to the overlapping circles of a Venn diagram:  [if a laconic gossipy scene is happening].  But usually, we will use them to ensure all necessary narrative jobs of the larger scene are complete.

Gatsby's Party is a scene.  “...”

Understand “leave/go home/--” as a mistake (“But the night is still young!”) when Gatsby's Party is happening and a gossipy scene has not happened.

Gatsby’s Party ends when every gossipy scene has ended and the player’s command includes “leave/go home/--”.

Later we will see how a scene can remove or change other scenes' tags, for those cases where the job of a group member is done by an outlier.
Pacing and Timers

When we introduce non-forward progression into an int fic, pacing and "stuckness" become much more of a concern.  While the reader explores new territory it isn't too much of a problem, but sometimes, especially with interactive dialogue, the reader may not know how to move the story forward and find themself talking in circles.  Either the reader is missing some significance, or they cannot figure out what to type, or are just plain stuck.  [[circularity allows for simulation -- of dialogue, of world, etc.]]

Fortunately, pacing is strongly tied to time, and a computer can measure time.  Inform measures it by counting reader prompts (“turns”) though it usually uses "minutes" synonymously.  For a conversation which circulates thorough a flowchart of mini-scenes, we can time how long the conversation as a whole has lasted, and begin to display additional and perhaps more explicit options.

"…at the party[if the time since Gatsby's Party began is at least 10 minutes], as Nick wished to discover all he could about his cousin's old suitor[end if]."

We use is at least instead of is so the message will continue to appear after the ten-minute mark has passed. This is especially important because a particular scene may not appear on exactly that point in time.  (Of course, if we want it to appear just once after the set time, we could place [first time] and [only] within the [if the time since…] and [end if].)

We also have the choice to simply end scenes after a set amount of time. Naming that ending may be a good idea so any following scenes can summarize what information the reader didn’t discover on their own.  

Gatsby's Party ends inevitably when the time since Gatsby's Party began  is greater than 15 minutes.

Discovering which mini-scenes were omitted is a job for the adjectival tags:  every new gossipy scene, for instance.  We could also ask how long it has been since any scene has begun (i.e., how old the newest scene is), or even how long since a scene of a particular group has begun (such as gossipy scenes).  [[adjective “new” isn’t needed]]

Send in a man with a gun begins when the time since a scene began is twenty minutes.
Send in the big-mouthed drunk begins when the time since a gossipy scene began is at least three minutes.

Once we detect mired pace, we write an unexpected event to move things along.  In the previous section with Gatsby, a likely thing to happen would be some character volunteering the information we need the reader to know.   How to weave in timered scenes that just "pop in" like that?  

Cues

Inform 7 uses the term "rules" for these, but they aren't the proscriptive declarations found in Monopoly's box-lid instruction manual.  They are much like stage directions in theater, specifying what to do and when to do it.  The commonest moments to have instructions attached are when a scene begins or ends.  The instructions commonly given are "say" and "now".  We've seen "say" earlier, when looking at how to make our own say phrase.  But unlike say phrases, we don't explicitly state when a cue is to begin -- the cue itself knows.

When  Gatsby’s Party  ends eventually:
say "Nick heard all manner of speculations regarding Gatsby's character:  bootlegger, murderer, heir to an even greater fortune."

The colon divides the 'when' part, which comes first and we will call the header, from the 'what' part, which comes afterward and we will call the body.  The header can have multiple conditions, usually prepended by 'when' or 'during'.  The body may have multiple instructions, separated by semicolons, and in that case we might like to list the cue in outline format.

Besides the "say" instruction, "now" is another common instruction because it changes something backstage.  One of those things is the prompt for the reader.  Normally set to an innocuous > greater-than symbol, we could change it to the beginning of a sentence that our reader is expected to finish. 

	When the Entire Game begins: 
		now the command prompt is "Arnie felt ".

Changing the reader's prompt is a powerful technique for suggesting what words the int fic understands or expects of the reader.  

"Now" may also change the adjectives that tag a scene.  In our dialogue example, we needed a few rumors to be dropped during the party.  But let's say the reader spread a rumor spontaneously, say, about Gatsby killing a man, rendering moot the scene where a drunk young woman brings it up.  When the former scene happens, it will remove the tag from the latter.

Reader Volunteers Gatsby as Murderer is a scene.  "..." 
Reader Volunteers Gatsby as Murderer begins when the player's command includes "[Gatsby] killed/murdered". 

When Reader Volunteers Gatsby as Murderer begins:
	now i-heard-he-killed-a-man is not gossipy.  

Thereafter, the party scene, which ends when every rumor's been spread, will no longer wait on the drunk's scene, its job already finished.
Character Arcs and Overlapping Scenes

X said that every story is someone's story, the story of a character.  And, every person has their own story, their own character arc.  One pleasure of interactive fiction involves the reader taking a vested interest in the welfare of a side character, and taking action to help them.  If we wish, we can use scenes to represent the stages of a side character's arc.  These scenes are generally disconnected from the main flow of the story, so may tend to overlap the main scenes awkwardly.  

	George Wilson's life is a scene. 
	George Wilson's 

Jordan Baker
George Wilson
Tom Buchanan
Myrtle Buchanan

Nick doesn't know of Jay & Daisy until after the party.

Character arc "scenes"; scenes running in parallel; scenes that "remember" stuff?   Just as many things are going on at once, many scenes can be going on at once.  Every character may have his or her own story, but those stories' scene breaks don't necessarily fall in the same place.   [[ but how is that a good idea?  we can't allow the arcs to insert themselves whenever they feel like ]]
Act I is a scene. Introducing the major players is a scene. Introducing the first plot knot is a scene.

Look-Up Tables and Corresponding-To

There come times when lots of little things need writing:  lines of interactive dialogue, responses to various reader input, variations on reader input, responses to reader inputs, and so on.  Since creating a scene involves three or more sentences besides the prose itself, creating a scene or even a understand-as-mistake line for every little line is laborious. Tables can represent this kind of information in a concise rows-and-columns format.

Table 1 - partygoer lines
topic						response
“sneer/ignore [Gatsby]”  	 		“'Oh!  So rude to our host.'”
“talk/discuss about/-- [Gatsby]”  	“...”
“kiss/smooch [Gatsby]”  			“...”
“kiss/smooch [text]”    			“'There will be no kissing anyone here, young lady, least of all [the topic understood].'”
"[text]"					"'Whaat!?' someone says, the din of the party having drowned you out.  (Try re-phrasing.)"

Here we have put the topics and responses for the understand-as-mistake lines we used earlier.  We begin with the word "table" followed by its number or name (or both, as we've done here).  The next line holds the names of the columns, separated by at least one tab.  Finally, the good stuff, one per row.  Extra tabs may line up the columns.  At least one tab is always needed, because that is how the computer knows where one column ends and the next begins.  

Now that we have the table, we can write a single understand line to consult it.

Understand "[text]" as a mistake ("[the response corresponding to a topic of the player's command from table 1]") when Gatsby's Party is happening.

That is a single, rather lengthy say phrase as the response, but it is responsible for doing the look-up and saying what it found. Let's examine how it works. First of all, the say phrase has to know which table it will be consulting, so that information is in there as from table 1 at the end.  Second, corresponding to means "on the same row as".  It scans down the topic column for what the player's command is holding, and when it finds a match we have the row to work with.  From that row, the entry under response will be said. 

If it sounds complicated, it is, but once learned that complexity works in our favor.  Every row in that table previously needed "Understand", "as a mistake", the scenes or times to which they applied, and all relevant punctuation, to be typed out by hand each time.  That's a lot of unnecessary typing.

other features yet to be introduced

When to use mistake lines, versus Table of mistakes, versus very short scenes, versus a big scene with table lookups within it...   and then introduce table-of-mistakes with a yes/no column called "said"!   (and, a say instruction cued by an ending scene)

The random say phrases: give to their own section far below.  [as decreasingly likely outcomes] ; [at random] ; [purely at random] ; [sticky random] ; [in random order].  Randomness is more of a gamer thing than a writer thing. They're a possible solution to having one's puzzles spoiled (i.e., the safe's combination lock).

[[the player's command of [turn X / scene 4 / etc.  ] as an alternative to the "declare space, write value into space, use value later" pattern of computing;  the <global variable> of <something with an implied point in time, like a scene ending or a turn or...>]]

More on Look-up Tables

Like many things presented in this tutorial, tables are a tool with many uses.  In the previous section we used a table to represent several mistake lines concisely.  But we can use tables for responses in the next scene just as easily, especially if more than one piece of prose needs to change in response to the previous scene. 

To start, let us end a scene on when the reader enters something in a table.  

	Scene X ends when the player's command includes a topic listed in table 1.

In the following scene, before the reader is allowed to enter something else, we can use the corresponding to phrase to sprinkle many little responses throughout the scene's prose, one per column.

Table 2 - Tom & Daisy banter about the broken clock
topic			Tom's response	Daisy's reply
“fix”  	 		“...”			“...”
“need”		“...”			“...”
“buy/new”  		“...”			“...”

Act III is a scene. "Tom goes up to the bar and makes another drink.  '[Tom's response corresponding to a topic of the player's command in table 2]' he says.  '[Daisy's reply corresponding to a topic of the player's command in table 2]' replies Daisy.  Tom grunts.  'Nick, you want a drink?'"

unthreaded & threaded dialogue exchanges via tables?  scheduling a dialogue response, a reminder? ?

Properties

One method of proving agency is to quote the reader's input in a later scene, such as a character quoting them.   To do this, we first need a 'place' to put the reader’s text until the later scene happens.  to attach it to something.  Such places are called properties. One property we have been using all along is called description.  When a scene begins, it is the scene's description property that has held our text, and shows it to the reader when the scene is cued to begin.  

We can create a new space for each scene to hold something, naming it what we wish.  

A scene has some indexed text called the reader response. 

This declares a place named "the reader response", which would be said via [the reader response of Gatsby's Party] or some such.  By "indexed text" we mean text that is inputted by readers, not written by authors. It is called such because the contents of such text can be looked up per word or per letter, such as [the first word of the reader response of Gatsby's Party]. 

Properties always use the word of between themselves and their holder.  

When a scene (called that scene) ends:  
	now the reader response of that scene is the player's command. 

The “now” instruction, used from within a cue, can place the reader's text so.  But first we must provide the places. 

[[Save [the player's command] for later, via properties!  But properties need cues to set & change them, unlike adjectives and descriptions which usually do not change at run-time. ]]

* change/replace [the text of] the player’s command to/with “indexed text”
* cut the matched text;  /  replace the matched text with "...";  / matches vs includes

if the first word of the player’s command matches…

Cuing Events (delete this section?)

Sometimes we might like to schedule a future scene based on what the reader has just done.  

[[But in a CYOA-ish work, there isn’t really a simulation of time passing by, either real-time or via multiple prompts passing by -- indeed, a distinguishing feature of CYOA is no wasted prompts.  So why is beginning/ending a scene ten prompts later/sooner even useful?  And the future scene can always ask if a previous condition was met, so why schedule future events at all? It's six one way, half-a-dozen the other.]]

[[how about meandering dialogue?  NPC brings up an old topic again spontaneously? Didn't I already cover that with Pacing+Timers?  ]]

Can’t do  scene begins/ends in 3 turns from now  except by: 

Train stop begins when the time since Waiting On Train ended is 3 minutes.
Train stop ends when when the time since Train Stop began is 3 minutes.

How to connect scenes to scheduled events (i.e., a scheduled rule)?

When Inciting event begins: the mail drop happens in 3 turns from now.

At the time when the mail drop happens: 
say "There's a sound downstairs.  The mailman apparently dropped a few letters through the front door slot.";
now Inciting Event is ready to end.

A scene can be ready to end.

Understand "..." as a mistake ("...") when Inciting Event is happening and Inciting Event is not ready to end.

[  Understand "..." as a mistake ("...") when the time since the mail drop happens is less than one minute.  ]

Every turn when the Inciting Event is happening:
if the time since Inciting Event began is 10 turns, say "What's this?  This letter is unexpected."

Narrative Questions

What is the viewpoint?  This isn't just the narrative question of choosing between first-person, third-person (omniscient or otherwise), and possibly multiple and/or unreliable narrators.  To what extent is the reader "in" the magic circle, on the same side of the fourth wall as the characters?  To what extent is the reader themself, as opposed to role-playing a particular, distinct character?  These are distinct questions, as it is possible to be one's self within the circle, like a Connecticut yankee in King Arthur's court, or role-play a god toying with mortals, or play one aspect of a particular character's mind, like a woman's superego or a son's anxiety about paternal expectations.  And all of those possibilities assume whatever answers given remain unchanged throughout the work. 

For works in which the reader remains themself but are placed within the magic circle, second-person present tense is not only common, but in sharp contrast to trad fic, is considered a beginner's technique. Less characterization is needed for the avatar, less is asked of the reader in maintaining a particular role, and less is asked of the author in guiding the reader into a role.  However, this weakens the technique of discouraging deviant behavior in the guise of the character's own predilections.  For example, a reader role-playing as Hamlet allows the author to curtail many behaviors with variations on "Irrevocable actions require irrefutable justifications," which re-inforces Hamlet’s character as well as an important component of the work's theme.

Hero, protagonist, viewpoint character… and a controllable avatar.  X observed that the choices fictive characters made should seem in retrospect inevitable despite the choice seeming difficult and evenly balanced before it was made.  But the reader's choices in int fic may remain balanced.  While the trad fic reader might have been left wondering why the hero chose A instead of B, the int fic reader does not wonder this about themself.  Indeed, making the reader wonder why they chose as they did could be int fic's most powerful technique.  So try placing the reader's avatar outside the main protagonist-antagonist conflict, and allow them to choose whichever side they may, or even make their own.  

What are the key scenes?  What are the interactive bits that keep the reader involved during them?  What is the tone of the interaction, or of a particular choice?  Exploratory, either geographic, dialogic, or otherwise?  Highly restricted, as in being a captive or a hands-off sightseer?  Highly interactive, as in a puzzle or physical simulation?  Is time an element either narratively or in fact, as measured by in-game clocks and countdowns?  Transcript it. (how to encode the transcript?)  When to allow an "interaction beat"?  What to allow?  Allow often, with WAIT or LISTEN as a non-beat?  (Or use my awesome extension for a command prompt when you want one?)

interactive scene types
Atmospheric, sightseeing -- not about doing much  
Trapped, highly restricted -- cannot do much 
Puzzle/ manipulation -- highly interactive, not usually much plot. pacing/timers difficult
exploration / mystery -- incite curiosity in the player, then give them some rope
directed conversation -- dialogue tree.  exploration of a different kind.
interactive travel -- setting heavy. pacing difficult.
scripted sequence -- barely interactive. light on setting, heavy on anything else trad fic

Some int fics begin with an interactive vignette of sorts.  It allows the reader to become comfortable in the world, to get their bearings before plot-developing decisions need to be made.  Other readers would prefer the orientation be brief to the point of invisibility.  Either way, a vignette can show a reader a lot:  characterization, setting, etc. But what is there for the reader to do?  To decide? To choose?  Reader's decisions will change later text, perhaps in key scenes.  In a vignette, what later text will the reader change that needs be decided here, in the vignette? When and what is the interaction beat?

Consistent verb vocabulary, consistent granularity of those verbs, and consistent amount of "zoom" are ways of setting reader expectations.  For an example of the latter, when the reader participates in dialogue with the characters, does the reader need to say hello?   In sitcoms, characters don't say hello or goodbye when they answer the phone -- it's implied.  Likewise, a trad fic scene may begin in the middle of a conversation with two characters, skipping over the mundane bits and getting to the good part. How close to slice-of-life does a work sit?

Writers know that how characters talk with one another isn't how real people talk with one another.  Fictional dialogue is pared down, efficient, potent.  Real dialogue meanders.  So when a reader is inserted into a fiction, we have a problem of mismatched expectations:  most readers' experience with dialogue is the slice-of-life kind.  They don't know how to write *dialogue*, how to pare down the words to the essence.  How does the int fic author deal with this problem?  

Requiring the reader to Compose Dialogue is hardly an option; writers themselves differ on quality and various other aspects of dialogue.  But even if we could use a full-blown chatbot, we introduce pacing issues:  the conversation will wander aimlessly.  

Explicit options a la dialogue trees?  Keyword topics?  The combinatorial explosion of a few verbs / topics allow some self-directed speech without too much aimlessness, since we control the vocabulary. But that seems to work better for imperative actions than for dialogue.  Perhaps enforcing a few select grammars, with replaceable words within like an ad-lib, is a solution.  

Physical Simulation is Slice-of-Life

[[Mundane dealings with furniture and pockets.  Time sliding by is simulated via allowing prompts to do narratively little to nothing.]]  [[Simulate furniture, pockets, physics in general.   Strong setting, if not related to the story.]] 

The computer needs to remember where things were left, what state they were left in, etc.  We can’t attach all this information to understand phrases.  There is something called objects whose sole purpose is to glue multiple bits of information together, including an understand phrase.   But this attached information, these relations, cannot be changed from an understand-as-mistake line. They can only be changed by the "now" instruction, within a cue.   Which relations are changed – burnt, location, wet, etc. – usually depend upon which verb was used.  So we now have actions to glue understand phrases to cues.

	Carry out taking something (called the item in question): 
		now the player carries the item in question.

(Now we seem to need the parser?)

(how to sell the imperative parser?) 

What problem does it solve? What’s the problems with keyword-based input? 
* Exploring the edges: most I-F allow more than just the main CYOA throughlines.  They also add a bit of ancillary exploration. But there’s a limit on how many options one can give the reader.  Reading long lists of possible inputs is a no-go idea. A solution is combinatorial input.
* more amenable to sims, sims more amenable to slice-of-life?
* Alternatives to combinatorial input: "all options allowed in previous scenes are allowed in later scenes" -- but hard for reader to remember them all, hard to author to track them all.
* The verb-noun combination is natural way to express a great many different things with only a few words.  Even with only four verbs and three nouns, that’s twelve different possibilities squeezed into a mental space made for seven (plus or minus two) things. 
* Combinatorial input is also a solution for readers who feel led by the nose. It gives them a sense of freedom, of agency.
* The explosive amounts of input also gives the expectation of a lot of parser responses that need be written.  Adaptive text to the rescue.
* Jon Ingold said, "I want the reader to feel involved, but not responsible." Well, isn't responsibility one of those new-territory emotions that new media are always aiming at? Isn't such *new territory* mostly the point?
* Parser can't disambiguate / infer when Topics collide.
**	Chocolate vs peanut butter, and, chocolate vs vanilla
**	If the player’s command includes “chocolate” won’t work.

How to deal with a parser once you've decided to use it.   What are the objects involved?  For each one, think of all the things the reader may want to attempt with it.  The list of allowed reader actions will come in handy.  Might we consider new synonyms, or even new actions?

Parser error rules.

For printing a parser error during Gatsby's party:  say "'Whaat!?' someone says, the din of the party having drowned you out.  (Try re-phrasing.)"

la la la

After reading a command during a laconic scene when the number of words in the player's command is more than one:
		say "One word only please."; 
	reject the player's command.

What Our Reader May Write

We have unlimited freedom between the double quotes, but otherwise what we write is restricted to only the idioms than the computer understands.  Likewise, our reader does not have much freedom in what she may write.  She's largely restricted to imperatives, and frequently we will be busy accounting for even that much.  Inform understands some selection of verbs as-is [WHY LIST THEM] So here then are the verbs our reader has available.  (We provide the nouns ourselves.)  For brevity, synonyms are not listed.  

	look, listen, smell, taste, touch
	give, show, kiss, tell, ask, throw, attack
	wait, go, enter, exit, get off, jump
	read, examine, look under, search
	get, put down, take inventory
	lock, unlock, open, close, insert, remove, switch on & off 
	eat, drink, wear, take off, think, sleep
	insert, remove, push, pull, tie, cut, squeeze, turn, burn, rub, swing 
	climb, jump, sing, wave, sleep, wake, buy
	saying yes, saying no, saying sorry

To put the interactive in our fiction, we end a scene on the performance or success of these actions.  We have already ended scenes on the performance of WAIT, via the phrase "we have waited".  However, sometimes we are less concerned if an action was ever done than if its effect is still in effect.  For example, when our reader enters TAKE RING, it is true that 1) she is (now) taking the ring, and 2) she is (now) carrying it.  But next turn, when she enters WAIT, she is no longer taking the ring, but she is still carrying it. 

We – not our readers – have additional verbs that describe the state of the world, rather than indicate a momentary performance. 
	has, carries, wears, supports, incorporates, contains, conceals

Nearly all of them related to physical and/or geographical relationships to other objects.  This is because physical objects are much more tractable for a computer to simulate than are characters.  For example, bags and backpacks contain things, tables and mantelpieces support things, and four wheels (among other things) incorporate a car. 

[sidebar]Besides those actions that happen within the fictional world, our player also has a few out of world actions pertaining to the computer and the work itself.  Generally we can ignore their existence.  
	save, quit, restore
	restart
	transcript on & off, score, pronouns
[end sidebar]
A Physical Simulation Example

Since nearly all of our reader's actions involve acting upon a noun of some sort, let us create a few things with which our reader may interact.

	 An apple  is  an edible thing  in  the location .
	 The hope chest  is  a locked container  in  the location .
	 A glass box  is  a closed, openable, transparent container  in  the location .
	 The engagement ring  is  a wearable thing  in  the glass box .

The first blank is the name of our prop.  The computer does not understand this; it just quotes it, and recognizes it when we use it in other places in our work.  The second blank the computer does understand, and a little later we will examine what adjectives and nouns we may write here.  (Omitting this blank entirely presumes "a thing".)  The third and final blank specifies where in our fictional world the prop currently is.  Initially we have only one on-stage place, "the location," but a container counts as another place -- especially when it is closed. (Omitting the location presumes off-stage.)

Perhaps there is a diary in the locked hope chest, and reading it will end the scene in a third way.  Perhaps our lover gave us a mysterious key in an earlier scene, never saying what it was for.  We don't explicitly call out that that key may unlock the hope chest, but it is natural enough for an alert reader to attempt.  

What kinds of emotions can we induce in our readers by involving them so intimately in how things unfold?

The small key is a thing.  "It is a small brass key, but you know of nothing that it unlocks."

The matching key of the hope chest is the small key. 

The diary is in the locked hope chest.  "It is a perfectly square book tied shut with a leather cord."  
The description of the diary is "June 26th:  I have learned a terrible truth today...."

Act II ends with detailed knowledge of what happened when we have examined the diary.

Action Cues

[ clear the stage, re-create the stage for a new scene, change properties like location, description, printed name,  ]

We can move things around between scenes as well.

	When a scene ends: now everything is off-stage.

	When Act ii begins:
		now the hope chest, apple, and glass box are on-stage;
		now the hope chest is closed and locked;
		now the player carries the small key;
		now the matching key of the hope chest is the small key.

Sometimes it's useful for the stagehands to do things in response to what the player does.
	Before doing anything:
	Before waiting: 
	Before taking something: 
	Before taking the engagement ring: 

	After doing anything:
	After waiting:
	After taking something:
 	After taking the engagement ring:

	Every turn:
	Every turn during the collapsing bridge scene:

Scenes use "when", actions use "before" and "after" among others. 

	When a scene begins:
	When a scene ends:

	Before an action:
	After an action:
	Before an action during a scene:
	After an action during a scene:

	Every turn:
	Every turn when an action:
	Every turn during a scene:
	Every turn when an action during a scene:

The State of the World

Our reader's writings do more than just reference the few nouns we tell the computer about.  The computer remembers the physical relationships between those things, usually using verbs like carries, wears, contains, etc.  The computer remembers the physical state of those things, usually via adjectives like open, locked, lit, and so on.  In Inform, adjectives are generally a yes/no affair:  the computer considers it either open or closed, never ajar.  Our prose may disagree, and that's fine.  And then there are properties, like location, printed name, description, matching key, etc.  They are not either/or, but are valued properties.

Properties are named after nouns, and the preposition "of" connects the property to the noun is describes:
	The matching key of the hope chest is the small key.

Compared to the performative verbs, we have very few verbs of state.  Partly this is because we need two performatives for each state:  one to put the world in that state, and one to put it back.  
	take, get		---> carrying		---> drop, put down
	wear, don		---> wearing		---> take off, doff
	put in, insert		---> containing	---> take
	put on, stand on	---> supporting	---> take, get off

Reader Synonyms, Revisited

Synonyms are more than just a nicety to a reader whose vocabulary might not match up to our own.  They can change the tone of a work.

	Understand "pray" as waiting.

Normally, when our player types in the word "pray", she will receive a canned response: "That's not a verb I recognize."   Here we have changed that, and perhaps the tone of the work as well.  We may also define synonyms for more than just verbs.

	Understand "band" as the engagement ring.

Now our reader may write "engagement band" or just "band" to refer to the ring.  

Because our reader writes only in the imperative, we can take advantage of the computer's ignorance.

	Understand "turn page" as waiting.

Perfect-tense Actions

* irreversible, like knowledge & plot points.
* "we" required vs. a specific noun required
* useful most for Examined X, or Asked Bob about Letter, or Looked Under, or Searched, or consulted the letter about something, or showed something to someone, told someone about something, or thought, tasted,
* BROKEN: only single-argument actions, only non-"blocked" actions, only object-based actions (not topics. not values?). But can be used on Relation verbs?

#1b: ACTIONS testing command. Introduce some of the player's standard actions.
#1b1: explain difference between "actions" and the several synonymous "commands"
#1b1a: Understand "turn page" as waiting.
#1b1b: Praying is an action. Understand "pray", "meditate", or "chant" as praying.
#1b2: create a few props in the room; something to interact with.
#1b3: end scenes on "we have Xed the Y"; "when we have waited three times."

We can then end a scene on some such result of the player's interaction with those props.
	Act III ends when the player has the tomato.
	say "[if the player has a tomato]Or you could RUB that tomato on the tree."

#6 other  Instructions
	say 
	now 
	try
	the egg timer clucks in four turns from now;