2 posts tagged with "indie game development"

Alba Mayo is a Spanish indie developer building a visual novel about tic-tac-toe. He's been documenting his development process on YouTube for years, and in one of his videos he describes his dialogue workflow with the resigned clarity of someone who knows exactly what's wrong with it.

His scripts are CSV files. Each row is a line of dialogue. The columns hold the game commands, the Spanish text, and the translations for other languages. The game reads these files directly, which means they have to stay in plain text — no colors, no bold, no visual hierarchy of any kind.

To make them writable, he works in LibreOffice Calc, where he can at least apply cell formatting. He uses # ALL CAPS COMMENTS between sections to try to mark where one scene ends and another begins. "Difficult to see," he admits, "and for long scripts it doesn't work at all." A community member eventually wrote him a macro so that hitting Ctrl+S auto-exports the CSV, saving the manual export step.

It works. Barely. And every hour he spends maintaining this system is an hour not spent writing the game.

Here's the part that stuck with me, though. He knows this is a problem. In the same video he briefly considers proper solutions — using an external tool, building his own — and then talks himself out of both:

"I could look into using some external tool to display and edit these scripts more visually, but that would come with a whole series of limitations, plus it would cost time to implement, and who knows what other problems would arise that you don't see until you encounter them. I could also build my own tool, but same problem."

He moves on. The macro stays. The spreadsheet stays.

This is not a failure of judgment. This is the most rational possible response to a real problem with no obvious safe solution. And it describes the workflow of more indie developers than most people realize.

Why Devs End Up Here​

Organizing game dialogue in a spreadsheet is actually a smart instinct. Rows map naturally to lines of dialogue. Columns give you a clear way to separate character names, dialogue text, language variants, and script commands. If your game engine reads CSV or JSON, the export path is straightforward. You're already thinking in structured data, which is correct.

The problem isn't the data model. It's the tool.

Spreadsheets weren't built for dialogue. They don't know what a scene is. They don't know what an actor is. There's no concept of "this is a branching choice" vs. "this is a linear exchange." You're building those concepts yourself out of cell colors, comment rows, and naming conventions — which means rebuilding them from scratch every time you open a new project, and maintaining them manually as the project grows.

The # ALL CAPS section header is you trying to get your spreadsheet to behave like a script editor. The macro is you trying to get it to behave like an export pipeline. These aren't clever optimizations. They're workarounds for a fundamental mismatch between the tool and the job.

The job is writing and organizing interactive dialogue. The tool is a grid for numbers.

The Switching Cost That Feels Bigger Than It Is​

Alba's hesitation is worth taking seriously, because he's right that switching costs are real. Mid-project tool migrations can go badly. You move your data, lose some formatting, spend a week debugging the import, and end up worse off than when you started.

But there's another cost he's not accounting for: the cost of staying.

Every new scene added to that CSV file makes navigation harder. Every additional language column makes the grid wider and more fragile. Every script command that needs tweaking means finding the right row across hundreds of others. The workaround that was "good enough" in month one becomes a genuine drag by month six.

"If I keep settling for easy options," he says at the end of the video, "maybe the game will finish someday." He means it as a joke. But it reveals the real tension: the spreadsheet isn't a neutral choice. It has an ongoing cost, and that cost compounds.

The question to actually ask isn't "what will the migration cost?" It's "what is the current setup costing me per week, and how does that compare?"

What Dialogue Organization Actually Needs​

Before looking at any specific tool, it's worth being precise about what the spreadsheet is failing to provide. Understanding that makes it easier to evaluate whether any alternative actually solves the problem — or just moves it somewhere else.

What a dialogue workflow needs:

Visual hierarchy. A long script needs to be scannable. Scenes, acts, and beats should be visually distinct without requiring a row of ALL CAPS comments. You should be able to open a file and orient yourself in seconds, not minutes.

Character context. When you're writing a line of dialogue, you need to know who's speaking without hunting across columns. The character should be a first-class part of the structure, not a value in column B.

Non-linear organization. Game dialogue isn't linear. A quest might have five different outcomes, a scene might branch three ways, a character might have different dialogue based on game state. A spreadsheet forces you to represent all of that as rows — which means your non-linear structure is secretly disguised as a very long linear file.

An export path that just works. You shouldn't need a macro for this. The output format your engine expects — JSON, CSV, whatever — should be one click, not a manual process you have to remember.

