Executar o verdadeiro motor do jogo no navegador

Atualização, 3 de outubro de 2026: a demonstração que isto descreve já não existe, e a razão vale mais do que o artigo. Tudo o que se segue é um relato verdadeiro de um trabalho de engenharia real — o módulo de regras do ZUPI foi mesmo incorporado sem alterações, o seu resumo criptográfico era mesmo verificado em cada compilação, e o tabuleiro era mesmo o nível 1 tal como a aplicação o gera. Depois a aplicação mudou. O ZUPI: Pulse Shield saiu a 30 de setembro de 2026 e é outro jogo, por isso o módulo aqui celebrado passou a ser o do jogo anterior. A verificação que guardava a afirmação só podia provar que a cópia correspondia ao repositório, nunca que o repositório continuava a ser aquilo que as pessoas descarregam. O /try/zupi é agora uma recriação honesta. O argumento abaixo continua válido para o Glow Garden e o Veyra; o que lhe faltava é que uma cópia incorporada precisa de ter a origem reidentificada, e não apenas de novo resumo.

O site de qualquer estúdio de produto enfrenta o mesmo problema: uma captura de ecrã não consegue mostrar-lhe como algo se sente, e a sensação é a maior parte daquilo que um jogo é. A resposta habitual é uma recriação — uma versão simplificada para navegador que se aproxima do produto o suficiente para ser indicativa. Achamos que é a pior opção disponível. Custa engenharia real, afasta-se da aplicação no momento em que qualquer das duas muda, e aquilo que um visitante joga não é, por construção, a própria coisa.

O ZUPI permitiu-nos evitar a escolha por completo, por razões que nada tinham a ver com marketing.

A fronteira já ali estava

As regras do ZUPI vivem num único módulo autónomo, sem dependências de execução de terceiros. É dono da física, do tratamento de colisões, da geração de níveis, da curva de dificuldade, da pontuação e da regra dos três segundos de imobilidade. Não sabe o que é um canvas. Expõe uma classe que se constrói com um número de nível e se avança com um delta de tempo, e diz-nos onde está tudo.

Essa fronteira não foi traçada para a web. Foi traçada para que o jogo pudesse ser testado sem um renderizador e para que as mesmas regras pudessem suportar uma compilação Android e uma iOS sem serem escritas duas vezes. Acontece simplesmente que um módulo que pode ser conduzido por um arnês de testes também pode ser conduzido por um navegador.

O que fizemos na verdade

• Incorporámos o módulo de regras sem alterações, com a sua proveniência registada ao lado. Não é uma portagem nem uma reescrita — é o mesmo ficheiro.
• Escrevemos um renderizador para a web na linguagem visual própria da NOVEMADE, em vez de copiar a interface da aplicação.
• Conduzimo-lo a partir de um ciclo de passo de tempo fixo, para que a simulação avance de forma idêntica independentemente da taxa de atualização do ecrã.
• Deixámos a geração de níveis completamente em paz, pelo que o tabuleiro é o nível 1 tal como a aplicação o gera.

O último ponto é o que importa. Os níveis derivam de uma semente determinista por nível, portanto este não é um tabuleiro que se parece com o nível 1 — é o nível 1. Vencê-lo aqui significa o mesmo que significa na aplicação.

A honestidade como problema de interface

Porque «o verdadeiro motor» e «uma recriação» são afirmações genuinamente diferentes, o nosso catálogo de demonstrações traz uma declaração de fidelidade em cada entrada, e é um campo obrigatório do modelo de conteúdo e não um extra desejável. As demonstrações que ainda não existem dizem o que serão quando existirem — incluindo que a do Didi terá de ser uma recriação, porque a sua lógica está presa à camada de interface nativa e não há fronteira de motor para expor.

O que vale a pena levar daqui

A lição reutilizável não é sobre demonstrações web. É que «poderia outra pessoa conduzir isto sem a nossa interface?» é uma pergunta que vale a pena fazer enquanto um produto está a ser construído, e não depois. Quando a resposta é sim, obtém-se testabilidade, portabilidade e — como se vê — uma demonstração que não foi preciso construir duas vezes.