Your Characters Shouldn't Belong to a Platform

October 26, 2026 · Mitchel Pigsley

When I was building Sectors Without Number, I wanted it to become a system-agnostic tool. Getting there would have meant restructuring the whole platform, so I let the idea go.

I'm picking it back up. We're building Open Character Format (OCF), an open specification for how tabletop characters are defined, how they change, and how they interact with each other. It's pre-1.0 and ships fourteen packs, from the latest D&D 5e SRD to Mothership and Fate Core. The spec will keep evolving until 1.0.

Building a character standard for TTRPGs is an act of hubris. There's a trail of smoldering attempts to build a universal interchange format. Meanwhile Roll20 + Demiplane, Alchemy, and D&D Beyond have spent years and real money on proprietary formats. Games, packs, and add-ons are a lucrative market, which is why most big VTTs end up as closed systems built to keep you on the platform.

As a GM and a player, I've been pushed into those platforms with no way to take my characters with me. The walled gardens, and the characters left behind in them, are why I'm taking this on.

What it looks like

A game's rules live in packs, and a character file points to the packs it uses. Here's a Mothership character from the spec. The player brought a blaster the rulebook doesn't have, and it travels inside the character file:

specVersion: 0.2.0
id: example-mothership-reyes
packs:
  - { id: mothership-1e, version: 0.1.1 }
homebrew:
  defaultLanguage: en
  content:
    - id: gear.blaster
      type: weapon # resolves to mothership-1e:weapon
      tags: [ranged, energy]
      fields: { damage: 2d10, magazine: 12, range: long, woundType: fire }
  i18n:
    en:
      gear.blaster.name: Blaster
inventory:
  - { id: inv-1, item: homebrew:gear.blaster, equipped: true }

Notice what isn't there. There are no derived stats at all. A character file holds only the player's choices, and the engine computes everything else from the packs, so the sheet can't disagree with the rules. The blaster is a tiny pack of its own, named homebrew, built on Mothership's weapon type, so it gets the same state and shoot action as any weapon in the book. Export this file from one app, import it into another, and the custom gear comes along.

Why doesn't this exist?

Because it's very hard. Defining one format that fits every TTRPG is difficult on its own, and the hidden costs are worse. You need schemas for weapons, items, spells, and every other kind of pluggable data. You need upgrades between versions, multi-language support, and homebrew that extends the system without it seizing up. Multiply that across every app implementing the same standard and it becomes a nightmare.

OCF's approach is packs. Each game system, extension, or homebrew ruleset is defined in its own pack, and a TypeScript engine applies those packs to a character. That structure is half the answer. The other half is timing.

Why now?

The rules for every character already exist, written down in each game's rulebook. Turning those rules into structured, testable data is tedious, well-defined work, and that's where current AI tools are strong.

We use them to draft pack definitions, then to validate those packs by running thousands of characters through generation and upgrades. People check the work too. The packs power Realms of Shod, where humans review sheets for correctness and their feedback goes back into the packs. That's how a small team covers a dozen games, and it's why a standard that wasn't practical a few years ago is practical now.

I know AI is a sore subject in this hobby, so I'll be plain. OCF ships no AI-generated art or prose. Every name and any rules text in a pack comes straight from the game's own published material. The only text the engine adds is a short set of error messages. AI turns rules into data; it doesn't write the words.

What goes into the packs matters just as much. Every pack follows its game's license, and each one's license is listed on the site. Openly licensed games, like the 5E SRD (CC-BY-4.0), the ORC Second Edition rules, and the Cities and Worlds Without Number SRDs (CC0), can carry their rules text. The Sine Nomine games, like Stars Without Number, follow the terms of their free editions. Games that aren't openly licensed, like Mothership and MÖRK BORG, get mechanics-only packs, which hold the math and the names but no rules text, and claim no affiliation with or endorsement from the publisher.

Why us?

We already depend on it. PixelQueue runs Realms of Shod, and Realms of Shod's character sheets are built on OCF. We maintain the spec because our own product needs it, so we're in this for the long haul.

Sectors Without Number also taught me what it takes to keep an open-source TTRPG project alive.

Characters are a core part of the lock-in we've all lived with, and I didn't want Realms of Shod to take that road. Open source was the answer. The code, spec, schemas, and tests are Apache 2.0, and our own pack work is CC0, so anyone can build on OCF, commercially or not.

Right now the core team is entirely PixelQueue maintainers. Packs, fixes, and engine ports are open to anyone today. We discuss decisions about the spec itself openly on GitHub, and as other apps adopt OCF, I want their builders to have a real say in those decisions, not just a comment box.

What's next

The goal is OCF 1.0. We'll get there by adding systems whose mechanics differ from what we already cover, until new packs stop forcing changes to the engine and spec. When the rate of change slows enough that we can support it long term, we ship v1.

There are three ways to help right now.

Write a pack for a system you know well.
Implement OCF in your tool, or tell us what's stopping you.
Read the spec and tell us where it breaks.

I've already talked with builders hitting this problem on their own platforms. If that's you, or you just want your characters to outlive the apps they were made in, reach out.