One post tagged with "branching narrative"

You're six weeks into writing your game's dialogue. Your node graph has 400 boxes connected by a web of arrows you can barely follow. Or your script file has grown to 3,000 lines and finding where a particular branch leads now takes ten minutes of scrolling. Neither feels right, and neither scales the way you hoped.

Sound familiar?

If you've spent any time building a story-driven game, you've probably wrestled with this choice: use a visual dialogue tree editor, or write branching scripts in text? The answer matters more than most people realize — because the wrong choice doesn't just slow you down, it can make your dialogue system genuinely painful to maintain over months of development.

This article breaks down both approaches honestly, explains where each one breaks down, and makes the case for a third option that most developers overlook.

What Are Dialogue Trees?​

A dialogue tree is a visual, graph-based representation of your game's conversations. Every line of dialogue, every choice, every NPC response gets its own node. Nodes connect to each other with arrows that represent flow: "after this line, the player sees these choices; after they choose, the conversation continues here."

Tools like Twine, Yarn Spinner, and most node-based dialogue editors use this model. It's intuitive at first glance — you can literally see the shape of your narrative as a flowchart.

Where Dialogue Trees Shine​

• Small projects: A visual novel with 15–20 key choice points is perfectly manageable as a tree. You can hold the entire structure in your head.
• Communicating structure to your team: Showing a programmer or designer how a quest's dialogue flows is easy when there's a literal diagram.
• Early prototyping: Want to sketch out a conversation to test pacing? A quick node graph is faster than writing a script.
• Writers who aren't technical: No code, no markup, just drag boxes and connect lines.

That's a strong case. And for small or early-stage projects, a dialogue tree is often the right call.

Where Dialogue Trees Fall Apart​

Here's the thing nobody mentions until you're already deep in a project: dialogue trees scale terribly when you put linear dialogue in them.

Most tree-based tools treat every line of dialogue as a node. So an NPC introduction that goes like this:

"Welcome to the village, traveler. I haven't seen your face before."

"I'm passing through."

"Are you now? Stay a while. There's trouble on the road ahead."

"What kind of trouble?"

[Choice: Ask about the road / Ask about the village / Leave]

...becomes five nodes before you even hit the first real choice. And that's a short exchange.

A 5-minute conversation with 8 choice moments can easily balloon to 40–50 nodes in a pure tree tool — most of which are single lines of dialogue that don't actually branch. Your graph becomes a sprawling mess of boxes and arrows, and finding anything requires zooming, panning, and scrolling through visual noise.

This is what developers call node spaghetti: a graph that's technically correct but visually overwhelming. At this point, your "visual" tool has stopped being visual in any useful sense.

What Are Branching Scripts?​

A branching script is a text-based approach to the same problem. Instead of a visual graph, you write dialogue in a specialized format — like Ink, Yarn, or a custom YAML/JSON structure — that uses markup to indicate choices, conditions, and branching.

An Ink-style script for the same NPC exchange might look like this:

Welcome to the village, traveler. I haven't seen your face before.
I'm passing through.
Are you now? Stay a while. There's trouble on the road ahead.
What kind of trouble?

* [Ask about the road] -> road_trouble
* [Ask about the village] -> village_info
* [Leave] -> leave_scene

It's compact. It reads like a real script. And it scales much better than a tree for large projects.

Where Branching Scripts Shine​

• Large projects: An RPG with hundreds of scenes, thousands of lines, and complex variable-driven dialogue is far more manageable as text than as a graph.
• Version control: Text files work beautifully with Git. You can diff, merge, and track history in ways you simply can't with a visual tool's proprietary format.
• Complex conditions: Variables, flags, counters — scripting languages handle these elegantly in text.
• Technical writers and programmers: If your narrative designer thinks in code, a script format often feels more natural than a drag-and-drop interface.

Where Branching Scripts Fall Apart​

The problem with pure scripts is the inverse of the problem with pure trees: you lose the ability to see the structure.

When your script is 3,000 lines long, finding where a particular branch leads requires either a deep mental model of the entire file or a lot of manual searching. The visual overview is gone entirely. You're navigating blind.

New team members — especially writers without a technical background — often struggle significantly with this. "Where does the 'refuse quest' option lead?" becomes a real question that takes 20 minutes to answer. Onboarding gets harder. Collaboration gets harder. And when you need to show someone the shape of a conversation — a director, a playtester, a publisher — you have nothing to show them.

