The Easiest Way to Organize Game Dialogue Without Spreadsheets
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.