Dicey Table

DiceyTable Developer Docs

DiceyTable is a browser-first tabletop simulator. A physics table runs in the browser, players connect to each other peer-to-peer, and games arrive as mods — GitHub-hosted packages of scenes, assets, scripts and rules that anyone can build and publish.

These docs are for the people building those mods: someone assembling a board and a deck in the in-app editor, someone scripting a card game's turn order, someone shipping the result so other players can join a room and play it.

Everything here is written against the product as it exists today — not as it was designed, and not as it may become. Where behavior is incomplete, asymmetric between the two script surfaces, or a known rough edge, the page says so plainly instead of smoothing it over. How to Read These Docs explains the conventions that make that claim checkable.

What "modding DiceyTable" actually involves#

A mod is a folder in a GitHub repository. At minimum it holds a manifest and a scene; at most it also holds models, textures, materials, decks, sound sets and a script. Nothing about a mod lives on a DiceyTable server — the repository is the source of truth, and publishing is a push.

That shape means five different jobs, and most projects need at least two of them:

  1. Author the scene — place and dress the things that sit on the table.
  2. Give it rules — script what happens when a die lands or a turn ends.
  3. Package it — the manifest, the file layout, and the security scanner that reads your script before anyone else can run it.
  4. Bring in card data somebody else owns — only if your game needs it; most do not.
  5. Look things up — the enum values, the action names, and the limits everything is validated against.

The five tracks below map onto those jobs one-for-one.

The five tracks#

1. Editor Guide#

Everything inside Edit Mode, the in-app authoring environment: the Hierarchy, the Inspector, the Asset Explorer, materials and textures, decks, parenting and welding, player zones and seats, and the path from a blank project to something worth publishing.

Start here if you are building the content of a game.

2. Scripting API#

DiceyTable has two separate script surfaces, and neither is layered on the other. A table script runs against a live world handle with delegate-style events and per-entity ObjectHandle mutators. A mod script is one file in the repository that talks to a smaller, capability-gated api object for the whole table. world does not exist in a mod's runtime, and api does not exist in a table script's runtime.

Read Choosing a surface before you pick one.

3. Mod Files & Publishing#

The shape of a mod on disk and the trip it takes to a live table: the manifest, the setup format, how assets and sidecars are laid out, exactly what the static security scanner rejects and why, and how a GitHub push turns a local draft into something joinable.

4. Plugins#

A plugin brings card data from an external provider onto a table — a separate publishable thing from a mod, with its own manifest, its own registry entry, and a deliberately narrow contract. Most games never need one: if your cards are a list you can write down, ship them in your own repository instead.

5. Concepts & Reference#

The cross-cutting tables that belong to no single surface: the three overlapping action vocabularies and how they differ, the enum value lists both script surfaces share, and an honest list of what does not work yet.

The badges, and where their values are defined#

Every scripting reference entry carries badges that tell you what a call actually does before you read its implementation. Each badge's values are defined in exactly one place, and this page links to it rather than repeating it — a second copy would drift, and a drifted badge legend is worse than none.

Badge The question it answers Where its values are defined
Authority Does this run on every peer, only on the host, or everywhere with host-replicated effects? The three authority values
Timing Does the call resolve immediately, or only after the next state broadcast? The two timing values
Availability Which script attachment points can reach this member? The four availability values
Capability Which manifest-declared capability gates this call for a mod? The capability values
Surface Which of the two script surfaces does this belong to? The two surface values

The badges exist because DiceyTable is host-authoritative: exactly one connected peer owns the table's real state. An API that looks synchronous can still only take effect once the host has agreed, and a reference page that did not say so would mislead by omission.

Examples are verified, not merely written#

Every runnable example on this site is checked mechanically before it can be published — table-script examples are compiled against the same declaration the in-editor autocomplete uses, and mod examples are additionally run through the same scanner that gates real publishing. See how that works, and what it does and does not guarantee.

Every page is dated#

Every page carries a Last verified date in its footer, beside a direct link to edit that exact file on GitHub. The date is when a human last confirmed the page against the running product, not when the file was last touched. Unstamped, undated pages are the single most-cited failure of tabletop-simulator documentation elsewhere; the convention is described in How to Read These Docs.

Where to start#