Checklist antes de lançar um minigame Cocos Creator: desempenho, tamanho do pacote, adaptação e revisão

No dia em que enviei a primeira revisão, fiquei olhando para o pop-up de “rejeitado na revisão” e travei por alguns segundos. O problema era tamanho do pacote: o pacote principal tinha 6,8 MB, enquanto o WeChat impõe um limite rígido de 4 MB. Passei três dias mexendo em tudo, de compressão de texturas a conversão de áudio e corte de módulos do motor, até conseguir reduzir o pacote para 3,2 MB e passar.

Aquela experiência me fez perceber que a checagem antes do lançamento segue um caminho bem claro. Não é sorte. É métrica concreta e método de teste definido. Depois disso, organizei as armadilhas em uma checklist e passei a marcar item por item antes de cada envio. Hoje essa lista já passou por mais de uma dúzia de iterações e cobre 15 checagens em quatro blocos: desempenho, tamanho do pacote, adaptação e revisão.

Este artigo compartilha a checklist que eu uso. Cada item traz um critério numérico, o tipo de ferramenta para testar e onde costuma estar a armadilha. Ao terminar, você consegue usar a lista para revisar seu jogo ponto por ponto e aumentar bastante a chance de aprovação na primeira tentativa.

1. Checagem de desempenho: não deixe travamentos estragarem a experiência

Problemas de desempenho estão entre os principais motivos de perda de jogadores. Talvez o jogo rode liso no seu celular, mas não esqueça: seu aparelho de teste provavelmente é novo, enquanto usuários reais podem estar em um celular de três anos atrás. A diferença entre um iOS de alto desempenho e um modelo fraco pode chegar a 3-4 vezes. Não é exagero.

1. Checagem de estabilidade de FPS

Critério de checagem: em aparelhos fortes (iPhone X ou superior), mire em 60 FPS; em aparelhos fracos (iPhone 6s/7/8), mire em 30 FPS. O pico mínimo não deve ficar abaixo de 80% da meta: ou seja, pelo menos 48 FPS em aparelhos fortes e 24 FPS em aparelhos fracos.

Método de teste: ative a exibição de FPS integrada do Cocos Creator em cc.macro:

// Exibe FPS durante o desenvolvimento
cc.macro.SHOW_FPS = true;

Você também pode usar Stats.js, que é mais visual. O “painel de desempenho” do WeChat DevTools também mostra a curva de FPS em tempo real.

Métricas quantificáveis:

• Aparelhos fortes estáveis em 55-60 FPS
• Aparelhos fracos estáveis em 28-32 FPS
• Variação de pico abaixo de 20%

Problemas comuns: DrawCalls demais, travamento ao trocar cenas complexas e muitos efeitos de partículas disparando ao mesmo tempo. Em um projeto anterior, a morte do Boss disparava 200 partículas e o aparelho fraco caía direto para 15 FPS. Depois troquei para 50 partículas com animação de easing, e o resultado visual ficou até melhor.

Dica de autoteste: pegue um iPhone 7 real e rode o jogo por 10 minutos. Se a linha de FPS ficar oscilando perto de 30, tudo bem. Se cair com frequência abaixo de 20, é hora de investigar.

2. Checagem de pico de memória

Critério de checagem: o iOS impõe limites rígidos de memória. Em aparelhos fracos (iPhone 6s/7/8), o teto fica em 1 GB; em aparelhos mais fortes (iPhone X/XR/11), em 1,4 GB. O pico não deve passar de 70% do limite do aparelho, ou seja, mantenha abaixo de 700 MB em aparelhos fracos e abaixo de 1 GB em aparelhos fortes.

Método de teste:

• WeChat DevTools: abra o painel “Debugger-Memory” para ver a curva de memória
• Depuração remota do Safari: conecte o aparelho real ao Mac e selecione o dispositivo no menu de desenvolvedor do Safari

// Imprime periodicamente o uso de memória
const memoryInfo = cc.sys.getMemoryInfo();
console.log('Memória atual: ' + memoryInfo.used + 'MB');

Métricas quantificáveis:

