Skip to content
zabloo

Overview

What zabloo/ui is, which page to read first depending on what you came for, and the three ideas the whole product rests on.

zabloo/ui is a UI platform for videogames. You write your game’s screens in React on your own machine, and a build step turns them into one small file — the envelope. Inside the game, a compact open-source SDK reads that file and draws it. Because the screens travel as data rather than as code, they can change without rebuilding the game: publish a new envelope and the build already on players’ machines draws the new screen.

The same shop screen — a title, a gold counter reading 1,250 and a Buy button — drawn inside four engines side by side: Unity and the browser today, Godot and Unreal next, shown dimmed. One exported file, named your-ui.zabloo, feeds all four.
Unity is a trademark of Unity Technologies. Godot logo by Andrea Calabró (CC BY 4.0). Engine names and marks identify the engines; they do not imply endorsement.

Which page do I read first?

Pick the line that sounds like you.

  • I want to try it. Start with getting started. It builds one shop screen from an empty folder, runs it in your browser, and finishes with the game loading it. About twenty minutes, and nothing installs into an engine until the last step.
  • I want to know what actually ships to players. Read how it works. It follows one screen from your editor to the player’s machine, in plain terms. The normative reference — every field the envelope can hold, and what an SDK must do with each one — is the format spec, kept in the repository.
  • I am looking for a specific component. Go to the catalog — one page per node type, with its props, its states and a preview you can run.
  • I want to see it before I read anything. The product page mounts the real renderer on a screen you can drive.
  • I want the code. The GitHub repository holds the core, the SDKs and the issue tracker.

Getting started, how it works and the catalog are sections of the sidebar, in that order; the format sits between them as a link out, because the spec is maintained in the repository rather than here. The docs are landing section by section: what you can read is listed there, and anything absent is not written yet, because there are no placeholder pages.

The mental model

Three ideas carry the whole product.

  1. What you write is not what ships. Your React code runs once, on your machine, at build time. What it produces is the envelope, and the envelope is all the game ever receives — it never runs React, and never runs any of your JavaScript.
  2. The UI fires names, not callbacks. A button does not carry a function; it declares a named action like "buy". The game listens for that name and never learns what drew the button.
  3. An old SDK is a normal case, not an error. A player can receive a screen newer than the SDK in their build. Anything that SDK does not recognize degrades by a written rule — never into a crash.

These docs and the repository

These pages are written for someone reading a website; the reference inside the repository is written for someone reading the code. Both are maintained by hand and updated at each release, so they can differ between one release and the next. When in doubt about the code as it is today, the repository is the source of truth.

The format is only there. It used to be here as well, in both languages, and keeping two normative copies in step was a promise that could only be broken quietly — so the spec now has one home, next to the code it governs.