Voltar às novidades

Por trás das cenas: Desempenho

J Brian Smith

Olá pessoal! Eu sou J Brian e lidero os esforços de tecnologia de núcleo para a equipe do Crucible. Uma das responsabilidades da nossa equipe é o desempenho do jogo.

 

De um modo geral, desempenho é o que dá a sensação de resposta e harmonia ao jogo. Mas os problemas de desempenho podem acontecer de várias formas diferentes e ter muitas causas diferentes. Vamos começar falando de alguns componentes essenciais do desempenho do jogo e no que estamos trabalhando desde maio. Depois, vamos falar de alguns dos próximos passos ao avançarmos para um futuro com mais desempenho e mais promissor!

 


Taxa de quadros

Quase todo jogador sabe que mais quadros por segundos (fps) é melhor.  Problemas com taxa de quadros podem surgir como baixa sustentação de taxa de quadros ou aparecer como “intermitências” (um único quadro leva muito mais tempo que o outro, causando a quebra). Nosso objetivo é que, nas máquinas que atendem às especificações recomendadas de sistema, o uso do padrão de configurações gráficas em “alto”, faça o Crucible rodar a 60 fps constantemente.  Ele poderá rodar mais rápido em hardware mais avançado, e naquele com “especificações mínimas” e configurações padrão em “baixo”, ele rodará a pelo menos 30 fps constantemente. No momento, estamos a 60 fps nas especificações recomendadas para a maioria dos quadros, mas frequentemente caímos abaixo de 60 fps por algum tempo ou temos quadros ruins isolados.

 

No desenvolvimento, geralmente olhamos mais para o “tempo de quadro” do que para a taxa de quadros. Para atingir 60 fps, cada quadro deve levar cerca de 16,5 milissegundos ou menos. Nosso trabalho gira em torno da redução do tempo que leva para concluir a simulação e renderizar um único quadro. Fizemos mais de uma dúzia de micro-otimizações por taxa de quadro, e no geral reduzimos o tempo de quadro em mais de 15% desde o lançamento para máquinas com especificações recomendadas, ultrapassando o limite crítico onde a maioria dos nossos quadros levam menos que o alvo de 16,5 milissegundos. Grande parte das melhorias veio da maior eficiência dos sistemas centrais e do código do engine que executam a lógica de jogo, ou do melhor uso dos núcleos ociosos da unidade de processamento central (CPU) em partes do nosso código que eram desnecessariamente vinculados ao uso de apenas um núcleo de CPU por vez.

 

Dessincronização

 

Quando seu cliente (a cópia do jogo executada na sua máquina) e o servidor compartilham o mesmo estado do mundo do jogo com precisão, nós chamamos isso de sincronização, pois eles “concordam” com o mesmo estado do mundo. Uma dessincronização é quando o cliente e o servidor não concordam com o estado do mundo dado em qualquer ponto no tempo. Quando isso acontece, o servidor emite uma correção ao cliente que o força a adotar o estado real de mundo do servidor (o servidor é sempre a “autoridade” no que diz respeito ao estado do mundo). Essa correção faz o mundo deformar anormalmente de alguma maneira sob a sua perspectiva. Você e outro jogador podem “ser arrastados” para lugares diferentes, pode haver ação ou cancelamento de uma habilidade que você achou que poderia ou não acontecer, ou algum outro valor de jogabilidade pode mudar de um jeito que parece anormal. Se a dessincronização acontecer em vários quadros seguidos, vai ser bem ruim e isso pode causar problemas de taxa de quadro e largura de banda.

 

As realidades do tráfego na internet e os modelos de sincronização de rede de baixa latência nos impedem de reduzir isso a zero, mas podemos melhorá-los. Descobrimos algumas situações onde uma única dessincronização por queda do pacote de internet ou erro de lógica pode resultar em uma cadeia de dezenas de dessincronizações seguidas. Corrigir diversos desses erros reduziu a taxa geral de dessincronização em mais da metade do que era no lançamento.

 

Memória

O desempenho fica muito prejudicado quando o jogo está quase no limite da memória de acesso aleatório (RAM) ou vídeo RAM do sistema do computador, em especial se outros programas e sistemas estiverem usando alguns recursos. O uso de menos memória garante que cheguemos menos a esses limites, mantendo a harmonia do desempenho e o que nos permitiria executar numa maior variedade de hardware.

 

Definimos o objetivo de reduzir nosso uso de memória no lançamento em 3 GB (que é bastante, se considerar que rodamos em máquinas com 8 GB de RAM!), e no nosso lançamento em 12 de agosto reduzimos o uso a 2,6 GB. O aspecto mais difícil desse trabalho foi implementar medidas e código de alerta muito melhores no nosso engine, dando aos desenvolvedores dados detalhados do que exatamente estava usando toda essa memória. Armados de dados precisos sobre quais sistemas e conteúdo usavam qual memória, mais da metade de uma dezena de áreas-chave do jogo foram otimizadas em código e conteúdo para reduzir em muito o uso de memória, sem sacrificar a qualidade da experiência de jogo. Este trabalho melhorou significantemente a experiência de jogar o jogo na gama de hardware mais acessível compatível.

 

