Pular para o conteúdo

Voltar para projetos

WebGL

Tempo de carregamento percebido em um jogo 3D no navegador

· 6 min

Um jogo de ação em 3D, rodando inteiramente no navegador via WebGL, precisa equilibrar dois objetivos que competem entre si: carregar áudio e modelos tridimensionais suficientes pra parecer completo, e ainda assim dar a sensação de estar pronto pra jogar quase no instante em que a página abre.

Ilustração de um botão de play com uma barra de progresso

Áudio bloqueando o início do jogo

Numa versão anterior, todos os arquivos de som das armas eram carregados de forma antecipada, durante a inicialização da cena, antes mesmo de o jogador interagir com qualquer coisa. Isso adicionava uma fatia de tempo de rede ao momento em que o jogo ficava pronto, e esbarrava numa restrição comum de navegador: contexto de áudio não pode ser iniciado sem um gesto do usuário, então parte desse carregamento antecipado nem cumpria seu propósito.

Adiando o carregamento pro primeiro gesto do jogador

O carregamento de áudio passou a ser adiado pra trás do primeiro clique ou toque do jogador. Isso resolveu os dois problemas de uma vez: o tempo até a cena parecer pronta caiu, porque esse carregamento saiu do caminho crítico, e o carregamento passou a coincidir exatamente com o momento em que o navegador já permite iniciar áudio de qualquer forma.

Modelos 3D: mostrar algo na hora, trocar depois

As armas do jogo inicialmente eram construídas só com geometria primitiva simples, rápidas de montar, mas visualmente pobres. A versão mais recente adota uma abordagem híbrida: constrói e exibe imediatamente uma versão simplificada e barata de cada arma, e carrega o modelo 3D real em segundo plano, substituindo a versão provisória assim que o carregamento termina. Se o modelo real falhar ao carregar, o jogo simplesmente continua com a versão simplificada em vez de travar ou mostrar um buraco na cena.

O que ainda falta

Nem todo o conteúdo 3D planejado está com esse carregamento sob demanda aplicado, parte dos modelos ainda existe só como arquivo no projeto, sem compressão, aguardando ser conectada da mesma forma. É um lembrete de que esse tipo de orçamento de carregamento precisa ser vigiado conforme mais conteúdo é adicionado, não resolvido uma vez e esquecido.

Resultado

Sem depender de nenhuma métrica de FPS, o efeito é perceptível: o jogo chega a um estado jogável mais rápido e nunca fica preso esperando rede antes de o jogador ter feito qualquer coisa, a única espera acontece em paralelo, enquanto o jogador já está jogando com uma versão provisória na tela.