Why Your Game’s Data is a Mess
Introduction
Your game’s data is scattered across spreadsheets, engine-specific scripts, and disconnected middleware. Every change feels like a game of Jenga ; pull one piece ; and the whole thing might collapse. Sound familiar?
Game development relies on five critical domains: content schema, logic, dialogue, localization, and documentation. Most studios treat these as separate silos, leading to inefficiencies, errors, and collaboration bottlenecks. The result? Wasted time, frustrated teams, and games that take longer to ship.
Fragmented pipelines are the silent productivity killer in game development. Here’s why; and most important; how to fix it.
Five Domains of Game Development (And Why They Clash)
Game development isn’t just about coding or art; it’s about managing interconnected systems. When these systems don’t talk to each other, chaos ensues. Let’s break down these five domains and how their isolation creates problems.
1. Content Schema: The Foundation That’s Often an Afterthought
Current State
Your game’s data—characters, items, quests, stats; is likely stored in one (or more) of these places:
Spreadsheets (Google Sheets, Excel)
JSON/XML files (manually edited)
Engine-specific classes (e.g., Unity ScriptableObjects, Unreal Data Assets)
These tools are great for their intended purposes, but they weren’t designed to scale with the complexity of modern games. As your project grows, you end up with:
Inconsistent formatting (e.g., one spreadsheet uses
health_points, another usesHP)Manual updates (e.g., copying data from a spreadsheet into the engine)
Versioning nightmares (e.g., "Which file has the latest stats for this enemy?")
Pain Points
Duplicated work: Designers update stats in a spreadsheet, but engineers must manually copy-paste those changes into the game’s code. If they forget, the game ships with outdated values.
Desyncs: Changes in one place (e.g., a spreadsheet) aren’t reflected elsewhere (e.g., the engine or dialogue system). This leads to broken references and inconsistent gameplay.
No single source of truth: Without a centralized system, teams waste time hunting down the latest version of a file or value.
2. Logic: Scripts That Don’t Talk to Each Other
Current State
Game logic—quests, AI behaviors, interactions—is often hardcoded in:
Engine-specific scripts (C#, Luau, Python)
Middleware (Ink, Yarn, Articy:Draft)
These systems are disconnected from the rest of the game. For example:
A quest script in Unity references a dialogue ID, but that ID is managed in a separate tool.
A change in the dialogue system might break the quest script, but no one notices until playtesting.
Pain Points
Brittle systems: A small change in one part of the game (e.g., renaming a character) can break logic in another part (e.g., a quest script).
Engine lock-in: Logic written for Unity won’t work in Unreal (or vice versa). If you switch engines, you’re starting from scratch.
Non-technical team members are locked out: Writers and designers can’t tweak logic without asking an engineer for help.
3. Dialogue: The Black Box of Game Narrative
Current State
Dialogue is often authored in standalone tools like:
Twine
Yarn Spinner
Articy:Draft
Custom editors
These tools are disconnected from the game’s data. For example:
Dialogue references characters or items using hardcoded strings (e.g.,
"hero_sword").If a character’s ID changes in the schema, all dialogue referencing them breaks.
Pain Points
Broken references: Rename a character in the schema? Now all dialogue referencing them is broken, and you won’t know until runtime.
No validation: Typos in variable names or IDs go unnoticed until the game is played.
Localization headaches: Translating dialogue means manually updating keys in a separate system, which is error-prone and time-consuming.
4. Localization: The Forgotten Stepchild
Current State
Localization (translating your game into other languages) is typically managed in:
Separate TMS (Translation Management Systems) (e.g., Crowdin, Lokalise)
Spreadsheets (e.g., Google Sheets with columns for each language)
These systems are not linked to the game’s content schema or dialogue graphs. For example:
A character’s name is updated in the schema, but the localization keys aren’t remapped.
Translators work blindly, without context for how strings are used in-game.
Pain Points
Manual key mapping: Translators must manually match strings to their in-game usage, which is slow and error-prone.
Schema migrations break everything: Update a character’s name in the schema? All localized strings for that character now reference a dead ID.
Last-minute scramble: Localization is often an afterthought, leading to rushed, error-prone updates before launch.
5. Documentation: The Graveyard of Outdated Notes
Current State
Documentation is usually written in:
Google Docs
Confluence
Notion
Markdown files in a repo
These docs are static and disconnected from the game’s data. For example:
A document describes a quest system but doesn’t link to the actual quest data or scripts.
If the schema or logic changes, the docs don’t update automatically.
Pain Points
Outdated instantly: A change in the schema or logic isn’t reflected in the docs, leading to confusion and mistakes.
No relationships: Docs describe systems but don’t show how they connect to the rest of the game.
Wasted onboarding time: New team members spend weeks untangling the web of disconnected tools and outdated docs.