Publicar o verdadeiro motor, não uma recriação
Deixar um visitante jogar o verdadeiro jogo — o mesmo motor que corre na aplicação — prova mais do que qualquer galeria de capturas de ecrã?
·
Os sites de estúdio mostram normalmente os produtos como imagens fixas. Uma imagem fixa não consegue demonstrar a sensação, e a sensação é a maior parte daquilo que um jogo é. A alternativa é normalmente uma recriação: uma versão simplificada para navegador que se aproxima do produto. Achamos que uma recriação é o pior dos dois mundos, porque é caro construí-la e não é a própria coisa.
O ZUPI acabou por ser o caso em que nenhum dos compromissos era necessário. A sua física e a sua geração de níveis vivem num módulo autónomo sem dependências de execução de terceiros, escrito contra um simples espaço de coordenadas de 390×600. Esse módulo é a mesma fonte de verdade que as compilações iOS e Android executam. Por isso a demonstração deste site não se aproxima do ZUPI — importa o motor do ZUPI, a sua geração de níveis, a sua curva de dificuldade e a regra dos três segundos de imobilidade, e desenha-os com um renderizador escrito para a web.
A experiência é saber se essa distinção vale a engenharia, e se se generaliza: quantos dos nossos produtos têm uma fronteira de motor genuína que pudéssemos expor assim, face a quantos precisariam de uma recriação que já decidimos não querer construir.
Respondido, 3 de outubro de 2026, e não da maneira que a pergunta esperava. O ZUPI deixou de ser esse caso: a aplicação na App Store passou a ser o ZUPI: Pulse Shield a 30 de setembro, outro jogo, por isso o módulo que esta demonstração importava é o do anterior. A incorporação nunca se afastou — o resumo criptográfico bateu certo até ao fim — e é esse o achado. Um resumo responde se uma cópia é fiel ao repositório de onde veio. Ninguém tinha perguntado se esse repositório continuava a ser o produto. O /try/zupi é agora uma recriação construída a partir da ficha pública da loja: exatamente aquilo que esta experiência se propôs evitar construir, e a resposta honesta quando a fonte de verdade desaparece.
O que aprendemos
Conclusões até agora.
- 01
Uma cópia incorporada precisa de ter a origem reidentificada, não apenas de um novo resumo criptográfico. O resumo responde se a cópia se afastou do repositório de onde veio. Não consegue responder se esse repositório continua a ser o produto, que é a pergunta que realmente falhou aqui.
- 02
O motor foi portado sem uma única alteração ao seu código. Uma fronteira limpa entre regras e representação, construída pelas próprias razões da aplicação, acabou por ser exatamente aquilo de que uma demonstração web precisa.
- 03
O determinismo importa mais do que o esperado: como os níveis derivam de uma semente por nível, a demonstração e a aplicação publicada produzem tabuleiros idênticos, pelo que aquilo que um visitante joga é genuinamente o nível 1 e não um parecido.
- 04
Não se generaliza de graça. Os produtos cuja lógica está entrelaçada com uma camada de interface nativa não podem ser expostos assim, o que torna «há uma fronteira de motor?» uma pergunta que vale a pena fazer durante uma construção e não depois dela.
Vê-lo a funcionar
Uma recriação, escrita para este site. Não é o código do ZUPI e não pretende sê-lo: o código do jogo publicado não está no repositório do estúdio, por isso isto foi construído a partir da ficha pública da App Store — o Pulse Core, a regra dos três segundos, os desvios que carregam um Pulse, seis por cada Pulse, as ameaças blindadas que só o Pulse parte, os divisores, os perseguidores e as bandas de guarda. Os números e os comportamentos vêm dessa ficha e das suas capturas; os níveis, a curva de dificuldade e a sensação são deste site, não do jogo. Até 3 de outubro de 2026 esta página executava o motor do jogo anterior e dizia que era o publicado.