Pacing in Interactive Fiction Is Half Yours

Pacing in interactive fiction is a shared control. The writer decides how much happens inside a scene; you decide how much ground the next scene has to cover, because your move sets its scale. A story drags when those two settings disagree — when you are taking minute-sized steps through a stretch the story meant to cross in an afternoon.

• Tempo in an interactive story is set twice: once by the length of the scene, once by the scope of the move.
• Inform describes time the way it describes space, grouping turns into scenes as it groups rooms into regions, producing “a sort of map of time”.
• In a parser game built with Inform, play ordinarily begins at 9 AM and each turn takes one minute, so the clock advances whether or not anything happened.
• In a flat ink weave, players “take the same number of turns to get from top to bottom” whatever they choose, so the tempo is fixed before anyone arrives.
• A dragging story is usually a scale problem rather than a boredom problem, and the reader can fix it in one move.

Who sets the pacing in interactive fiction?

Both of you, and not at the same level. The writer works at the scale of the scene: how much is described, what is summarized, where the cut falls. You work at the scale of the move: whether the next scene covers a sentence of story time or a season of it. Neither half can rescue the other for long.

Inform’s documentation makes the structural half unusually clear, because it treats time as a kind of geography. It divides space into rooms and groups them into regions; it “also divides time up, into individual turns”, and the equivalent grouping is the scene. Organizing a story that way, the manual says, “is more like a chart in which one scene can lead in several possible ways to others – a sort of map of time”.

That map has a fixed step size underneath it. In Inform, “play ordinarily begins at 9 AM and each turn takes one minute”, so a parser story has a metronome running whether or not your command accomplished anything. Twenty turns of searching a cellar cost twenty minutes of story time and one evening of yours. The metronome is not the pacing; what you spend those turns on is.

How does each form divide the tempo?

Differently enough that advice rarely transfers between them. In a choice-based story the author has already decided the rate before you open the file. In a parser game the rate is fixed but the number of steps is yours. In a story written live, both the step size and the number of steps move.

Form	What one move costs	Who sets the tempo	How it drags
Parser, as in Inform	One turn, ordinarily one minute of story time	Author sets the scene boundaries; reader spends the turns	Twenty turns of searching between two events
Choice-based, as in ink	One click through an authored chunk	Author, entirely, at writing time	A flat weave where every route costs the same
Free input with a live narrator	One scene, scaled to what the move implies	Writer and reader together, every turn	A vague move, so the scene covers no ground

ink’s documentation is explicit that this is an authoring decision in choice-based work. Weaves, it notes, “allow for easy redrafting of choice-points; in particular, it’s easy to break a sentence up and insert additional choices for variety or pacing reasons”. It is equally explicit about the cost of the simplest structure: in a flat weave, “whatever the player does, they take the same number of turns to get from top to bottom”.

That is a real constraint rather than a defect. It also explains a familiar sensation — the sense that a branching story is moving at a rate you cannot argue with. You cannot. The rate was written. What a free-input story changes is that the scale of each scene becomes negotiable, which puts a dial in your hands that most interactive fiction has never offered.

Why does a story drag even when the writing is good?

Three causes, in descending order of frequency, and only one of them is the story’s fault.

Your move is smaller than the stretch it has to cross

This is the common one. You write “look at the door”, the narrator writes a careful paragraph about the door, and nothing has moved — correctly, because nothing was asked to. Repeat four times and the story feels becalmed, though every scene did its job. The remedy is scope, not patience.

The move carries no cost

A move that risks nothing produces a scene that resolves nothing. Walking into the next room is free; walking in and saying the thing you have been avoiding is not. Pressure is what converts a scene from description into event, and the reader supplies at least half of it.

The story has genuinely stalled

Sometimes the scene answers your move, adds no new fact, and ends where it began. That is a failure of the writing or the narrator, not of your move, and the fix is to raise the stakes directly: ask a character the question nobody has asked, or leave the location entirely. Suggested openings under a scene are a useful tell here. If all of them are small, the story is marking time.

How do you change the pace of a story you are reading?

By changing the shape of one sentence. A move that names a destination and a duration asks for a scene that covers both; a move that names a single gesture asks for a close-up. Most readers never discover this because no interface advertises it, and it is the most direct control over pacing in interactive fiction that a reader has.

Four adjustments cover most of it:

• To speed up, name an end state. “Travel until the river” or “wait out the week” hands the narrator a span to compress, and good narration compresses by selecting, not by summarizing.
• To slow down, narrow to one object or one line. A single question put to one person will reliably produce a scene that covers ninety seconds.
• Give the move a cost. Tell the truth, spend the last coin, turn back. A scene with something at stake runs faster than one without, at the same word count.
• Stop on an open question. Where you choose to close the app sets the tempo of the whole reading, which is the argument for reading interactive fiction slowly over several evenings.

What none of these requires is a longer sentence. Scope is not length. “Ride to the coast” is four words and covers a day; a hundred-word description of your mood covers nothing at all.

What a live narrator has to get right about tempo

A narrator writing scenes as you go has to read the scale of your move and answer at that scale, which is harder than it sounds. Ask for a day’s travel and get a paragraph about mounting the horse, and the story has quietly refused you. Ask to examine a lock and get a week of plot, and it has run off without you.

Fabledrift, an interactive fiction app for Android, treats that reading of scope as part of the narrator’s job rather than a setting you configure. The practical consequence is that stepping back to an earlier scene of your own is free and always available, because a misjudged tempo should cost nothing to correct. A story’s total length follows from the same arithmetic, which we worked through in how long an AI story runs.

The harder half is restraint. A narrator that compresses too eagerly turns a story into a synopsis, and one that never compresses leaves you examining furniture in a burning building. The record it keeps matters here too: knowing that the lamps are lit at dusk, and that you said you would be at the coast by then, is what lets a single scene cover a day without losing the thread.

A pacing test for the next three scenes you read

Read three scenes in a row and write down, for each, how much story time passed. If all three are minutes, you are in a close-up — fine for an argument, wrong for a journey. If all three are days, check whether you can still name what anybody wanted. A story reading well usually alternates, and the alternation is something you can cause rather than wait for.

Then try the inverse. Write the largest move the scene can honestly support and see what comes back. Most readers underestimate it by a wide margin, and the discovery that a single sentence can move a story a week forward tends to change how the rest of it reads.

Sources: inkle’s Writing with ink documentation and Graham Nelson’s Writing with Inform.