Why is writing interactive fiction still drawing diagrams instead of writing?

[oldskultxo]

There’s something that has always felt a bit strange to me about interactive fiction tools.

When you write a novel or a short story, you open a text editor. But when you want to write interactive fiction, you usually end up opening a visual node editor: nodes, arrows, connections, flowcharts.

While trying to write my own interactive novel, I kept running into the same feeling over and over again: the developer in me would come out and the writer would disappear.

Visual editors are very powerful, but many times I don’t feel like I’m writing. I feel like I’m designing logic: variables, conditions, connections… And I think the core activity of interactive fiction should still be writing.

• Scenes.

• Dialogue.

• Narrative voice.

• Atmosphere.

So, as I commented in a previous post I ended up building a small writing tool around that idea.

The idea is simple: write scenes as text first, while the structure of the story stays manageable in the background, without constantly thinking about code or diagrams.

After fixing feedback I received in the other post, I’ve just released a fairly solid version that allows you to write a full book, export it, and load it into the project’s library (everything is free to use).

It currently supports things like:

• scenes with main text, alternate text and extra text

• narrative conditions and state

• Use reader behavioral metrics as conditions (for example: how long it takes to read a chapter, how often the reader opens the menu, etc.).character sheets

• stat checks and dice rolls

• automatic generation of the story flowchart

I also added a few things to make it easier to get started:

• guided tour

• step-by-step onboarding

• quickstart guide

• integrated manual

• story validation while writing

• preview inside the editor

The project is still evolving and I’m improving it almost daily. Right now I’m working on things like:

• importing existing projects (especially Twine and Ink stories)

• narrative diagnostics tools

• debug preview

• narrative complexity warnings

If anyone feels like taking a look, I’d love feedback from people who actually enjoy writing interactive fiction.

• whether the writing flow feels natural

• what parts feel confusing

• what tools or features you feel are missing

And I’m also curious about something more general: If you could design the ideal tool for writing interactive fiction… Would it look more like a text editor or a flowchart?

You can try it here if you are interested:

https://iepub.io/iewriter/variant

And who knows… maybe someone will end up writing a novel with it!

I’d be happy to publish the first complete novel in iepub.

PS: As I need help with translations to English, I write my posts in Spanish and ask the AI to translate them keeping them correct. I hope sincerely that is not a problem. Regards

[zarf (Andrew Plotkin)]

@oldskultxo

But when you want to write interactive fiction, you usually end up opening a visual node editor: nodes, arrows, connections, flowcharts.

“Usually?”

[JoshGrams]

@oldskultxo

When you write a novel or a short story, you open a text editor. But when you want to write interactive fiction, you usually end up opening a visual node editor: nodes, arrows, connections, flowcharts.

I don’t know that it’s “usually” - granted there are a LOT of Twine games but Twine is just about the ONLY widely-used tool that’s visual?

• Twine is visual – but some people end up moving to VSCode with Tweego which is mostly text.
• Ink (possibly the most widely used narrative tool in the broader gamedev industry?) is only text, explicitly because its creators didn’t like the visual metaphor.
• Inklewriter has a fancier graphical editor, but it just shows loose ends and stuff, it doesn’t have nodes and arrows or a story map.
• ChoiceScript isn’t visual.
• None of the currently-most-popular parser-engine tools are visual:
  • Inform
  • TADS
  • Dialog
  • Adventuron
  • ZIL
• Dendry isn’t visual.
• Bitsy/Bipsi/Binksi etc. don’t use a flowchart metaphor either, even though they do have a visual editor, right?
• The Videotome family of engines aren’t visual.
• Texture Writer doesn’t have a story map IIRC?
• Gruescript isn’t visual.

I think I’d argue that most of the tools that are visual are coming from people outside the interactive fiction space who are making tools without reference to what the community likes? Although there certainly are people who do like the flowchart metaphor of Twine… and hey, there it is for them to use.

[zarf (Andrew Plotkin)]