• Pico em aparelho fraco ≤700 MB
• Pico em aparelho forte ≤1000 MB
• Taxa de crash abaixo de 2% (em um projeto, caiu de 15% para 2% após otimização)

Problemas comuns: textura duplicada (o mesmo recurso carregado duas vezes), recursos que não são liberados a tempo e atlas grandes sem divisão. A documentação oficial do Cocos menciona que o ideal é manter atlas em até 1024x1024; atlas muito grandes estouram memória com facilidade em aparelhos fracos.

Dica de autoteste: em um aparelho fraco, entre e saia da mesma cena 20 vezes. Se a curva de memória continuar subindo sem voltar, há vazamento de recursos.

3. Checagem do número de DrawCalls

Critério de checagem: DrawCall afeta diretamente o desempenho de renderização. Quanto mais DrawCalls em um mesmo frame, maior a pressão sobre a GPU. A primeira tela, ou seja, a primeira imagem ao entrar no jogo, deve ficar abaixo de 100; durante o jogo, abaixo de 200.

Método de teste: no painel “Build and Publish” do Cocos Creator há uma opção de estatísticas de renderização. Depois de marcar, você consegue ver o número de DrawCalls em tempo de execução.

// Verifica o número atual de DrawCalls
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

Métricas quantificáveis:

• Primeira tela ≤100
• Durante o jogo ≤200
• Pico abaixo de 350 (pode afrouxar em cenas extremas)

Problemas comuns: imagens não combinadas em atlas, batching dinâmico desativado e uso excessivo de BMFont. Em um projeto, antes da otimização, o DrawCall chegava a 350. Depois empacotei imagens pequenas em um atlas grande e troquei BMFont por TTF, caindo direto para 120.

Técnicas de otimização:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

• Atlas estático: empacote com TexturePacker para reduzir imagens soltas
• Atlas dinâmico: o Cocos Creator ativa por padrão, mas a textura precisa ter menos de 2048
• BMFont: se der para usar TTF, use TTF; no BMFont, cada char vira um DrawCall

4. Checagem do tempo de carregamento da primeira tela

Critério de checagem: quando a primeira tela leva mais de 3 segundos para carregar, a taxa de abandono sobe 7%. Não é chute meu, é dado de mercado. Dados da plataforma de testes em nuvem do WeChat mostram que, em jogos com pacote de 3,5 MB, o tempo inicial fica entre 4500 e 9000 ms, faixa em que a perda de usuários aumenta claramente.

Método de teste:

• WeChat DevTools: “Details-Local Code” mostra o tamanho do pacote
• Plataforma de testes em nuvem do WeChat: simula rede em aparelho real e mede o tempo real da primeira tela

// Registra o tempo de carregamento da primeira tela
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('Tempo da primeira tela: ' + loadTime + 'ms');
});

Métricas quantificáveis:

• Renderização da primeira tela ≤3000 ms (ideal ≤1500 ms)
• Exibição da barra de progresso ≥80% (usuários tendem a esperar mais quando veem progresso)

Problemas comuns: recursos demais na primeira cena, cena inicial sem subpacote e carregamento completo da pasta resources. Na época, eu tinha colocado 3 personagens, 2 fundos e um monte de UI na primeira cena. O carregamento inicial foi para 5 segundos. Depois mudei para uma imagem de loading + carregamento por subpacote e baixei para 2 segundos.

Técnicas de otimização:

• Na primeira cena, deixe só uma imagem de fundo + barra de progresso
• Marque a cena inicial como subpacote
• Coloque recursos não essenciais em carregamento remoto

2. Checagem do pacote: o limite de 4 MB precisa ser vencido

O pacote principal de minigames do WeChat tem limite rígido de 4 MB, e o pacote total, incluindo subpacotes, não deve passar de 16 MB. Isso é linha vermelha: passou, rejeita direto, sem negociação. Foi exatamente a armadilha em que caí: pacote principal com 6,8 MB, rejeição e três dias de retrabalho até baixar para 3,2 MB.

5. Checagem do tamanho do pacote principal

Critério de checagem: pacote principal ≤3,8 MB. Por que deixar 200 KB de folga? Porque o build pode gerar arquivos dinâmicos, e a medição do WeChat às vezes tem pequenas diferenças. Deixe espaço para respirar.

