Publicado em 26/08/2026 por Equipe JPC

Nosso catálogo vive em hosting estático. Sem Node no servidor. Sem PHP para servir o jogo. A página canônica é /play/slug/; o binário/jogo fica em /games/slug/.

Essa divisão não é estética. É SEO e publicidade: conteúdo nosso em /play/, shell do engine em /games/ (robots até bloqueia /games/ de propósito).

Paths relativos ou dor

Export de Construct adorava paths absolutos e SW registrando cache de outro domínio. Em estático, path relativo é lei. Abrir index.html local e no CDN tem que achar o mesmo data.json.

Checklist de publish que a gente cola no PR:

• abrir /games/slug/ direto — joga?
• abrir via /play/slug/ no iframe — joga?
• hard refresh depois de trocar asset — viu a versão nova?
• iOS Safari uma vez, pelo menos

Se só funciona no localhost com live server e mágica de CORS, não está pronto.

Service worker

Desligamos registro de SW nos shells Construct para esse site. Cache agressivo + deploy iterativo = jogador preso em build velha. Offline bonito no pitch; no suporte, ticket de “jogo bugado” que era cache.

Quer PWA? Faça no site, com escopo controlado — não deixe cada minigame instalar SW próprio brigando por cache.

Sem backend, sem desculpa

Placar online, login, season pass: fora do MVP estático. Salva local (localStorage) se precisar. Quando o jogo exigir servidor de verdade, aí é outro produto — e outra infra.

Deploy chato e previsível ganha de pipeline esperto que ninguém entende às 23h.