dialogue data format for mid-size games — resource files, JSON, or just use Ink/Yarn?

we shipped a game using Ink and i'd do it again, but there's one thing nobody warns you about: Ink is great for writers and kind of terrible for reviewing structure. the syntax reads well line by line but getting a birds-eye view of a complex branch is rough. ended up building a small JSON export visualizer just so we could sanity-check that we hadn't written ourselves into dead ends.

at that point i started wondering if we'd have been better off with JSON from the start and slightly better custom tooling. for 60+ conversations i'd still lean Ink, the writer experience is genuinely good, but budget time for visualization tooling if anyone on your team needs to see the full structure at once.

One thing nobody's mentioned: YAML as a middle ground between JSON and full DSL. It's more readable than JSON for branching structures: no brace noise, multiline strings work, inline lists are clean. A non-technical writer can pick it up faster than Ink syntax or a visual node graph.

Used it on a small narrative side project and had a writer editing files directly after a 15-minute walkthrough. The tradeoffs are the same as any flat-file approach (no type safety, diffs get noisy past a certain size), but as a bridge between "too technical" and "requires learning a new tool" it's underrated. My rough ceiling was around 50 conversations before the lack of visual structure started hurting navigation.

we shipped a small narrative game in Godot 4 using custom Resource subclasses for dialogue and it held up well to about 80 conversations. basically a DialogueNode resource with typed fields for speaker, text, a choices array, and a next-node reference. stays in .tres files, version control is fine, you get inspector editing for free.

the thing that pushed me toward Yarn Spinner on my next project wasn't the data format, it was the editing experience. writers don't want to touch .tres files in a code editor. if it's just you doing the writing, resource files are honestly great. the moment anyone else needs to author dialogue, get a proper tool.

One angle that hasn't come up: if the person writing dialogue isn't comfortable with code or graph editors, a Google Sheet with a defined schema can work as a writer-friendly intermediate layer. Writer fills out rows (id, speaker, text, conditions, next_id), a build script pulls via the Sheets API and bakes to whatever format the game actually loads. We did this on a project where the narrative designer wasn't touching the engine at all, and the iteration speed was genuinely good. She could edit text, reorder conversations, and flag broken branches in a format she already knew.

The failure mode is when branching gets deep enough that a flat table stops representing it cleanly. Past maybe 3 levels of nesting, row-based dialogue starts requiring a lot of mental overhead to follow. At that point Ink is probably the right call. But for straightforward branching with a non-technical writer, the spreadsheet approach is underrated.

One thing the thread hasn't touched on: schema migration. Whatever format you pick, your dialogue structure will change mid-project. A new field for speaker portrait. A localization key. A "skip if flag set" condition you didn't plan for. Multiply that across 60+ conversations and you're in real pain unless you anticipated it.

Custom Resource subclasses in Godot handle this best in my experience. Adding a new exported property with a default just works, old files load without breaking. JSON and YAML both require an explicit migration pass every time the schema changes, which is fine if you actually write one. Whatever you choose, put a schema version field in from day one even if you never increment it. Future you will be grateful.

tbh the format question is mostly a "who's writing dialogue" question more than a technical one. if it's just you in the editor, custom Resource subclasses in Godot are great. fast iteration, type-safe, no extra deps. but the second a non-dev needs to touch it you're gonna end up with Yarn anyway. found this out after building a whole bespoke system, then a writer friend wanted to contribute, spent like 20 minutes trying to add nodes in the Godot editor, and noped out completely lmao. Yarn Spinner's graph view alone is worth the dependency if there's any chance of collaboration.