Largura de banda

A maioria das conexões de internet dos jogadores flutua durante a partida. Quando o jogo precisa enviar ou receber mais informações que sua conexão suporte em qualquer momento, as informações são perdidas e o jogo passa por dessincronização e alta latência. Reduzir a largura de banda usada pelo jogo reduz a frequência desses problemas.

 

Uma das principais otimizações que fizemos nesse fronte até agora, tem a ver com alguns sistemas centrais que estavam usando mais largura de banda que o necessário para sincronizar os dados.

 


Rastreamento de progresso

Agora que vimos os quatro fatores (taxa de quadros, dessincronização, memória e largura de banda) que fazem a maior parte na experiência de desempenho do jogador, como sabemos se nossas mudanças estão funcionando?

 

Sem a medição constante das características do nosso desempenho é muito difícil saber se estamos progredindo! Temos medido o desempenho com cuidado durante o desenvolvimento e continuamos a refinar nossa habilidade de entender todos os cenários de desempenho no jogo. Há três maneiras primárias de rastrear como o desempenho muda com o tempo:

 

  • Melhoramos nossa automação de teste, e ela testa e coleta dados detalhados de desempenho do jogo dezenas de vezes por dia, assim descrevendo o desempenho mais consistentemente e corretamente. Esses dados nos permitem agir rapidamente quando surgem novos problemas e verificar a eficácia das novas otimizações.

 

  • Suplementamos os dados automatizados com execuções de desempenho manual diariamente, e a equipe de Controle de Qualidade (QA) joga o jogo com ferramentas especiais e código de gravação de desempenho, para garantir que temos dados de cenários reais do jogo que podem se perder em nosso teste automatizado (que por padrão testa sempre e exatamente as mesmas condições).

 

  • Por fim, rastreamos os dados de desempenho de alto nível de jogos do mundo real em uma página interna da web, para comparar o que os jogadores estão realmente vivenciando segundo nossas expectativas de testagem interna.

 


Expectativas

Agora que vimos o que contribui para a qualidade de desempenho, o estado de cada um dos atributos em Crucible e como nós os medimos, só sobrou um tema: o que vem por aí! Aqui vai um pouco do que estamos trabalhando agora, dividido por categoria:

 

Taxa de quadros

Nos nossos testes internos, com máquina em especificações recomendadas, ainda encontramos cerca de 10% dos nossos quadros em 19 ms (lembrem que estamos buscando 16,5 ms ou menos), e 1% dos nossos quadros em 23 ms. Avançando, esperamos fazer maior uso de núcleos adicionais de CPU, o que reduzirá o parâmetro de tempo de quadro, especialmente em PCs de ponta com mais núcleos de CPU. Também faremos a análise mais profunda das situações que resultam em “quadros ruins” para melhor abordar as causas específicas. E por fim, iremos trabalhar no melhor equilíbrio da carga de trabalho necessária a ser feita em qualquer quadro isolado.

 

Estamos buscando a compatibilidade consistente com 144 fps em hardware de ponta. De curto a médio prazo, iremos focar primariamente no suporte a uma taxa constante de 60 fps em máquinas com especificações recomendadas, e nos ganhos que contribuirão imediatamente para fps maiores em hardware de ponta.

 

Dessincronização

Nos próximos meses, iremos trabalhar para reduzir a taxa atual de dessincronizações em mais da metade, o que as tornará raras e deve ter seu impacto percebido numa maior harmonia de jogo, especialmente em situações de combate pesado. Essas otimizações virão da melhora da lógica de previsão em casos onde a previsão existente é necessária, porém frágil, e também removeremos algumas lógicas de previsão desnecessárias.

 

Memória

Como falei anteriormente, o objetivo que definimos é reduzir o uso de memória do Crucible em 3 GB e já baixamos em aproximadamente 2,6 GB. Com mais algumas otimizações de código e conteúdo planejadas (especificamente relacionadas a como carregamos a geometria na memória), acreditamos que podemos concluir o objetivo no próximo mês.

 

Largura de banda

No nosso próximo lançamento, usaremos tecnologia de compressão rápida para reduzir ainda mais o uso da largura de banda para colossais 30%. Com isso, atingiremos com consistência o nosso objetivo de usar menos de 300 kbit/segundo de download em largura de banda (e a maior parte do tempo usando ainda menos que isso).

 

Nesse ponto, estaremos praticamente otimizando a largura da banda no período, mas daremos uma olhada em quanto podemos melhorar o upload da largura de banda usada pelo jogo. Usamos menos upload que download no geral, mas algumas pessoas têm conexões com mais restrições de upload que download, e isso pode precisar de maior otimização, se encontrarmos boas oportunidades.

 


Muito obrigado por ler e por jogar o Crucible! Sabemos que o desempenho é crítico na experiência de um atirador multiplayer competitivo. Nunca estaremos completamente satisfeitos e sempre buscaremos novas maneiras de melhorar o desempenho no jogo. Se você for apaixonado por desempenho e tiver observações sobre situações de jogo detalhadas e específicas que podem dar problemas, adoraríamos saber — o canal “#bugg reports” no Discord é um lugar excelente para compartilhar.

 


V2