How it works

Every screen a game shows with zabloo/ui makes the same trip: you build it in React, an export turns it into one small file, and inside the game a small SDK draws it. This page follows that trip once, end to end, in plain terms — no rules, no tables. The example is the guild shop the getting started guide builds: a gold counter, a list of items, a Buy button on each row.

You build your UI on the web

The shop screen starts as a React component in a normal web project. You write it with the editor, the components and the hot reload you already use for the web, and you watch it in the browser while you build it. What the browser shows is the real renderer drawing your screen — not a mockup of it.

Nothing in this step belongs to any engine. No Unity project is open, no plugin is installed. If you can build a web page, you can build a game screen.

The parts the game will fill in are declared rather than hardcoded. The gold counter names the data it wants to show — a binding to player.gold — and the Buy button declares the named action "buy" it will fire. Those two declarations are the whole contract between your screen and the game.

You export once

When the screen is ready, you export it. What comes out is a single file: the envelope, a versioned JSON document your game downloads. Inside it, your screens travel as the IR — a tree of nodes and the tokens their styles point at, data instead of code. Your React ran once, on your machine, at export time. None of it ships, and the envelope is all the game ever receives.

Why a file and not code? A file can be inspected, cached, versioned and replaced. And every engine can download a file, while only a browser could run your JavaScript. The full contract — every field the envelope can hold, and what an SDK must do with each one — lives in the format spec on GitHub.

It runs in any engine

Inside the game, the SDK — a small open-source library — reads the envelope and draws it natively, with the engine’s own drawing machinery. Same file, same screen, wherever an SDK exists: in Unity, in the browser, in whatever engine comes next. Moving your UI to a new platform is not a port; it is the same envelope, read by another SDK.

The game talks to the running screen in two directions, both through the SDK. It pushes data in — the gold count the counter shows — and it listens for the named actions the screen fires. It hears "buy"; it never learns what drew the button.

And because the UI is a file the game downloads, hot-update falls out for free. Publish a new envelope and the build already on players’ machines draws the new screen — no rebuild, nothing reinstalled. An older SDK meeting a newer envelope degrades by a written rule, never into a crash.

Why this is a good idea

You learn to build UIs once. The same skills — React, components, tokens — produce the shop screen in Unity today and a settings panel in the browser tomorrow. The next engine your game targets does not reset what you know.

The UI stops being part of the build. Screens ship on their own schedule: fix a label, rebalance a layout, run a seasonal storefront — daily if you want — while the game’s binary changes as rarely as it likes.

The people best at UI can own it. A designer or a web developer can build, preview and ship game screens without ever opening the engine. The game team keeps the engine; the UI team keeps the UI.

Where to go next

Two doors out of this page, depending on what you want now.