What TaleShard is

TaleShard is a browser application for writing branching narrative. You draw the story as a graph, you model the world it is about, you write the rules that decide which way it goes — and then the whole thing leaves as data that a game reads.

Nothing is installed. There is no plugin involved in writing; the Unity plugin is a separate product that reads the result, and it is documented over here.

Four things, and everything else is one of them

Boards

A board is a canvas of nodes joined by edges. A project holds as many as you want, arranged in a tree — a board can sit inside another board, or inside a folder — and a board can hand the story to another board through a Board node or a Jump node.

A board’s own record is small: a name, an optional description and colour, its position in the tree, and optionally the node the story starts at. The nodes and edges live separately, keyed by the board, which is what lets one canvas be re-pointed at a different board without tearing the editor down.

Node types

A node type decides what a node is: which fields it has, what it looks like, and how it may connect. TaleShard does not ship a fixed list of narrative primitives that every project must pretend to fit. A new project starts from a standard pack — Text, Board, Dialogue, Entry, Branch, Jump, Element, Code — and every one of those is ordinary project data you can change, extend or replace.

That is the single most consequential decision in the product, and it is why there is a whole node builder rather than a settings page.

The world

Characters, items, locations, factions — the things the story is about. You declare an entity definition (the shape: which fields, of which types) and then create entity items against it (the instances). Traits let two definitions share a block of fields without either one owning it, and a definition can inherit from another.

Prose that is not a node lives here too, as documents; a document whose kind is a spreadsheet is the same object with a grid instead of a page.

The rules

What makes a second playthrough different from the first. Variables hold state; contexts group them under a dotted name; enums and bitmasks give a variable a fixed set of values; tags label things and gate them. Exits carry conditions, nodes carry scripts, and commands are how the story tells the game to do something the story cannot do itself — play a cutscene, start a minigame, move a camera.

All of that is written in one small expression language, and the same language runs in the browser player and in the game.

It leaves as data

A finished project is compiled into an engine payload — boards, nodes, exits, node types, entities, entity definitions, variables, contexts, enums and a tag table — in a form with no TaleShard concepts left in it that a game would have to learn. Expressions travel as parsed trees, not as strings for the game to re-parse.

The consequence worth holding on to: your game never learns your node-type table. It reads resolved fields and follows resolved exits. Add a node type on Tuesday and the game does not need a new build to understand it.

What this manual is, and is not

These pages document the editor. They are written from the app’s own source, and where a limit is stated it is a limit something actually enforces — a number that no guard checks is not published here.

Two things you will not find:

• Prices, plans and allowances. They live on the pricing page, which is the one place they are decided. Docs link out to it; it never grows a how-to.
• The game-side API. Reading a step, implementing a command, generating C# — all of that is the plugin’s, at the Unity documentation.

Next: your first board, which is short and worth doing rather than reading.