The Real Problem: One Tool for Every Kind of Dialogue​

Here's the insight that both camps miss: not all dialogue is the same.

Some dialogue is genuinely branching. A player makes a choice, and the story diverges meaningfully. These moments benefit from visual representation. You want to see the branches. You want to see what connects to what.

But most dialogue is linear. It's an exchange — NPC talks, player responds, NPC replies. There's no branch. It's just conversation. And putting every line of it in its own graph node, or annotating it with markup syntax in a script, is overkill in opposite directions.

The mismatch is the root cause of both failure modes:

• Trees fail because you're using a branching structure to represent non-branching content. Everything becomes a node, the graph explodes.
• Scripts fail because you're reading branching structure as linear text. The structure is there, but invisible.

The question isn't trees or scripts. The question is: what's the right tool for each part of the dialogue?

The Hybrid Approach: Nodes for Branches, Text for Flow​

The answer most projects eventually arrive at — usually after suffering through one of the two failure modes — is a hybrid approach:

1. Use nodes only for structural moments: choices, divergences, scene transitions, conditional branches. The moments where the story actually forks.
2. Write linear dialogue as plain text inside each node: no new node for every line — just write the exchange naturally, like a script.

This keeps your graph clean and meaningful. A conversation with 8 genuine choice points gets 8–10 nodes, not 80. You can see the narrative shape at a glance without drowning in single-line boxes. And each node's internal dialogue is readable and writable without fighting a GUI — because it's just text.

A simple quest structure in this model might look like:

• Node 1: Guard intro scene (plain text, 6 lines of dialogue, no branches)
• Node 2: Choice — "Bribe guard / Use stealth / Confront them" (3 output ports)
• Node 3: Bribe outcome (plain text, 4 lines)
• Node 4: Stealth outcome (plain text, 3 lines)
• Node 5: Confrontation with variable check (conditional, 2 outcomes)

Five nodes for a full quest conversation that would take 40+ nodes in a pure tree tool. Clean, readable, maintainable — and the graph actually tells you something useful.

This is the design philosophy behind Drafft. Nodes represent divergence. Everything inside a node is a script. You don't pay the cognitive overhead of a tree editor for linear content, and you don't lose the visual overview for the moments that matter.

Picking the Right Approach for Your Project​

Use a Pure Dialogue Tree if:​

• Your project is small scope (under 50 nodes total)
• You're a solo dev who's comfortable with visual editors
• You're in early prototyping or a game jam
• Your narrative is a simple visual novel with few, clear choice moments

Watch out for: Node spaghetti appearing around the 100-node mark.

Use a Branching Script if:​

• Your team is technical (programmers, technical designers)
• You're building a large project with thousands of lines
• Your game requires version control and diff-ability
• You're handling very complex variable-driven logic

Watch out for: Losing the narrative overview as the file grows.

Use a Hybrid Approach if:​

• You're building a mid-to-large project where writers and programmers both touch dialogue
• You're an indie team maintaining dialogue over months of development
• You've already hit the limits of a pure tree or pure script approach
• You want a system that scales without forcing you to start over

The hybrid approach is less common in the ecosystem, which is partly why it's underserved. Drafft is specifically designed around this model — built by indie developers for indie developers, as a practical alternative to expensive enterprise tools.

A Note on Enterprise Tools​

The honest version of this conversation includes acknowledging that enterprise-grade tools like Articy:draft do handle the hybrid approach well. They're powerful, flexible, and used on AAA titles. They're also expensive, complex, and built for teams with dedicated narrative tooling budgets and onboarding time to spare.

For indie developers — especially solo devs or small teams — that overhead is a real cost. Drafft was built to fill that gap: the hybrid approach, accessible and affordable, without the enterprise price tag or the steep learning curve. Built by indie developers who ran into these exact problems and couldn't find a tool that solved them without requiring a corporate budget.

Conclusion​

The "dialogue trees vs. branching scripts" debate is a bit of a false binary. Both approaches are genuinely good at something, and both genuinely break down at something else.

The real insight is simpler than it sounds: use nodes for the moments that actually branch, and write everything else as text.

That's not a compromise — it's the right tool for each job. And it's the approach that keeps dialogue manageable whether your game has 50 scenes or 500, and whether you're working alone or with a team.

If you want to see what that looks like in practice, Drafft is worth a look.