Game Data Management - theseus.works

theseus.works for designers

Theseus gives your designers a proper interface for game data. Define objects, set fields, manage records, and push changes directly into your Git repo via PR. Your data lives where your code does. Your programmers stop being the middleman.

Theseus - Iron Keep / Weapons

Objects

Weapons
Characters
Quests
Levels
Loot Tables

Project

Pull Requests
History
Schema
Weapons 24 records
Filter
Sort
+ New
Name Damage Rarity Status
Iron Sword
45
Common
● Live
Shadow Dagger
62
Uncommon
● Live
Stormcaller
118
Rare
● In PR
Voidreaper
240
Legendary
● Draft
Thornwhip
38
Common
● Live
Scroll to explore

The problem

You've outgrown the spreadsheet. You haven't built what comes next.

Mid-size studios get stuck in an awkward middle ground. Too big for spreadsheets to hold up, not big enough to have someone whose job is building internal tools. So the work falls to whoever has a spare afternoon, which is nobody.

01

Programmers as bottlenecks

A designer needs a new field. That means finding a programmer, explaining what they need, waiting for it to be built, and hoping the spec didn't change in the meantime. This happens constantly.

02

Spreadsheets with no guardrails

One wrong paste and three weeks of balancing work is gone. There's no history, no validation, nothing stopping anyone from saving over something important. It's a shared document masquerading as a database.

03

The data never just gets there

When something changes in a spreadsheet, someone still has to export it, convert it, and get it into the build. Usually that someone is a programmer, and usually it's not the first time they've done it this week.

04

No record of what happened

A weapon does no damage. Was it always like that? Did someone change it yesterday? You can't tell. Spreadsheets don't know and don't care. Debugging a data problem with no history is a bad afternoon.

"We spent six weeks building an item editor. By the time we shipped it, half the schema had changed. That's the last internal tool we'll ever write."

How it works

Design data, shipped like code.

Designers own their data. Engineers own the merge. The PR workflow your team already uses handles the rest.

01

Define your objects

A designer builds a Weapon object: Damage, Range, Rarity, whatever the game needs. Field types, constraints, and relationships are set up in the UI. No code, no asking for help.

02

Fill in the records

Add a sword. Set the damage to 45. Mark it uncommon. If something's wrong - a number out of range, a required field missing - it gets flagged before the designer even submits.

03

Submit a PR

The designer raises a pull request. Theseus puts the data on a branch in your GitHub repo, formatted as JSON. A reviewer looks it over and approves or kicks it back, same as any other change.

04

Sync in Unity

The PR merges. The Unity package picks up the change and regenerates the C# class. sword.Damage returns 45. Nobody had to write a parser or update a struct.

Strongly-typed. Auto-generated. Always in sync.

When a designer defines a Weapon in Theseus, the Unity package generates a C# class from the schema. Programmers don't need to write a dictionary lookup function, or parse strings. Just typed properties. Simple.

Add a field and the class updates on next sync. Remove one and it gets marked [Obsolete]. A compiler warning, not a build failure. A cleanup task is automatically raised in the task tracker.

No silent breaking changes. Existing records keep the data they had at the time the field was removed. New records use the defined default. Nothing disappears without somebody knowing about it.

Weapon.cs - auto-generated by Theseus
// Generated by Theseus - do not edit manually
// Last synced: schema v4 - 2 fields updated

public class Weapon
{
    public string  Name      { get; set; }
    public float   Damage    { get; set; }
    public string  Rarity    { get; set; }
    public float   Range     { get; set; }

    // Deprecated in schema v3 - cleanup task #47
    [Obsolete("Removed in schema v3. See task #47.")]
    public int Price { get; set; }
}

// Usage - anywhere in your game code:
var sword = TheseusData.Get<Weapon>("iron-sword");
Debug.Log(sword.Damage); // 45

What's included

What you get.

Custom Object Types

Weapons, quests, NPCs, levels, dialogue nodes, define whatever your game uses. Presets for the common ones, blank slate for everything else. Fields, types, relationships, all in one place.

Field Validation

Set value ranges, mark fields as required, restrict to a list of allowed values. Validation runs in the UI as designers type, and again at PR submission. Bad data doesn't get far.

Object Relationships

A Quest can reference its reward Items. A Level can list its Characters. These links are enforced. Related records surface in the UI without any extra setup.

GitHub PR Workflow

Theseus creates the branch and raises the PR. Designers submit changes, reviewers approve them, and the data merges exactly like code, because it is. Your existing review process doesn't change.

Audit Trail

Every change is logged; who made it, what they changed, which PR it came in on. Field-level diffs, full record history. When something breaks you can actually find out why, which is more than a spreadsheet will ever tell you.

Unity Code Generation

The Unity package generates typed C# classes from your schema on every sync. Removed fields are marked [Obsolete] rather than silently dissapearing. No struct to maintain. No parser to write.

Works with your stack

Fits into your pipeline.
Not the other way around.

Your studio already has tools. Theseus works alongside them, not instead of them. Bring your Twine dialogue, your Google Sheets, your CSV exports. Import them, structure them, put them under version control. You don't have to start over.

Available at launch
Google Sheets Notion CSV

Spreadsheet & Database Import

Most studios live in spreadsheets or Notion until something breaks badly enough to force a change. The importer walks you through mapping your existing columns to Theseus field types. Your data comes with you, you're not rebuilding from scratch.

Available at launch
GitHub Unity

Version Control & Engine

Data goes into your existing GitHub repo as JSON. The Unity package reads from there and generates typed C# classes on sync. Your repo stays authoritative. Theseus is the interface on top of it.

Planned
Twine Yarn Spinner

Dialogue Tools

Writers use Twine or Yarn Spinner, and that's not changing. The Theseus importer maps exported dialogue trees into structured object types, with nodes tied to the translation lookup table. Same tools, proper version control.

Planned
GitLab Bitbucket Perforce

More Version Control

GitHub at launch. GitLab, Bitbucket, and Perforce to follow.

Already have data somewhere? Bring it in.

Import your existing data, map your columns to your fields, and move on. If your data is in a spreadsheet, a Notion database, or a CSV sitting on someone's desktop, it'll work.

.CSV
Google Sheets
Notion DB
Twine JSON
Yarn Spinner

The alternative

Why not just use a spreadsheet?

Capability Spreadsheets Theseus
Field-level validation Manual, fragile Enforced at UI + PR
Version history File-level only Field-level, per record
Git integration Manual export + commit Automatic via PR
PR review workflow None Native, GitHub-backed
Typed Unity access Custom importer required Auto-generated C# classes
Object relationships Manual cross-sheet refs First-class, validated
Programmer involvement Required for any change Setup once, then none
Broken build risk High - no warnings Deprecation warnings, not errors

Give your programmers their sprints back.

Theseus will be in early access soon. Get in touch, and we'll let you know when it's ready for your studio.

No commitment. No spam. Early access invites sent in studio order.