I will note that the headline question subtly mis-states the history. Twine came after Inform, TADS, etc. It appeared at the same time as ChoiceScript.

Twine took off fast because there was a large audience of users who didn’t realize they wanted to use a visual-node tool but loved it as soon as they tried it. Other people didn’t, which is why there are several popular options in that space.

[oldskultxo]

That’s a fair point. I probably over-generalized by using Twine as the mental model because it’s what many people encounter first.

My concern is slightly different though: regardless of whether the tool is visual or text-based, authors often end up having to embed logic structures (conditions, variables, state checks) directly into the writing process.

What I’m interested in is whether tools could separate those layers better — letting writers stay closer to the narrative flow while the structural logic lives somewhere else.

[oldskultxo]

That’s a good clarification — you’re right that the earlier IF ecosystem was mostly text-based.

I think what fascinates me is how different mental models emerge from these tools. Twine encouraged people to think in terms of story graphs, while parser systems encouraged thinking in terms of simulation and rules.

I’m curious whether there might be other models that keep the narrative flow central while still supporting complex state and structure.

[oldskultxo]

“usually” was probably too strong.

What I meant is that many newcomers to IF end up discovering the node-based metaphor first (especially through Twine), and that shapes their expectations of what an IF tool should look like.

[oldskultxo]

Reading some of the replies here made me realize that I probably framed the idea poorly.

What I was actually thinking about is a slightly different problem: how interactive fiction tools mix prose and logic during the writing process.

In many systems — visual or text-based — authors end up embedding variables, conditions, and state checks directly into the narrative flow.

I’m curious whether tools could separate those layers more clearly: letting writers stay closer to the prose while structural logic lives somewhere else.

(Also, the word “usually” probably sounded stronger in English than what I had in mind in Spanish.)

[Giger_Kitty]

Design-wise, it seems inescapable that, at its simplest (like, say, a CYOA-type with no variables or counters, just branching paths) IF will always be at least a number of branching paths. Diagrams seem inevitable. I mean, you may not be drawing diagrams, but in your head there are diagrams of the various paths and branches.

Your project seems to be similar in that way. But I haven’t tried it, so I’m just going from your descriptions.

It’s a valid question you’re asking. It seems similar to the question that caused Inform 7 to exist in the first place; I7 goes to some pains to make the programming feel non-intrusive and like writing. Parser-wise, I don’t imagine it can go much more in that direction without sacrificing its world modelling (as usual, I’m happy to be proven wrong).

But again, inherently, since you’re making something interactive, the design will always be branches and flowcharts and switches. And the software needs a place for them to live. And I wonder whether separating them might not cause more confusion…

…but I will say again, in these instances I do enjoy being proven wrong, so keep working on it to showcase how it can work.

Example, in I7 being able to inject text substitutions directly into the text seems to be an excellent way to construct paragraphs, especially with random/sequential bits rules by “[one of]”. Having to separate those from the text seems like doing away with a great convenience, and obfuscating instead of helping. I think.

EDIT - I think having the writers live too far away from the structural logic may make the logic poorer and frailer. The thing about IF is, it’s both I and F. The trick is having them work well together. Otherwise you might as well just have F. However, should a writer decide to make IF that is more F than I, then by all means yes, they should have something at their disposal to help them. I thought what was around already took care of that, but it’s not really my area, so if I’m wrong and it doesn’t, sure, let’s have another go at craking it.

[JoshGrams]

@oldskultxo

My concern is slightly different though: regardless of whether the tool is visual or text-based, authors often end up having to embed logic structures (conditions, variables, state checks) directly into the writing process.

I guess I don’t think that pushing the logic information over to a prominent sidebar feels that much different than Dendry putting all the logic in the front-matter section of each scene, or Ink putting the logic in curly brackets at the start of an option: in either case you can just ignore it in writing mode, or write the prose without the logic and come back and add the logic later, and I think plenty of people do… so I don’t think it’s as much of a problem as you’re making it out to be. But I’m sure there are other people out there who are also bothered by it.

