Vista general

Qué es zabloo/ui, qué página leer primero según a qué hayas venido, y las tres ideas sobre las que se sostiene todo el producto.

zabloo/ui es una plataforma de UI para videojuegos. Escribes las pantallas de tu juego en React, en tu propia máquina, y un paso de compilación las convierte en un único fichero pequeño: el envelope. Dentro del juego, un SDK compacto y de código abierto lee ese fichero y lo dibuja. Como las pantallas viajan como datos y no como código, pueden cambiar sin recompilar el juego: publicas un envelope nuevo y la build que ya está en las máquinas de los jugadores dibuja la pantalla nueva.

La misma pantalla de tienda —un título, un contador de oro que marca 1.250 y un botón Buy— dibujada dentro de cuatro motores, uno al lado de otro: Unity y el navegador hoy; Godot y Unreal después, atenuados. Un único archivo exportado, llamado your-ui.zabloo, alimenta los cuatro. — Unity es una marca de Unity Technologies. Logo de Godot por Andrea Calabró (CC BY 4.0). Los nombres y las marcas identifican a cada motor; no implican ningún respaldo.

¿Qué página leo primero?

Elige la línea que suene a ti.

Quiero probarlo. Empieza por primeros pasos. Construye una pantalla de tienda desde una carpeta vacía, la ejecuta en tu navegador y termina con el juego cargándola. Unos veinte minutos, y no se instala nada en ningún motor hasta el último paso.
Quiero saber qué llega de verdad a los jugadores. Lee cómo funciona. Sigue una pantalla desde tu editor hasta la máquina del jugador, en términos llanos. La referencia normativa —todos los campos que puede llevar el envelope, y qué tiene que hacer un SDK con cada uno— es la spec del formato, que se mantiene en el repositorio.
Busco un componente concreto. Ve al catálogo — una página por tipo de nodo, con sus props, sus estados y un preview que puedes ejecutar.
Quiero verlo antes de leer nada. La página de producto monta el renderer de verdad sobre una pantalla que puedes manejar.
Quiero el código. El repositorio de GitHub tiene el core, los SDKs y el gestor de issues.

Primeros pasos, cómo funciona y el catálogo son secciones de la barra lateral, en ese orden; el formato va entre ellas como un enlace hacia fuera, porque la spec se mantiene en el repositorio y no aquí. Las docs van aterrizando sección a sección: lo que se puede leer está listado ahí, y lo que no aparece es que aún no está escrito, porque aquí no hay páginas de relleno.

El modelo mental

Tres ideas sostienen todo el producto.

Lo que escribes no es lo que se publica. Tu código React se ejecuta una vez, en tu máquina, al compilar. Lo que produce es el envelope, y el envelope es todo lo que el juego llega a recibir: nunca ejecuta React, y nunca ejecuta nada de tu JavaScript.
La UI dispara nombres, no callbacks. Un botón no lleva una función: declara una named action como "buy". El juego escucha ese nombre y nunca llega a saber qué dibujó el botón.
Un SDK antiguo es un caso normal, no un error. A un jugador le puede llegar una pantalla más nueva que el SDK de su build. Todo lo que ese SDK no reconozca degrada siguiendo una regla escrita — nunca en un cierre inesperado.

Estas docs y el repositorio

Estas páginas están escritas para quien lee una web; la referencia que vive dentro del repositorio, para quien lee el código. Las dos se mantienen a mano y se actualizan en cada release, así que pueden diferir de una release a la siguiente. Ante la duda sobre cómo está el código hoy, el repositorio es la fuente de verdad.

El formato está solo allí. Estuvo también aquí, en los dos idiomas, y mantener dos copias normativas al día era una promesa que solo se podía romper en silencio — así que la spec tiene una única casa, junto al código que gobierna.