Quantos megas são demais para um mini-jogo?
Não há um número mágico, e quem lhe dá um está vendendo uma regra de bolso como lei. Mas o tamanho tem um custo mensurável, e para mini-jogos ele morde mais forte que para apps nativas —porque o jogador costuma buscar seu payload sob demanda, dentro do runtime de outro, num telefone de gama média sobre uma conexão instável. Isto é como pensar no orçamento em vez de adivinhar.
Q: Por que o tamanho do pacote pune mini-jogos mais que apps nativas?
Um app nativo é baixado uma vez, cacheado pelo SO e pré-aquecido pela plataforma. Um mini-jogo corre frequentemente dentro do WebView ou runtime de um app anfitrião que ele próprio tem um orçamento de memória e inicialização, e seu payload é buscado quando o jogador toca —não foi instalado dias antes. Assim seu cold start é download + parse + primeiro frame, e cada mega é tempo que o jogador encara um spinner. Num Android de gama média num mercado emergente, a diferença entre 3MB e 10MB iniciais é a diferença entre um jogador que espera e um que rebote antes do primeiro frame. Apps nativas amortizam esse custo; você o come por sessão.
Q: Qual é o orçamento real, e como medir?
Esqueça a discussão de megas e meça o que o jogador sente: tempo-real-para-interagir num perfil limitado, não seu laptop de dev com wifi. Uma meta útil é menos de ~4MB para o payload jogável inicial, transmitindo o resto. Depois teste como o jogador vive: 4G limitado, dispositivo de gama média, cache limpo —com Lighthouse, WebPageTest ou a ferramenta de trace da plataforma. A armadilha é otimizar o tamanho do download enquanto um único arquivo JS gigante bloqueia o thread principal no parse: um arquivo menor que pinta devagar é pior que um maior que pinta rápido. O tamanho é um proxy; a interatividade é a verdade.
Q: De onde vem realmente o peso?
Três suspeitos, e o terceiro é o que as equipes ignoram. Primeiro, overhead do motor e runtime —o framework que você escolheu tem um piso, e alguns são mais pesados. Segundo, inchaço de assets: áudio sem compressão, texturas 4K para um puzzle 2D, sprite sheets que ninguém cortou. Terceiro, e o assassino silencioso: SDKs de terceiros. Analítica, anúncios, auth, crash reporting —cada um soma silenciosamente 0.5–2MB e uma ida e volta de rede na inicialização. As equipes se obcecam com seus 200KB de código e ignoram seis SDKs puxando 4MB. Audite a árvore de dependências e etiquete cada SDK como estrutural ou decorativo; a maioria é decorativo e todos cobram imposto no primeiro frame.
Q: Como mantê-lo pequeno sem reescrever o jogo?
Quase nunca precisa de reescrita. Transmita assets e carregue preguiçosamente: não envie as texturas do nível 50 no dia 1, busque-as quando o jogador chegar. Comprima áudio para um codec moderno, faça atlas de texturas e inicialize os SDKs depois do primeiro frame em vez de antes. Escolha um runtime ou motor com pegada pequena desde o início —esta é uma decisão que você toma uma vez e carrega por todo o projeto. O tradeoff a nomear em voz alta: o code-splitting agressivo reduz o tamanho inicial mas adiciona um pouco de latência em carregamentos posteriores, então você troca primeiro-frame-imediato por tamanho-total. Meça ambos, não assuma que a divisão ajudou.
| Alavanca | Impacto no cold start | Esforço | Risco se ignorado |
|---|---|---|---|
| Payload inicial < 4MB | alto | médio | rebote antes do primeiro frame |
| Streaming / lazy load | alto | médio | envia peso que não precisa já |
| Auditoria SDK + init pós-frame | muito alto | baixo | imposto silencioso 4MB |
| Escolha de motor / runtime | alto | alto (cedo) | piso travado |
