Teste a build que os jogadores vão receber. Um jogo que roda no editor ainda pode ser distribuído com recursos ausentes, arquivos de salvamento antigos que não funcionam mais ou uma descrição na loja que promete mais do que o pacote oferece. Atribua um identificador estável à versão candidata e prepare uma matriz de testes curta antes de começar os testes.
Busque três resultados úteis: um pacote testado, uma lista de problemas conhecidos e um registro para o suporte. Escolha as verificações de acordo com os sistemas do jogo e os dispositivos para os quais você anunciou suporte. Uma suíte de testes extensa que apenas repete detalhes da implementação pode deixar de verificar os problemas que os jogadores vão encontrar.
Congele uma versão candidata que você possa identificar
Registre a revisão do código-fonte, a versão da engine, a versão do conteúdo e as plataformas de destino previstas. Gere a build a partir de um ambiente de trabalho limpo ou documente o estado desse ambiente. Depois que os testes começarem, verifique os efeitos de qualquer mudança adicional; até uma alteração aparentemente sem relação pode afetar a versão candidata que você está preparando para distribuir.
Guarde o pacote e sua soma de verificação junto com as notas de lançamento. Peça aos testadores que informem a versão candidata, o dispositivo usado e a rota que seguiram. Uma build de desenvolvimento corrigida nunca deve ser confundida com o pacote que eles realmente testaram.
Cubra as rotas e os estados importantes
Monte uma matriz que cubra cada final, cada rota principal mutuamente exclusiva, cada limiar e cada desbloqueio obrigatório. Teste uma partida iniciada do zero, o salvamento e o carregamento antes e depois das escolhas, a reinicialização e os estados suportados ao atualizar, incluindo arquivos de salvamento antigos. Inclua as funções de pular, histórico e rollback sempre que o jogo as oferecer. Um final que funciona não justifica uma falha no desbloqueio de uma cena pelo caminho.
Verifique os eventos repetidos e a saída de estados incomuns. Uma cena pode parecer correta e, ainda assim, conceder uma recompensa duas vezes ou deixar uma flag de rota em estado inconsistente. Transforme os defeitos encontrados durante o desenvolvimento em verificações de regressão direcionadas, para que o mesmo bug não volte sem ser percebido na próxima versão candidata.
Verifique a interação prevista
Peça a um testador que navegue sem orientação. Verifique o ritmo dos diálogos, as informações transmitidas pelos menus, a legibilidade, a entrada pelo teclado ou por toque, o foco e as configurações. Observe os pontos em que o jogador não consegue encontrar a próxima ação. Sua explicação de um botão não virá junto com o jogo.
Teste os controles de áudio e todas as configurações de movimento ou reprodução que houver. Inclua sessões interrompidas e retornos do segundo plano quando isso for relevante. Verifique se as opções de acessibilidade funcionam de forma confiável ao longo das rotas e no sistema de salvamento; ver o botão de alternância correto na tela de configurações é só o começo.
Inspecione o empacotamento e as dependências externas
Instale ou extraia a distribuição fora do projeto-fonte e, depois, execute-a nesse local. Verifique se há arquivos ausentes, problemas de permissão dos arquivos ou de localização dos salvamentos e quais componentes de runtime são necessários. Confirme que o pacote não contém segredos de desenvolvimento nem dados de origem desnecessários.
Para um lançamento no navegador, sirva a exportação real no ambiente de hospedagem previsto. Verifique os caminhos dos recursos, o comportamento do armazenamento e os carregamentos lentos ou com falha. Para uma versão para download, teste o arquivo compactado de distribuição e as instruções de instalação no sistema operacional suportado. O pacote que os jogadores recebem também precisa fazer parte dos testes.
Alinhe a descrição pública à build
Descreva com precisão o conteúdo disponível, os idiomas suportados, os requisitos de sistema, as diferenças entre edições e as limitações conhecidas. Consulte as exigências atuais do canal de distribuição para publicação e declaração do uso de IA. Escolha prévias públicas que cumpram as regras de conteúdo do canal.
Não apresente um protótipo como um jogo concluído nem uma estimativa como um requisito verificado por medições. Use capturas de tela representativas e identifique as ilustrações editoriais quando usá-las. Obtenha, antes do lançamento, as aprovações referentes a pagamentos e conteúdo necessárias para a via de distribuição que você realmente vai usar.
Lance com uma opção de recuperação
Arquive a versão candidata, os arquivos-fonte editáveis, o registro de direitos e as evidências dos testes. Publique informações claras sobre a versão, um contato de suporte e os problemas conhecidos. Guarde uma versão anterior utilizável quando o acordo de distribuição permitir, para que a recuperação não dependa de reconstruir de memória uma build antiga.
Quando chegar um relato de problema, reproduza-o na versão afetada antes de fazer mudanças amplas no projeto. Corrija a causa, verifique os estados relacionados e atualize a matriz de regressão. Um bom suporte exige poder explicar qual build mudou, o que a correção cobre e o que você verificou.
Decisões-chave
- Atribua um ID estável à versão candidata empacotada e teste esse pacote.
- Cubra os limites das rotas, os desbloqueios obrigatórios e os arquivos de salvamento antigos suportados.
- Verifique os controles, a entrega e a descrição pública em conjunto.
- Arquive a versão lançada e adicione os defeitos corrigidos à matriz de regressão.
Arquivos do guia
Lista de verificação para o lançamento ↓Matriz de testes ↓Comunidades externas dedicadas a modelos e sites externos de publicação podem conter material explícito. Os links para as fontes abrem em uma nova aba; este guia não carrega suas prévias.
Fontes e leituras adicionais +
- Orientações do Ren'Py sobre lançamento e geração de builds ↗
- Documentação de exportação do Godot ↗
- Processo de lançamento do Steam ↗
Última verificação 5 de outubro de 2026.