Publicar el motor real, no una recreación
¿Dejar que un visitante juegue al juego real — el mismo motor que se ejecuta en la app — demuestra más que cualquier galería de capturas?
·
Los sitios de estudio suelen mostrar los productos como imágenes fijas. Una imagen fija no puede demostrar la sensación, y la sensación es la mayor parte de lo que es un juego. La alternativa normalmente es una recreación: una versión simplificada para navegador que se aproxima al producto. Creemos que una recreación es lo peor de los dos mundos, porque es cara de construir y no es la cosa en sí.
ZUPI resultó ser el caso en el que ninguno de los dos compromisos era necesario. Su física y su generación de niveles viven en un módulo autocontenido sin dependencias de ejecución de terceros, escrito contra un espacio de coordenadas llano de 390×600. Ese módulo es la misma fuente de verdad que ejecutan las compilaciones de iOS y Android. Así que la demo de este sitio no se aproxima a ZUPI — importa el motor de ZUPI, su generación de niveles, su curva de dificultad y la regla de los tres segundos de quietud, y los dibuja con un renderizador escrito para la web.
El experimento es si esa distinción merece la ingeniería, y si se generaliza: cuántos de nuestros productos tienen una frontera de motor genuina que podríamos exponer así, frente a cuántos necesitarían una recreación que ya hemos decidido que no queremos construir.
Respondido, 3 de octubre de 2026, y no como esperaba la pregunta. ZUPI dejó de ser ese caso: la app del App Store pasó a ser ZUPI: Pulse Shield el 30 de septiembre, otro juego, así que el módulo que esta demo importaba es el del anterior. La incorporación nunca se desvió — el hash coincidió hasta el final — y ese es el hallazgo. Un hash responde si una copia es fiel al repositorio del que salió. Nadie había preguntado si ese repositorio seguía siendo el producto. /try/zupi es ahora una recreación construida a partir de la ficha pública de la tienda: justo lo que este experimento se propuso evitar construir, y la respuesta honesta cuando la fuente de verdad ha desaparecido.
Qué aprendimos
Hallazgos hasta ahora.
- 01
A una copia incorporada hay que volver a identificarle el origen, no solo volver a calcularle el hash. El hash responde si la copia se desvió del repositorio del que salió. No puede responder si ese repositorio sigue siendo el producto, que es la pregunta que falló de verdad aquí.
- 02
El motor se portó sin un solo cambio en su código. Una frontera limpia entre reglas y representación, construida por las propias razones de la app, resultó ser exactamente lo que necesita una demo web.
- 03
El determinismo importa más de lo esperado: como los niveles derivan de una semilla por nivel, la demo y la app publicada producen tableros idénticos, así que lo que juega un visitante es genuinamente el nivel 1 y no un parecido.
- 04
No se generaliza gratis. Los productos cuya lógica está entrelazada con una capa de interfaz nativa no pueden exponerse así, lo que convierte «¿hay una frontera de motor?» en una pregunta que merece hacerse durante una construcción y no después.
Verlo funcionando
Una recreación, escrita para este sitio. No es el código de ZUPI y no pretende serlo: el código fuente del juego publicado no está en el repositorio del estudio, así que esto se construyó a partir de la ficha pública del App Store: el Pulse Core, la regla de los tres segundos, las desviaciones que cargan un Pulse, seis por cada Pulse, las amenazas acorazadas que solo el Pulse rompe, los divisores, los rastreadores y las bandas de guardia. Los números y los comportamientos vienen de esa ficha y de sus capturas; los niveles, la curva de dificultad y la sensación son de este sitio, no del juego. Hasta el 3 de octubre de 2026 esta página ejecutaba el motor del juego anterior y decía que era el publicado.