Método de teste: depois do build, clique em “Details-Local Code” no WeChat DevTools para ver a estatística precisa do tamanho do pacote.

Métricas quantificáveis:

• Pacote principal ≤3,8 MB (linha segura)
• Pacote principal ≤4,0 MB (linha vermelha, precisa comprimir)

Problemas comuns:

• Recursos demais na pasta resources: tudo nessa pasta entra no pacote principal
• Módulos do motor sem corte: o Cocos empacota todos os módulos por padrão, mas talvez você só precise de alguns
• Dependências grandes demais: pacote npm importado sem checar tamanho

Dica de autoteste: antes do build, verifique a pasta resources e mova recursos não essenciais para outros diretórios. Depois, em “Project Settings-Module Settings” no Cocos, desmarque os módulos que você não usa.

// Exemplo de configuração de corte de módulos (project.json)
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // Não marque módulos desnecessários, por exemplo:
  // "physics" - sem necessidade de motor físico
  // "tween" - sem necessidade de sistema de easing
}

6. Checagem do tamanho total do pacote

Critério de checagem: o pacote total (pacote principal + subpacotes) não deve passar de 16 MB. Subpacotes podem ser carregados remotamente, mas a velocidade de download depende da rede; por isso o conteúdo central ainda deve ficar no pacote principal e no subpacote da primeira tela.

Método de teste: o log de saída do build mostra o tamanho de cada subpacote. A soma é o tamanho total.

Métricas quantificáveis:

• Pacote total ≤15 MB (linha segura)
• Pacote total ≤16 MB (linha vermelha)

Sugestão de estratégia de subpacotes:

• Pacote central (pacote principal + subpacote da primeira tela) <10 MB
• Pacote de funções (modos secundários) 20-50 MB
• Pacote de cenas (carregamento remoto) 30-100 MB

Problemas comuns: divisão ruim dos subpacotes, subpacote da primeira tela grande demais e usuário esperando download por tempo demais. Em um projeto, coloquei todos os modelos de personagens no subpacote da primeira tela, e o usuário precisava esperar 8 segundos para entrar no jogo.

7. Checagem da taxa de compressão dos recursos

Critério de checagem: texturas, áudio e fontes são os três grandes responsáveis pelo tamanho do pacote. Dados práticos: texturas representam 45%, áudio 25% e fontes 15%. Se essas três categorias forem bem comprimidas, o pacote pode cair pela metade.

Método de teste: compare o tamanho dos arquivos originais com o tamanho depois do build.

Métricas quantificáveis:

• PNG → JPG (imagens sem canal alfa): redução de 50-70%
• WAV → OGG: redução de 65-70%
• Extração de fonte (fontmin): redução de 80-90%

Ferramentas recomendadas:

• TinyPNG: compressão de PNG, versão web; basta arrastar o arquivo
• TexturePacker: empacotamento de atlas + compressão em um passo
• Audacity: conversão de áudio, especialmente WAV para OGG
• fontmin: extração de subconjunto de fonte, mantendo só os caracteres usados no jogo

Problemas comuns:

• Fundo em PNG: se não tem transparência, JPG resolve
• Áudio em WAV: fica várias vezes maior; troque para OGG
• Fonte sem extração: uma fonte completa pode ter 10 MB+; só os caracteres usados talvez fiquem em 100 KB

Dica de autoteste: compacte um PNG no TinyPNG e compare o antes/depois. Uma imagem de fundo de 500 KB pode cair para 150 KB.

8. Checagem da configuração de subpacotes

Critério de checagem: a estratégia de carregamento dos subpacotes precisa ser razoável e não pode prejudicar a experiência de abertura. A primeira cena deve estar marcada como subpacote, e recursos não essenciais não devem ficar no pacote principal.

Método de teste: verifique a ordem de carregamento dos subpacotes e as dependências da primeira cena.

Métricas quantificáveis:

• Primeira cena marcada como subpacote: sim
• Tempo de carregamento da primeira cena: ≤3000 ms
• Recursos não essenciais fora do pacote principal: verifique a pasta resources

