Ejecutar el motor real del juego en el navegador

Actualización, 3 de octubre de 2026: la demo que esto describe ya no existe, y la razón vale más que el artículo. Todo lo de abajo es un relato verdadero de un trabajo de ingeniería real: el módulo de reglas de ZUPI sí se incorporó sin modificar, su hash sí se comprobaba en cada compilación, y el tablero sí era el nivel 1 tal como lo genera la app. Luego la app cambió. ZUPI: Pulse Shield salió el 30 de septiembre de 2026 y es otro juego, así que el módulo que aquí se celebra pasó a ser el del juego anterior. La comprobación que guardaba la afirmación solo podía demostrar que la copia coincidía con el repositorio, nunca que el repositorio siguiera siendo lo que la gente descarga. /try/zupi es ahora una recreación honesta. El argumento de abajo sigue valiendo para Glow Garden y Veyra; lo que le faltaba es que a una copia incorporada hay que volver a identificarle el origen, no solo volver a calcularle el hash.

El sitio de cualquier estudio de producto se enfrenta al mismo problema: una captura no puede mostrarte cómo se siente algo, y la sensación es la mayor parte de lo que es un juego. La respuesta habitual es una recreación: una versión simplificada para navegador que se aproxima al producto lo bastante para ser indicativa. Creemos que es la peor opción disponible. Cuesta ingeniería real, se desvía de la app en el momento en que cualquiera de las dos cambia, y lo que juega un visitante es, por construcción, otra cosa.

ZUPI nos permitió evitar la elección por completo, por razones que no tenían nada que ver con el marketing.

La frontera ya estaba ahí

Las reglas de ZUPI viven en un único módulo autocontenido sin dependencias de ejecución de terceros. Es dueño de la física, el tratamiento de colisiones, la generación de niveles, la curva de dificultad, la puntuación y la regla de los tres segundos de quietud. No sabe qué es un canvas. Expone una clase que construyes con un número de nivel y avanzas con un delta de tiempo, y te dice dónde está todo.

Esa frontera no se dibujó para la web. Se dibujó para que el juego pudiera probarse sin un renderizador y para que las mismas reglas pudieran sostener una compilación de Android y una de iOS sin escribirse dos veces. Simplemente ocurre que un módulo que puede ser conducido por un arnés de pruebas también puede ser conducido por un navegador.

Qué hicimos en realidad

• Incorporamos el módulo de reglas sin modificar, con su procedencia registrada al lado. No es un port ni una reescritura — es el mismo archivo.
• Escribimos un renderizador para la web en el lenguaje visual propio de NOVEMADE, en lugar de copiar la interfaz de la app.
• Lo conducimos desde un bucle de paso de tiempo fijo, para que la simulación avance de forma idéntica sea cual sea la frecuencia de refresco de la pantalla.
• Dejamos la generación de niveles completamente en paz, así que el tablero es el nivel 1 tal como lo genera la app.

El último punto es el que importa. Los niveles derivan de una semilla determinista por nivel, así que no es un tablero que se parece al nivel 1 — es el nivel 1. Superarlo aquí significa lo mismo que significa en la app.

La honestidad como problema de interfaz

Porque «el motor real» y «una recreación» son afirmaciones genuinamente distintas, nuestro catálogo de demos lleva una declaración de fidelidad en cada entrada, y es un campo obligatorio del modelo de contenido y no un extra deseable. Las demos que aún no existen dicen qué serán cuando existan — incluido que la de Didi tendrá que ser una recreación, porque su lógica está atada a su capa de interfaz nativa y no hay frontera de motor que exponer.

Lo que merece la pena llevarse

La lección reutilizable no es sobre demos web. Es que «¿podría alguien más conducir esto sin nuestra interfaz?» es una pregunta que merece la pena hacerse mientras se construye un producto, no después. Cuando la respuesta es sí, obtienes testabilidad, portabilidad y — resulta — una demo que no tuviste que construir dos veces.