If you read that list and recognized "wait, that's exactly what my spreadsheet doesn't do," you've correctly identified the gap.

What a Tool Built for This Looks Like​

This is where I'll mention Drafft, not because it's the only option, but because it was built to solve exactly these problems for indie developers.

The Script Editor in Drafft is the core of dialogue organization. Scripts live inside folders inside your project — you organize them the way your game is structured, not the way a spreadsheet happens to be structured. That hierarchy exists natively — you're not faking it with comment rows or cell formatting.

Character names aren't column values. They're tags that tie back to Actor documents — each character in your game has their own page where you can track their voice, personality, relationships, and notes. When a character speaks in a script, you're referencing a real object in your project, not typing a name into a cell and hoping you spelled it consistently.

This is meaningfully different from a spreadsheet, not just cosmetically different. When you want to see every line a specific character has, you can. The data is structured because the tool is structured.

The difference in day-to-day workflow is less dramatic than a full migration sounds. You're still writing dialogue as text — Drafft's Script Editor is text-based, not a drag-and-drop GUI. If you're comfortable writing in plain text or markdown, the transition is mostly about where files live, not how you write them.

(If you're thinking about how dialogue structure relates to branching — whether to use a tree, a script, or something in between — that's a separate question covered in Dialogue Trees vs. Branching Scripts: Which Should You Use for Your Game?)

The Export Problem, Solved​

One of the specific things Alba mentions is the two-file problem: he maintains an ODS file for writing and a CSV file for the game. They have to stay in sync manually (hence the macro). If he edits the CSV directly, those changes won't be in the ODS. If he edits the ODS and forgets to export, the game runs stale dialogue.

This is a version control problem disguised as a workflow problem. There are two sources of truth, and keeping them synchronized is a manual process that's easy to get wrong.

Drafft exports to JSON directly from the structured document. There's no intermediate file format, no separate writable copy, no sync step. The document you write in is the source of truth, and when you export, you get the engine-ready output.

For engines that can read structured JSON — which is most of them — this means the export path is zero-friction. And if your engine needs a specific shape for that JSON, Export Mappings let you define exactly how each speech line or command gets serialized — so the output matches what your engine expects without a post-processing step.

If you want to skip the export step entirely, Drafft also includes a lightweight REST API that lets your game query a loaded project directly. It's opt-in and designed for iteration — useful when you want to tweak dialogue and see results in-engine without a full export cycle.

An Honest Assessment​

No tool is a free lunch, and it's worth being clear about the tradeoffs.

Drafft has a learning curve. Not a steep one, but you'll spend a few hours getting oriented to how documents, actors, and scripts relate to each other. That's real time, and it's fair to account for it.

The Actors system — while genuinely useful — is functional rather than elaborate. If you need detailed character databases with complex relational queries, you might want something more purpose-built. For most indie projects, it's more than enough.

On the other hand, if your spreadsheet was also doing double duty as a data store for items, variables, or other game state — Drafft covers that too. Variables, Items, and Grids are dedicated document types for exactly that kind of structured data, so you're not splitting your project across Drafft for dialogue and a spreadsheet for everything else.

And plain CSV/spreadsheet workflows do have one advantage that's worth acknowledging: they're universally writable. Any text editor, any spreadsheet app, any platform, zero setup. If your team includes contributors who aren't technical and aren't willing to learn a new tool, that matters.

That said, for a solo developer or a small team where everyone is already in the same tools, the friction argument against switching is almost always overstated. Most developers who make the switch report that the setup cost paid for itself within a few weeks.

The Real Cost of "Good Enough"​

A macro that auto-exports on save is a clever solution to a problem that shouldn't exist. # ALL CAPS section headers are a clever solution to a problem that shouldn't exist. They're evidence of thoughtful developers adapting to a tool that isn't quite right — not evidence that the tool is right.

The thing about organizing game dialogue in a spreadsheet is that it never gets easier. It scales in the wrong direction. The first scene is fine. The tenth is a bit annoying. The fiftieth is genuinely painful. And by then you've invested enough that migrating feels scarier than it actually is.

If you're early in a project, now is the right time to ask whether your current setup will still be comfortable when you have ten times as much content. If you're mid-project and already feeling the friction, the migration cost is probably lower than you think — and definitely lower than the remaining months of maintaining a workaround.

Game dialogue is structured information. It deserves a structured tool.

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.