Problemas comuns:

• Primeira cena referenciando recursos fora do pacote principal: obriga baixar o subpacote antes de entrar na cena
• Subpacotes sem divisão por lógica de negócio: o usuário entra em um modo e só então descobre que o subpacote não terminou de baixar
• Momento errado de carregamento: os subpacotes seguintes devem começar a baixar já na tela de loading

// Exemplo de carregamento de subpacote
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('Falha ao carregar subpacote', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

Dica de autoteste: teste o carregamento de subpacotes em uma rede 4G. Se o subpacote da primeira tela demorar mais de 5 segundos para baixar, repense a estratégia.

3. Checagem de adaptação: não deixe o jogo quebrar em um aparelho específico

Adaptação é o tipo de problema mais fácil de ignorar. Talvez tudo rode bem no seu aparelho de teste, mas depois do lançamento começam as reclamações: UI bloqueada, bordas pretas feias, erro de layout ao virar a tela. Compatibilidade de aparelhos é um problema sistêmico; não dá para testar só em um dispositivo.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

9. Checagem de adaptação de tela

Critério de checagem: resolução de design, estratégia de adaptação e tratamento de bordas pretas. Para jogos em retrato, a resolução recomendada é 720x1280 (9:16) ou 750x1334; em paisagem, inverta.

Método de teste: cubra pelo menos 3 proporções de tela em aparelhos reais:

• 16:9 (proporção tradicional, comum na maioria dos Androids)
• 18:9 (proporção moderna, modelos novos de Xiaomi e Huawei)
• 19.5:9 (série iPhone X, com notch)

Métricas quantificáveis:

• Resolução de design: 720x1280 ou 750x1334
• Estratégia de adaptação: em retrato, adaptar altura; em paisagem, adaptar largura
• Bordas pretas: nenhuma borda preta, ou bordas distribuídas de forma uniforme

Código-chave:

// Retrato: adaptar altura
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// Paisagem: adaptar largura
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// Obtém a área visível real
const visibleSize = cc.view.getVisibleSize();
console.log('Área visível: ' + visibleSize.width + 'x' + visibleSize.height);

Problemas comuns:

• Estratégia errada de adaptação: em retrato, escolher adaptar largura causa bordas pretas em cima e embaixo
• Widget mal usado: nós não acompanham automaticamente a borda da tela
• Resolução de design larga demais: parte da tela não aparece em alguns aparelhos

Dica de autoteste: use o componente Widget para fixar UIs críticas às bordas da tela. Por exemplo, o contador de moedas no canto superior direito deve ficar preso ao canto pelo Widget, sem sair do lugar em proporções diferentes.

10. Checagem de notch e tela em gota

Critério de checagem: tratamento da área segura, sem bloquear UIs críticas. Notch na série iPhone X, tela em gota e tela furada no Android ocupam área no topo da tela.

Método de teste: teste em aparelhos reais da série iPhone X/XR/11 e em Androids com notch, como Huawei Mate e modelos topo de linha da Xiaomi.

Métricas quantificáveis:

• UI crítica a ≥50 px do topo
• UI crítica a ≥50 px da base (área do Home virtual)
• Detecção de área segura: use a SafeArea API

Técnicas de adaptação:

// Obtém SafeArea no iOS
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// Adaptação dos nós
this.topNode.y = -topPadding;  // desloca para baixo
this.bottomNode.y = bottomPadding;  // desloca para cima

Outra opção é usar o componente Widget e configurar diretamente a distância até a borda com o valor dinâmico da área segura.

Problemas comuns:

• Título bloqueado pelo notch: o usuário não consegue ver o nome do jogo
• Botão inferior bloqueado pela área do Home virtual: áreas de toque se sobrepõem
• Android com tela furada não testado: a posição do furo muda de marca para marca

Dica de autoteste: no simulador do WeChat DevTools, selecione o modelo “iPhone X” e veja se a UI fica atrás do notch. Depois teste novamente em um Android real com notch.

11. Checagem de compatibilidade de aparelhos

Critério de checagem: cobrir aparelhos populares e garantir desempenho aceitável nos modelos fracos. Plataformas de teste em nuvem ajudam a testar em lote sem comprar uma pilha de celulares.

Método de teste:

• Plataforma de testes em nuvem do WeChat: gratuita, cobre aparelhos comuns para minigames do WeChat
• Testin Cloud Testing: pago, com cobertura mais ampla

Aparelhos recomendados para cobertura:

• iPhone 6s/7/8: base de baixo desempenho, para testar o limite inferior
• iPhone X/XR/11: médio/alto desempenho, para testar adaptação em notch
• Huawei/Xiaomi/OPPO/vivo populares: para testar compatibilidade Android

Métricas quantificáveis:

• FPS em aparelho fraco ≥30
• Memória em aparelho fraco ≤70% do limite do dispositivo
• Taxa de crash ≤2%
• Taxa de instalação bem-sucedida ≥99%

Problemas comuns:

• Testar só em iPhone: Android varia muito, e um Android fraco pode ser pior que um iPhone 6s
• Ignorar aparelhos antigos: em 2024 ainda havia usuários com iPhone 7
• Não testar suporte a WebGL: alguns aparelhos têm versão baixa de WebGL, e certos efeitos não aparecem

Dica de autoteste: foque em 3 classes de aparelho: seu dispositivo de desenvolvimento (alto desempenho), iPhone 7 (iOS fraco) e um Android intermediário de 2019. Essas três classes cobrem a maior parte dos casos.

12. Checagem de alternância entre retrato e paisagem

Critério de checagem: plano de adaptação retrato/paisagem e fluidez da troca. Alguns jogos permitem alternar orientação, como certos jogos de puzzle; nesses casos, a UI precisa se reorganizar automaticamente.

Método de teste: gire o aparelho real e teste cenas forçadas em retrato/paisagem.

Métricas quantificáveis:

• Tempo de troca ≤500 ms
• Reorganização da UI sem desalinhamento
• Cena renderizada normalmente após a troca

Problemas comuns:

• Posição dos nós bagunçada ao trocar: Widget não foi atualizado
• Tela preta após a troca: falha ao recarregar a cena
• Travamento na troca: cena grande demais para renderizar novamente com rapidez

// Escuta rotação da tela
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// Lógica de reorganização da UI
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // Layout em paisagem
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // Layout em retrato
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

Dica de autoteste: se o jogo só suporta retrato ou só paisagem, bloqueie a orientação nas configurações do projeto para evitar layout quebrado quando o usuário gira o celular.

4. Checagem de revisão: documentação, privacidade e conteúdo

A revisão é a parte que mais dá dor de cabeça ao desenvolvedor. Problemas técnicos você consegue testar; normas de revisão são mais difíceis de prever. As regras do WeChat são detalhadas, mas a execução prática ainda tem muitos detalhes. Desde 2026, o WeChat introduziu revisão auxiliada por IA, e atualizações de versão podem ser concluídas em 2-4 horas; a primeira revisão, porém, ainda costuma levar 1-2 dias úteis.

13. Checagem de documentação completa

Critério de checagem: registro de software, ICP e licença de jogo (obrigatória para compras internas). Esses três itens são exigências rígidas; faltar um pode causar rejeição direta.

Método de teste: confira item por item na lista oficial de qualificações e garanta que nome e titular sejam exatamente iguais.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Métricas quantificáveis:

• Registro de software: titular e nome exatamente iguais aos da conta (sem diferença de uma letra)
• ICP: aprovado (7-20 dias úteis)
• Licença de jogo: obrigatória para jogos com compra interna; pode ser dispensada em monetização só por anúncios

Problemas comuns:

• Um caractere a mais no nome do registro: por exemplo, o registro diz “BetterLink Match”, mas o jogo se chama “BetterLink Match Minigame”; rejeita direto
• Enviar antes de o ICP ser aprovado: o ciclo costuma levar 7-20 dias, e envio antecipado pode ser recusado
• Titular da licença diferente: a licença está na empresa A, mas a conta do jogo está na empresa B; não passa

Dica de autoteste: coloque juntos o certificado de registro de software, a captura do ICP e a licença, se houver. Confira nome e titular caractere por caractere. Um caractere a mais ou a menos já quebra, então aqui vale ser chato.

14. Checagem de política de privacidade e proteção de menores

Critério de checagem: entrada da política de privacidade, verificação de nome real e sistema contra vício. Esses três pontos são obrigatórios para proteção de menores, e a revisão de 2026 tende a olhar isso com atenção.

Método de teste: simule o login de um usuário menor de idade e confira se a lógica contra vício entra em ação.

Métricas quantificáveis:

• Política de privacidade: entrada visível na página inicial (pop-up ou botão)
• Sistema contra vício: menores ≤1 hora por dia, bloqueio entre 22:00 e 8:00
• Aviso de faixa etária: exibir aviso de jogo saudável na página inicial

Problemas comuns:

• Política de privacidade sem autorização por pop-up: o usuário entra direto no jogo sem ver o acordo
• Lógica contra vício ausente: não há entrada de verificação de nome real, ou a regra não é aplicada depois da verificação
• Aviso de jogo saudável ausente: a revisão pode exigir complemento

Dica de autoteste: use um número de documento de menor de idade (menos de 18 anos) para testar o fluxo de login. Veja se o limite contra vício é acionado e se, após 22:00, o login mostra bloqueio de jogo.

15. Checagem de conformidade de conteúdo

Critério de checagem: nome regular, anúncio em conformidade e conteúdo fora das linhas vermelhas. O nome precisa bater com a documentação, anúncios não podem bloquear funções centrais e o conteúdo não pode tocar em temas proibidos.

Método de teste: faça uma revisão interna pelas normas, item por item, olhando nome, anúncios e elementos de conteúdo.

Métricas quantificáveis:

• Nome: sem inglês/termos de marca e consistente com a documentação
• Proporção de anúncios: ≤50% e sem bloquear função central
• Conteúdo: sem violência, sexo, aposta ou elementos politicamente sensíveis

Problemas comuns:

• Nome com a palavra “software”: algo como “XX Software Minigame” pode ser rejeitado
• Anúncio bloqueando botão importante: o usuário tenta tocar em “começar jogo” e acerta o anúncio
• Incentivo a compartilhamento: “compartilhe com amigos para desbloquear fase” costuma ser rejeitado direto
• Nome em inglês: algo como “CocosGame” precisa virar um nome localizado aceito pela revisão

Motivos comuns de rejeição TOP 5:

1. Pacote acima do limite (pacote principal >4 MB)
2. Nome diferente do registro de software
3. Política de privacidade sem autorização por pop-up
4. Incentivo a compartilhamento/seguir conta
5. Anúncio bloqueando função central

Dica de autoteste: confira item por item contra esta lista TOP 5. Esses 5 motivos aparecem em 80% dos casos de rejeição; evitá-los já aumenta muito a chance de passar de primeira.

Tabela rápida de autoteste: checklist de 15 itens antes do lançamento

A checklist abaixo pode ser impressa e marcada item por item antes do envio para revisão:

Marque cada item depois de cumprir o critério e só envie para revisão quando os 15 estiverem ok. Não conte com sorte: qualquer item fora do padrão pode gerar rejeição e obrigar retrabalho.

Resumo

A checagem antes do lançamento não é um ritual opcional; ela afeta diretamente a taxa de aprovação. Problemas de desempenho fazem usuários irem embora, pacote acima do limite causa rejeição direta, adaptação ruim gera reclamações e inconformidade na revisão pode custar uma semana de correções.

O valor desta checklist está no concreto: cada item tem métrica, então você não precisa chutar; cada item tem método de teste, então você não fica no escuro; cada item mostra problemas comuns, para evitar armadilhas que outros já enfrentaram.

Minha sugestão é imprimir esta checklist e deixar ao lado do monitor. Antes de cada envio para revisão, marque item por item. Pode parecer trabalhoso, mas comparado a três dias de retrabalho depois de uma rejeição, esse investimento de tempo vale muito.

Por fim: ficar nervoso no primeiro lançamento é normal. Com esta checklist, você consegue revisar de forma sistemática e saber onde está pisando. Que seu minigame passe de primeira e entre no ar sem sustos.