And I think it’s fairly common for writers to work in a word processor or other tool where they have spellcheck etc. and then move the code in-engine later.

It’s interesting to compare your approach to Inform’s natural-language-esque programming, which a lot of people really like. I find that I slightly dislike natural-language-looking code because it looks so similar to prose: if the code looks more different it’s easier for me to distinguish and tune out one or the other…

[oldskultxo]

That’s a really thoughtful point, thank you.

I completely agree that the branching structure never disappears — even if you don’t draw diagrams, the structure still exists conceptually.

What I’m exploring is not removing that structure, but experimenting with where it lives during the writing process.

In many tools the prose and the structural logic are tightly interwoven, which can make writing feel like constant context-switching between narrative and system thinking.

The idea I’m exploring is whether the structure could exist as its own layer, while the prose remains readable and editable as prose.

So the structure still exists — it just doesn’t necessarily live inside the paragraphs themselves.

But your concern about logic becoming weaker if it’s too far away from the text is very interesting, and it’s something I’m still trying to understand better.

[oldskultxo]

That’s a really interesting perspective, especially the point about natural-language-looking code.

You’re right that many systems already allow you to ignore the logic while writing, or to add it later. And the fact that many authors draft prose in a separate editor first probably says something about the friction there.

The question I’m exploring is slightly different: whether tools could keep the prose readable as prose even when the structural logic becomes more complex.

Not hiding the logic completely, but letting it exist as its own layer rather than inside the paragraphs themselves.

I’m still trying to understand whether that actually helps writers or just moves the complexity somewhere else.

[Giger_Kitty]

@oldskultxo

But your concern about logic becoming weaker if it’s too far away from the text is very interesting, and it’s something I’m still trying to understand better.

Rereading my own post, I’d like to ammend my thoughts a bit. “Frailer and weaker” is part of it, to be sure, but I think I’m reducing things too much by putting it like that. I would rephrase that. I think it’s more like, they become less integrated. They mix less well. They are more like oil and water. The old “crosswords at war with a narrative” thing. I fear that if an author lives too much on the narrative side, the crosswords will suffer, but more than that, the narrative will not take full advantage of the crosswords. The point, and beauty, of IF, is that the crosswords can enhance the narrative. A writer who lives too far away from the logic may not even get to find out how much.

[J_J_Guest]

@Giger_Kitty

Diagrams seem inevitable. I mean, you may not be drawing diagrams, but in your head there are diagrams of the various paths and branches.

The diagrammatic presentation of Twine was what initially drew me to the program; I had a huge gamebook type of game that I’d been working on for years and I was keen to see what it looked like as a branching story. But the node graph was eventually why I gave up on Twine too. It just seemed unnecessary that every little bit of content had to have its own node. My big branching story quickly became a huge continent of nodes, complete with peninsulas and archipelagos. Navigating it became a feat of memorisation akin to a London cabbie learning the A to Z by heart. I frequently resorted to using the search tool, scanning the entire map for any node that had turned yellow. My second Twine game, Excalibur was smaller and better organised, but I still found it painful. The little diagrams on the back of Choose Your Own Adventure books are fun to look at, but as a writer I find node graphs entirely unnecessary.

[oldskultxo]

That’s a really interesting way to put it. “Less integrated” captures the concern better than simply “weaker.”

I agree that one of the beauties of IF is when puzzles, logic and narrative reinforce each other instead of competing. When that happens, the structure becomes part of the storytelling rather than something sitting next to it.

The separation I’m experimenting with isn’t really about distancing logic from narrative, but about changing where the interaction happens. Instead of mixing logic and prose line-by-line, the narrative remains readable as narrative, while a behavioral layer determines which pieces appear, when, and under what conditions.

In that sense, the text becomes more like a surface, and the logic becomes a system shaping that surface.

