Skip to content
zabloo

The format

What reaches the player is a single JSON file. These pages say what every field in it means, and exactly what an SDK must do with each one.

The format is the file your game downloads. Building a zabloo UI produces one JSON document — the envelope — and everything the game draws comes out of it: the tree of nodes, the tokens their styles point at, the images they paint, and the two hooks that connect them to the game. Picture the shop screen from the getting started guide: the rows, the gold counter and the Buy buttons all arrived as that single file.

These pages say what every field in it means and what an SDK must do with each one.

What the format is

The IR is data, and only data. It cannot branch, compute or call anything. That is what makes it safe to hot-update into a game that shipped months ago: a new file can change what a player sees, but it cannot change what the build is able to do.

Three properties follow from that, and they run through every page here:

  1. The SDK owns the geometry. Layout is a flex pass the SDK runs on the device, not rectangles baked at export time — so the same envelope lays itself out correctly on a phone, an ultrawide and a console.
  2. Everything dynamic is one of two hooks. A named action goes UI → game; a binding goes game ↔ UI. There is no third mechanism and no expression language.
  3. Older is a normal case. The file reaches players separately from the SDK that reads it, so an SDK meeting something it does not recognize is the expected path, not the error path. What it does then is written down, and tested.
The IR version is the envelope's v

One number, and it is a major: an SDK implements exactly one and refuses anything else. There is no minor version — what an SDK needs to decide is binary, and the rules for everything it does not recognize are already in the format. See Versioning.

The pages

The envelopeThe unit an SDK loads: version, tokens, views, assets — and the props every node carries.LayoutThe flex subset, the measure and arrange passes, and why nothing paints outside its own rect.Style & tokensHow a node looks, resolved per node with no cascade — plus states and their normative merge order.Input & focusHit-testing, focusability, directional navigation, the keyboard and the gamepad. None of it authored.Bindings & actionsThe two hooks into the game: names the UI fires, and paths it reads and writes.MotionOne transition per node, no trigger list, four easing curves defined in closed form.LoadingWhat an SDK does with a payload it was not built for: three levels, repair, and the diagnostic codes.VersioningWhat is additive, what breaks, and why there is no minor version.The host channelThe runtime API the game drives the UI through — seven operations in, three callbacks back.

How to read a page here

This section is a contract, not a tour. It is written to be returned to, one field at a time, rather than read end to end.

Anything marked normative is that contract. Two SDKs on the same major must produce the same frame in front of the same bytes, so those passages are written to be ported literally rather than paraphrased. Everything else on the page is explanation around them.

Node types are named as they appear in the IR — Button, Repeat, ScrollView — and each one has its own page in the catalog, where its props, its slots and its degradation live. This section describes what is true of every node; the catalog describes what is true of one.