Saltar al contenido
zabloo

El formato

Lo que llega al jugador es un único fichero JSON. Estas páginas dicen qué significa cada campo que lleva, y exactamente qué tiene que hacer un SDK con cada uno.

El formato es el fichero que tu juego descarga. Compilar una UI de zabloo produce un único documento JSON —el envelope— y todo lo que el juego dibuja sale de ahí: el árbol de nodos, los tokens a los que apuntan sus estilos, las imágenes que pintan y las dos conexiones que los unen al juego. Piensa en la pantalla de tienda de la guía de primeros pasos: las filas, el contador de oro y los botones de compra llegaron todos en ese único fichero.

Estas páginas dicen qué significa cada campo que lleva y qué tiene que hacer un SDK con cada uno.

Qué es el formato

La IR son datos, y solo datos. No puede bifurcar, ni calcular, ni llamar a nada. Eso es lo que hace seguro mandarla por hot-update a un juego que se publicó hace meses: un fichero nuevo puede cambiar lo que ve un jugador, pero no puede cambiar lo que la build es capaz de hacer.

De ahí salen tres propiedades, y recorren todas las páginas de esta sección:

  1. La geometría es del SDK. El layout es una pasada flex que el SDK corre en el dispositivo, no unos rectángulos horneados al exportar — así el mismo envelope se maqueta bien en un móvil, en un ultrapanorámico y en una consola.
  2. Todo lo dinámico es una de dos conexiones. Una named action va de la UI al juego; un binding va del juego a la UI y de vuelta. No hay un tercer mecanismo ni un lenguaje de expresiones.
  3. Ser más antiguo es un caso normal. El fichero llega a los jugadores por su lado, separado del SDK que lo lee, así que un SDK que se encuentra algo que no reconoce está en el camino esperado, no en el de error. Lo que hace entonces está escrito, y probado.
La versión de la IR es la v del envelope

Un solo número, y es mayor: un SDK implementa exactamente una versión y rechaza cualquier otra. No hay versión menor — lo que un SDK tiene que decidir es binario, y las reglas para todo lo que no reconozca ya están en el formato. Ver Versionado.

Las páginas

EnvelopeLa unidad que carga un SDK: versión, tokens, views, assets — y las props que lleva cada nodo.LayoutEl subconjunto de flex, las pasadas de medida y colocación, y por qué nada pinta fuera de su propio rect.Style y tokensQué aspecto tiene un nodo, resuelto nodo a nodo y sin cascada — más los estados y su orden normativo de mezcla.Input y focusHit-testing, qué puede recibir el foco, navegación direccional, teclado y mando. Nada de eso se escribe a mano.Bindings y actionsLas dos conexiones con el juego: los nombres que la UI dispara, y los paths que lee y escribe.MotionUna transición por nodo, sin lista de disparadores, cuatro curvas de easing definidas en forma cerrada.LoadingQué hace un SDK con un payload para el que no fue construido: tres niveles, reparación y los códigos de diagnóstico.VersionadoQué es aditivo, qué rompe, y por qué no hay versión menor.El canal del hostLa API de runtime con la que el juego maneja la UI — siete operaciones de ida, tres callbacks de vuelta.

Cómo se lee una página de aquí

Esta sección es un contrato, no un paseo. Está escrita para volver a ella, un campo cada vez, más que para leerla de principio a fin.

Todo lo marcado como normativo es ese contrato. Dos SDKs de la misma versión mayor tienen que producir el mismo frame ante los mismos bytes, así que esos pasajes están escritos para portarse literalmente, no para parafrasearse. Todo lo demás de la página es explicación alrededor de ellos.

Los tipos de nodo se nombran tal y como aparecen en la IR —Button, Repeat, ScrollView— y cada uno tiene su propia página en el catálogo, donde viven sus props, sus slots y su degradación. Esta sección describe lo que es cierto de todos los nodos; el catálogo describe lo que es cierto de uno.