Uma visual novel pode ser exigente mesmo quando há pouco movimento na tela. Retratos grandes dos personagens, cenários, clipes e áudio contribuem para o tempo de download, o espaço de armazenamento, a decodificação e o uso de memória. Cenas em tempo real acrescentam trabalho de animação, iluminação e renderização. Uma cena estática também precisa de um orçamento.
Comece pelo visual aprovado e por um orçamento para os dispositivos-alvo. A emulação no navegador pode revelar problemas de layout, mas o desempenho em dispositivos físicos precisa ser testado em dispositivos físicos. Para cada afirmação sobre desempenho, registre o dispositivo, o navegador ou ambiente de execução, a build e as condições de teste para que o resultado possa ser reproduzido.
Escolher cenas e dispositivos representativos
Escolha uma cena tranquila, uma com vários recursos grandes, uma sequência com transições frequentes e todos os trechos com vídeo ou em tempo real. Especifique o dispositivo com as características mínimas suportadas e um dispositivo comum. Inclua a menor tela na qual os jogadores precisam conseguir ler o texto e fazer escolhas.
Meça a inicialização a frio, uma nova inicialização, as transições entre cenas e a interação prolongada. Separe o primeiro download dos recursos das execuções que usam o cache. Registre texturas ausentes, decodificação lenta, atraso nos comandos e recarregamentos como falhas por si só; uma taxa de quadros média pode esconder esses problemas.
Medir o orçamento dos recursos distribuídos
Para cada recurso distribuído, registre as dimensões de exportação, o tamanho do arquivo e quantos recursos podem estar na memória ao mesmo tempo. O tamanho do download não informa quanta memória uma imagem decodificada vai ocupar: a compressão pode deixar o arquivo muito menor. Mantenha os arquivos-fonte editáveis separados dos arquivos exportados entregues aos jogadores.
Ajuste o tamanho da exportação à forma como o recurso realmente aparece na tela. Compare os formatos candidatos no ambiente de execução de destino antes de converter toda a biblioteca e confira bordas transparentes, gradientes, texto e rostos em relação à arte aprovada. Um arquivo menor é pouco consolo se a compressão estragar o close do personagem.
Tratar o vídeo como uma carga separada
Reserve uma entrada própria para o vídeo no orçamento. Registre resolução, duração, codificação, taxa de bits, áudio e se cada clipe é pré-carregado. No dispositivo-alvo, teste o início da reprodução, o loop, a pausa e a alternativa de contingência. A reprodução em um editor de desktop não comprova como o clipe se comporta em um navegador ou em uma build móvel empacotada.
Carregue as variações de que a cena precisa em vez de carregar todas de uma vez. Quando o design permitir, ofereça uma imagem de prévia ou uma imagem estática como alternativa de contingência e dê ao jogador controles de reprodução. Meça a transição completa, incluindo a decodificação e qualquer elemento de arte presente ao mesmo tempo; o tamanho do arquivo do clipe exportado cobre apenas parte da carga.
Manter a interação responsiva
Deixe o texto legível e os controles grandes o suficiente para serem usados. Teste a navegação rápida, o redimensionamento ou as mudanças de orientação, a alteração de configurações durante a reprodução e o retorno do segundo plano. Enquanto uma operação estiver pendente, verifique se cada comando é aceito apenas uma vez, sem disparar ações duplicadas.
Para jogos de navegador, verifique o comportamento do teclado, do toque e do foco onde for relevante. Mesmo uma cena fluida parece estar com defeito se uma sobreposição esconde a próxima escolha ou se uma transição bloqueia os comandos sem avisar. Considere o retorno visual e os controles acessíveis como parte da responsividade.
Testar possíveis otimizações isoladamente
Altere um recurso ou uma condição de renderização relevante por vez e compare com a referência. Registre a aprovação visual junto com a medição de desempenho. Para trabalhos em 3D, compare mudanças de LOD, texturas e iluminação na mesma cena, com a mesma câmera.
Mantenha o original disponível para comparação direta. A redução do volume de dados distribuídos, por si só, não comprova uma melhora de desempenho. A compressão pode alterar o custo de decodificação ou transferência, e mudanças no renderizador podem alterar o visual. Meça o indicador ligado ao defeito que você está tentando corrigir.
Definir e fazer cumprir o orçamento de lançamento
Use as observações do trecho jogável para estabelecer limites práticos para o tamanho distribuído, o atraso nas transições, as falhas de memória e a resposta aos comandos nos dispositivos-alvo. Verifique novamente quando um novo capítulo ou tipo de recurso acrescentar carga. O orçamento deve refletir o que a build e os dispositivos conseguem sustentar.
Arquive o relatório dos dispositivos junto com a build candidata e marque os dispositivos não testados como não verificados. Aceite uma otimização quando ela preservar a apresentação aprovada e melhorar a experiência pretendida em condições reproduzíveis.
Decisões-chave
- Acompanhe separadamente o tamanho do download, a memória ocupada após a decodificação e o custo de renderização.
- Meça cenas representativas em dispositivos-alvo físicos.
- Compare uma única alteração candidata com a referência aprovada.
- Use a emulação para verificar o layout e testes em dispositivos para embasar afirmações sobre desempenho.
Arquivos do guia
Registro de recursos ↓Matriz de testes de dispositivos ↓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 +
- Documentação do Ren'Py para Android ↗
- Documentação do Ren'Py para web ↗
- Orientações de desempenho do Godot ↗
Última verificação 5 de outubro de 2026.