Editors for game writing and interactive narrative

An interactive narrative edit checks six things a prose edit never touches: how your story branches, whether the merge points hold up in every state the player can arrive in, the short repeating lines a game fires during play (often called barks), the text-box limits your lines have to fit, pacing when the player controls the clock, and how much of your text players actually read. Most editors who say they edit game writing mean they'll read your dialogue in a Google Doc. That's a useful service and it isn't the job. Game writing lives in a spreadsheet, a node graph, a localization key file and a 40-character text box, and the things that break it aren't the things that break a novel.

We write and ship games as well as edit them, which is the only reason this page can be specific. Here's what an interactive narrative edit covers.

1. Branch structure: the three shapes, and what each one costs

Before anything else, an editor should be able to name the shape of your branching, because every note downstream depends on it.

The gauntlet. One spine, with choices that color a scene and rejoin immediately. It's cheap and scalable, and the player feels heard even though the state barely changes. The failure mode is that players notice nothing they do matters, usually around hour three, and the whole thing goes flat at once.

The wide branch. Genuinely divergent paths that stay divergent. It's enormously expensive, because content cost multiplies and most of what you write, most players never see. The failure mode is that the budget runs out and the branches quietly converge in a way that feels like a betrayal.

The state machine. No branch tree at all, just a pool of flags and scenes that assemble themselves from what's true. Many modern narrative games work this way, and it's the hardest to edit because there's no single readable story to read. The failure mode is combinatorial nonsense, like a character mourning someone the player never met, or a line that assumes a fight that didn't happen.

The structural notes that come out of this:

Where does state need to persist, and for how long? Every flag you keep is a permanent tax on every line written afterward. A flag that only matters for the next two scenes should be scoped to the next two scenes.
Is the choice legible before it's made? The most common design-writing failure is a choice whose meaning is only clear in retrospect. That's a coin flip wearing a costume. The player has to be able to predict the kind of consequence, even if not the specific one.
Is a false choice pretending to be a real one? Players forgive a gauntlet. They don't forgive a gauntlet that was sold as a branch.
Does every path get a version of the emotional beat? If the confession scene only exists on path B, path A players finish a different, worse game.

2. Convergence discipline

When branches rejoin, and they always rejoin, the first line after the merge is the most dangerous line in the script, because it has to be true in every world that leads into it.

An editor should read merge points specifically and ask what the full set of states arriving there is. A merge line that says "after what happened at the bridge" is broken for every player who skipped the bridge. The fixes are unglamorous, and they're the job:

Write merge lines stateless, and put the state-specific acknowledgment in a short conditional line just before or after.
Keep a written contract for each merge point listing what's guaranteed true there. Few teams do this and most should.
Make the character who speaks first at a merge the one with the least reason to reference recent events.

3. Barks and systemic text

Barks are the short combat, idle and reaction lines a game's systems fire off. They're where most games' writing quality is actually experienced, because players hear them thousands of times and read your beautiful cutscene once. They're also, in most projects, written last, fastest, and by whoever's free.

What an edit looks at:

Repetition math. How often does the line fire, and how many variants exist? If a line fires every twelve seconds and there are four variants, the player hears each one many times in a single session. Four is rarely enough. A rough rule is that the funnier or more distinctive a line is, the faster it wears out, because a flat line fades slowly and a joke dies on the third hearing. So write the distinctive ones with high variant counts and keep the workhorses plain.
Cooldowns and priority. This is writing work even though it looks like systems work. Two barks that can fire on the same trigger will eventually fire over each other, and it sounds like a bug. The writer should be specifying priority, not discovering it in QA.
Voice consistency under compression. A character's voice in a 300-word cutscene is easy. The same voice in six words, shouted, is the real craft problem. If your barks would work in any character's mouth, you don't have characters, you have a bark list.
Barks as tutorial and state readout. The best systemic lines do three jobs at once: character, mood, and information the player needs. "Reloading" is a UI sound. "I'm dry, cover me" is a UI sound, a relationship and a person.

4. Writing to a text-box budget

This is the constraint prose editors have no framework for. Your line doesn't get as many characters as it needs. It gets as many as the box holds, in the widest language you ship, at the largest accessibility text size, on the smallest supported screen.

Know the number before you write. Not "keep it short" but 38 characters, or two lines of 28, or whatever the real limit is. If nobody on the team can tell you the number, that's the first finding of the edit.
Budget for translation. Languages like German commonly run longer than English for short strings, and the shorter the string, the bigger the proportional jump. If English fills the box, the translated build breaks, so write English at a deliberate fraction of the limit.
Front-load the word that matters. Text that might get cut off should fail gracefully, so the meaningful noun goes first and the qualifier last.
Never write around a variable you can't see. {ITEM} acquired! isn't a sentence you've actually read until you've read it with the longest item name in the game, the one that starts with a vowel, and in a language with grammatical gender.
Read every string in place. A line that's perfect in the spreadsheet can be wrong on screen because of where it sits, what's behind it, and what the player is doing when it appears. A "game writing edit" that never looked at the build is a prose edit with a different invoice.

5. Pacing when the player controls the clock

A novel's pacing belongs to the author. A game's pacing is a negotiation, and the player can pause your dramatic revelation to go organize their inventory for twenty minutes.

Assume interruption. Anything the player must remember has to be recoverable somewhere: a journal, a repeatable line, an objective string. If the only statement of the stakes was in an unrepeatable cutscene, half your players are playing an incoherent game.
Don't put story where the player is busy. Dialogue during combat, driving or a platforming sequence gets a fraction of the player's attention. Either the line is optional flavor, or it doesn't go there.
Design for session shape, not chapter shape. Build your beats around the length of a real play session and give the player a satisfying place to stop. The "one more" hook and a clean stopping point don't conflict, and you want both at the same moment.

6. The reading problem

Players skip text. They aren't philistines, they're competing with a system that's more interesting, and skipping is one button. Treat it as a design constraint rather than a moral failing:

Assume the first read is the only read. No line that matters can depend on the line before it having been absorbed.
The skip button is data. In playtesting, the place people start hammering it is your edit list.
Earn length. Long text is fine when the player chose it, like a codex entry or a letter they picked up. Long text pushed at a player who was busy doing something else is a tax.

What we've shipped

This is the part of our work we can evidence most concretely. We wrote The Lost Library, a narrative adventure, as a paid project for Fable Labs. It was originally published by Tales Games and is now a free, tap-to-read visual novel you can play on bossfeed.fun. We were narrative consultant on Spheriums, and wrote The Conference, a choose-your-own-adventure story first published in The Wild Musette Journal, which you can read on bossfeed.fun. The publications page lists the rest, including the games we've made, such as Worldseekers and Hexa Puzzle Saga.

On the craft side, we've written about adding narrative to an idle game's design, narrative design lessons from Guayota, and jubensha, a Chinese live murder-mystery format that interests us as a form of scripted, player-driven storytelling.

Getting an interactive narrative edit

Tell us the format when you write. A Twine or Ink export, a dialogue spreadsheet, a design doc, or a build we can play are all workable, and they get different kinds of notes. The Get Edits page has the options.