Cómo funciona

Toda pantalla que un juego enseña con zabloo/ui hace el mismo viaje: la construyes en React, una exportación la convierte en un único fichero pequeño y, dentro del juego, un SDK pequeño la dibuja. Esta página recorre ese viaje una vez, de punta a punta, en términos llanos — sin reglas, sin tablas. El ejemplo es la tienda de gremio que construye la guía de primeros pasos: un contador de oro, una lista de artículos y un botón de compra en cada fila.

Construyes tu UI en la web

La pantalla de la tienda empieza como un componente de React en un proyecto web normal. La escribes con el editor, los componentes y el hot reload que ya usas para la web, y la miras en el navegador mientras la construyes. Lo que el navegador enseña es el renderer de verdad dibujando tu pantalla — no una maqueta de ella.

Nada de este paso pertenece a ningún motor. No hay ningún proyecto de Unity abierto, ningún plugin instalado. Si sabes construir una página web, sabes construir una pantalla de juego.

Las partes que el juego rellenará se declaran, no se escriben a mano. El contador de oro nombra el dato que quiere enseñar — un binding, el enlace entre un dato del juego y un nodo, hacia player.gold — y el botón de compra declara la named action "buy" que va a disparar: la acción con nombre que la UI dispara. Esas dos declaraciones son todo el contrato entre tu pantalla y el juego.

Exportas una vez

Cuando la pantalla está lista, la exportas. Lo que sale es un único fichero: el envelope — el sobre que el juego descarga —, un documento JSON versionado. Dentro, tus pantallas viajan como la IR: un árbol de nodos y los tokens a los que apuntan sus estilos — datos en vez de código. Tu React corrió una vez, en tu máquina, al exportar. Nada de él se envía, y el envelope es todo lo que el juego recibe.

¿Por qué un fichero y no código? Un fichero se puede inspeccionar, cachear, versionar y reemplazar. Y cualquier motor puede descargar un fichero, mientras que solo un navegador podría ejecutar tu JavaScript. El contrato completo — cada campo que el envelope puede llevar, y qué debe hacer un SDK con cada uno — vive en la spec del formato en GitHub.

Corre en cualquier motor

Dentro del juego, el SDK — una librería pequeña y open source — lee el envelope y lo dibuja en nativo, con la maquinaria de dibujo del propio motor. El mismo fichero, la misma pantalla, allí donde exista un SDK: en Unity, en el navegador, en el motor que venga después. Llevar tu UI a una plataforma nueva no es un port; es el mismo envelope, leído por otro SDK.

El juego habla con la pantalla en marcha en dos direcciones, ambas a través del SDK. Empuja datos hacia dentro — el oro que enseña el contador — y escucha las named actions que la pantalla dispara. Oye "buy"; nunca sabe qué dibujó el botón.

Y como la UI es un fichero que el juego descarga, el hot-update — actualizar la UI de un juego ya publicado — sale gratis. Publica un envelope nuevo y el build que ya está en las máquinas de los jugadores dibuja la pantalla nueva — sin recompilar, sin reinstalar nada. Un SDK viejo que se encuentra un envelope más nuevo degrada por una regla escrita, nunca en un crash.

Por qué es una buena idea

Aprendes a construir UIs una vez. Las mismas habilidades — React, componentes, tokens — producen la pantalla de la tienda en Unity hoy y un panel de ajustes en el navegador mañana. El siguiente motor al que apunte tu juego no pone a cero lo que sabes.

La UI deja de ser parte del build. Las pantallas se publican a su propio ritmo: corregir una etiqueta, reequilibrar un layout, montar un escaparate de temporada — a diario si quieres — mientras el binario del juego cambia tan poco como quiera.

La gente mejor en UI puede ser su dueña. Una diseñadora o un desarrollador web pueden construir, previsualizar y publicar pantallas de juego sin abrir el motor jamás. El equipo del juego se queda el motor; el equipo de UI se queda la UI.

Adónde ir ahora

Dos puertas para salir de esta página, según lo que quieras ahora.