Whether that makes the relationship clearer or weaker is exactly the question I’m trying to explore.

[oldskultxo]

That’s interesting, because your experience highlights something I’ve been thinking about for a while: the difference between visualising structure and writing with that structure.

Node graphs are great at showing the shape of a branching system, but they also subtly push the author to think in nodes. Every narrative fragment becomes a unit in the map.

As projects grow, that can lead exactly to what you describe: continents, peninsulas and archipelagos of nodes. At that point the cognitive effort shifts from storytelling to navigating the structure itself.

What I’ve been exploring is whether it’s possible to keep the structure without making it the author’s primary writing model. Instead of writing node-by-node, the narrative remains continuous text, while a separate behavioral layer determines which parts appear, when, and under what conditions.

In that sense the structure still exists — but it acts more like a system shaping the narrative surface than like the visible skeleton of the work.

I’m not sure yet whether this actually scales better for large projects, but it’s an interesting design space to explore.

[J_J_Guest]

@oldskultxo

Instead of writing node-by-node, the narrative remains continuous text, while a separate behavioral layer determines which parts appear, when, and under what conditions.

It’s an interesting idea, but as an Ink user and aficionado I find it hard to imagine how you’d separate game text from game logic without losing track of when this particular piece of text appears, and why. I’ve used Inform 7 for years too, and it’s second nature to write, “if this is true, say this, otherwise say that.” Writing all the game text as a continuous stream with the logic elsewhere would surely mean flipping constantly back and forth between the two. I can’t see that being better than having everything there at a glance.

@oldskultxo

In many tools the prose and the structural logic are tightly interwoven, which can make writing feel like constant context-switching between narrative and system thinking.

But that’s the fun, and the skill, of writing IF! It uses both sides of the brain. It’s not like the two are different processes, they’re intertwined aspects of the single process of writing IF. At least, that’s my experience.

[oldskultxo]

Very interesting,and I can definitely see how that workflow works well once you’re comfortable thinking in terms of both prose and logic at the same time.

What I’m curious about is whether that mental model is equally comfortable for everyone — especially for writers who approach IF primarily from the narrative side rather than the programming side.

For some people the constant switching between narrative thinking and structural thinking can feel like friction, while for others (like you describe) it’s part of the craft itself.

So I’m exploring whether there might be room for tools that support a slightly different workflow, where the prose remains readable as prose while the structural layer exists alongside it.

[Encorm (N. Cormier)]

@oldskultxo

So I’m exploring whether there might be room for tools that support a slightly different workflow, where the prose remains readable as prose while the structural layer exists alongside it.

The potential limitation I see here is a limit on the complexity and/or responsiveness of the narrative.

A lot of the games I work on involve conversations that allow the player character to say a variety of things, but ultimately only have 1-2 distinct outcomes. You have three rounds of conversation to pick the correct response out of three options and accumulate enough points to pass or fail. Each response, correct or incorrect, will elicit a unique piece of text from the NPC at each step – so for a single conversation that’s nine different conversation chunks to keep track of, plus an additional two depending on whether you passed or failed overall.

Setting up the code logic structure ahead of time makes this very easy to keep track of (just fill in the blanks appropriately). How would this work in your system? Do you have a fairly streamlined solution to keep track of all the moving parts, or by its very nature is this meant for less complicated games along the lines of a classic CYOA?

[oldskultxo]

That’s a really good example of the kind of structure that raises interesting questions for this approach.

In the model I’m exploring, the interaction logic would still exist (rounds, scoring, pass/fail conditions, etc.), but instead of organizing the narrative node-by-node, the conversation text could remain continuous while the behavioral layer determines which fragments appear.

So rather than pre-structuring the text into nodes, you might have a set of possible response fragments that are selected based on the current round and accumulated score.

The complexity doesn’t disappear — it just lives in the structural layer rather than being embedded directly into the prose.

I’m still trying to understand whether that actually makes complex interactions easier to manage or just shifts the complexity somewhere else.