Optimizing Deep Rock Galactic Survivor for mobile

O que é necessário para levar um jogo complexo de PC para jogadores em dispositivos móveis? Jogos de diversão Rochas Profundas Galácticas: Sobrevivente Combina um loop de "paraíso das balas" com os anões, classes, armas e mecânicas de escavação de Deep Rock Galactic . O desafio para a empresa de portabilidade Piktiv foi gerenciar milhares de inimigos e componentes ambientais simulados simultaneamente, mantendo uma taxa de quadros estável em um hardware com uma fração do orçamento de GPU, CPU e memória.

Para proporcionar essa experiência em dispositivos móveis, foi necessário reformular os sistemas cujo custo aumenta proporcionalmente ao número de inimigos: busca de caminhos, consultas de física, renderização de inimigos, cálculos de danos e renderização do ambiente. A equipe também teve que adaptar o jogo para um iPad de 3 GB, oferecer suporte a uma ampla gama de dispositivos, desde os principais modelos atuais até hardware Android de anos atrás, e manter uma integração unidirecional com uma versão para PC que ainda estava em desenvolvimento ativo.

Conversamos com o gerente de engenharia Marcus Ekelund e o engenheiro principal Fredrik Åkerblom sobre a portabilidade do jogo. Rochas Profundas Galácticas: Sobrevivente para dispositivos móveis, suas soluções personalizadas e como otimizaram o desempenho em um cenário de dispositivos fragmentado.

Quais eram seus principais objetivos técnicos ao desenvolver a porta móvel?

Fredrik Åkerblom: Muitos dos objetivos técnicos que tínhamos inicialmente eram simplesmente: Será que conseguimos fazer isso funcionar em dispositivos móveis? E qual a variedade de dispositivos que podemos alcançar? Se você observar os produtos da Apple , verá que não há uma grande granularidade de especificações que você possa atingir no envio. Há os itens mais modernos, depois uma categoria um pouco mais ampla que inclui grande parte do que está disponível atualmente, e por fim, há todo o resto. Você quer atingir pelo menos essa categoria intermediária.

Um dos problemas recorrentes para nós era que todos esses dispositivos tinham 4 GB de RAM, exceto um iPad que tinha 3 GB. Assim, isso se tornou um objetivo técnico fundamental: É possível executar o aplicativo neste iPad sem que ele trave? Tínhamos aproximadamente 1.850 MB disponíveis e, se ultrapassássemos esse limite, seria o fim do jogo. Grande parte do trabalho inicial consistiu em configurar a memória RAM corretamente, e depois disso pudemos analisar melhor o desempenho real do jogo em diversas plataformas. O Android, por outro lado, possui cerca de 9.000 dispositivos diferentes atualmente, então garantir que tudo funcione corretamente é uma ciência à parte.

Quais foram os maiores gargalos de desempenho que você enfrentou ao migrar de hardware de PC para hardware móvel e como os superou?

FÅ: Havia alguns sistemas principais que realmente se destacavam, e eram aqueles com milhares de objetos ativos: Números de dano, projéteis, o próprio mundo e os inimigos animados em 3D .

Os textos de dano, por exemplo, eram originalmente um GameObject usando TextMesh Pro . Mas quando você tem mil inimigos na tela e joga uma granada neles, todos eles precisam mostrar um número de dano. O gargalo está na geração da malha de texto: Fazer com que a fonte traduza seu texto em algo visual.

No final, usamos um sistema de partículas padrão do Unity com uma folha de sprites contendo os números de 0 a 9.

MEU: Outro exemplo foi o cálculo da rota de todos os inimigos, que utilizou o sistema NavMesh integrado no PC. Também contamos com o apoio de uma equipe de engenheiros da Unity , e um deles começou a trabalhar em uma solução que utilizava a navegação por campos de fluxo. Outro engenheiro criou uma solução de árvore KD para otimizar e eliminar grande parte das consultas de física.

FÅ: Com a renderização de inimigos, temos algo como mil renderizadores de malha com animação de esqueletos na tela ao mesmo tempo, e isso não funciona muito bem. Na verdade, praticamente todos esses inimigos têm apenas uma animação, então não precisamos de suporte para múltiplas animações.

Em vez disso, utiliza-se um sistema onde cada quadro-chave da animação é incorporado a uma textura. Percorremos cada quadro dessa forma, e então todos eles são animados por vértices através de um shader na GPU, então praticamente não há custo de CPU.

Reduzir tudo a uma única malha estática e uma textura foi uma grande melhoria, e também permite fazer coisas como instanciamento por GPU , já que tecnicamente são todas a mesma malha com o mesmo material.

Como funcionam internamente os campos de fluxo e as árvores KD, e o que eles substituíram?

FÅ: O campo de fluxo é uma inversão de onde reside o custo na busca de caminhos. Normalmente, quando você tem 20 ou 30 agentes buscando caminhos em um ambiente, você cria uma malha desse ambiente e cada agente é responsável por sua própria busca de caminho. Quando se tem milhares deles, isso se torna um gargalo bastante grande, porque o custo tende a aumentar proporcionalmente ao número de agentes.

Você cria uma grade sobre todo o nível, depois começa no seu objetivo e todos os blocos ao redor desenham uma seta apontando para o objetivo. Dê um passo para fora, aponte as setas novamente para o objeto mais próximo que já tenha uma seta e continue até cobrir todo o campo. Assim, em vez de ter um custo por agente, o preço é baseado no tamanho da área que você deseja navegar.

Você também pode limitar isso ainda mais. Calculamos com base na localização dos inimigos, então criamos uma caixa delimitadora que contém todos os inimigos mais o jogador, e atualizamos apenas o espaço dentro dessa caixa.

Para consultas espaciais, utilizamos uma árvore KD. Se você tem um cômodo grande e traça uma linha no meio dele, você o dividiu repentinamente em dois espaços. Você cria uma estrutura em árvore que pode ser consultada com bastante facilidade: Aqui está um ponto e um raio, me dê o que estiver ali.

Isso poderia substituir muitas das consultas de física mais complexas, como aquela em que uma granada explodiu aqui e eu preciso encontrar todos os inimigos neste círculo. Não tenho certeza se no final das contas foi uma solução perfeita, porque a árvore de habilidades de abate precisa ser regenerada com frequência — os inimigos estão em constante movimento, então a árvore precisa ser reconstruída constantemente.

Como você abordou os testes e ajustes em dispositivos móveis?

FÅ: Uma das primeiras coisas que fizemos foi definir um dispositivo no qual achássemos que o jogo deveria ser capaz de rodar – um dispositivo de nível relativamente baixo, onde desejávamos pelo menos 30 fps.

Criamos um sistema automático de medição de desempenho onde podemos configurar uma série de cenários. Executamos um total de seis cenários em Rochas Profundas Galácticas: Sobrevivente . Podemos construir o jogo especificamente nesse modo de medição e, assim que ele for iniciado em um dispositivo, entrará em um bioma e executará esses seis cenários.

Uma opção seria um cenário base com o jogador parado, e então gerar mil inimigos se movendo em sua direção, ou gerar 500 inimigos, equipá-lo com todas essas armas e dispará-las automaticamente em todas as direções. Isso nos dá uma ideia geral do que está acontecendo, e medimos CPU, GPU, memória – praticamente tudo o que podemos medir. Executamos o teste em todos os biomas para verificar se algum deles apresenta problemas específicos de desempenho.

O Unity Profiler foi uma das nossas principais ferramentas para auditorias de desempenho da CPU, especialmente no início, quando estávamos procurando por melhorias fáceis de implementar e os maiores ganhos possíveis.

Como os Addressables ajudaram a gerenciar o conteúdo e o consumo de memória em dispositivos móveis?

FÅ: Os Addressables ​​foram uma parte importante para atingir o limite de memória de 3 GB no iPad. Em geral, priorizamos as coisas que pareciam mais simples desde o início. Biomas diferentes, por exemplo, você nunca está em mais de um bioma ao mesmo tempo, então você pode explorar todos esses recursos gráficos e configurações.

Os Addressables ​​introduzem comportamento assíncrono em algo que antes era completamente síncrono, e reconstruir um sistema inteiro para ser assíncrono pode ser um desafio de arquitetura bastante grande, dependendo do jogo. Mas, nesse cenário, foi a solução ideal para nós.

Quais indicadores de desempenho você utilizou para medir o sucesso da versão mobile?

FÅ: A maioria das nossas metas estava relacionada ao desempenho: Nesses modelos, queremos atingir 30 fps, e nesses modelos topo de linha, esperamos 60 fps.

Em Rochas Profundas Galácticas: Sobrevivente Sempre que você mata um inseto, vários cubos azuis brilhantes aparecem e você os coleta para subir de nível. Um dos nossos cenários de medição automática gerou cerca de 4.000 dessas medições em 10 segundos, o que representou um sério impacto no desempenho logo no início. Após essa otimização inicial, ela deixou de ser mensurável.

A otimização dos movimentos e da física dos inimigos também elevou significativamente a taxa de quadros por segundo (fps) mínima. Isso se transformou nos campos de fluxo, bem como em uma longa cadeia de tarefas Burst – com 10 ou 15 dependências – responsáveis ​​por mover todos os inimigos, tudo fora do sistema de física regular.

Este jogo gera seus níveis proceduralmente, portanto o térreo e todas as paredes são construídos a partir de objetos individuais. Como temos uma câmera posicionada de cima para baixo no mesmo ângulo o tempo todo, podemos calcular facilmente a área visível, reunir todos esses objetos e enviá-los ao renderizador por meio de nossos próprios comandos de desenho em lote. Foi uma grande melhoria tanto para a GPU quanto para a CPU, pois enviar todas essas chamadas de desenho individualmente representava um custo considerável para a CPU.

Qual é a sua principal dica para desenvolvedores que desejam adaptar seus jogos de PC para dispositivos móveis?

MEU: Não se trata tanto de encontrar uma solução milagrosa, mas sim da colaboração entre diferentes sistemas.

FÅ: O custo de transferir dados entre vários componentes começa a aumentar consideravelmente quando se processa milhares de entidades a cada quadro. Se você conseguir gerenciar seus dados de forma que todos estejam em contêineres nativos e usar os mesmos contêineres nativos durante todo o processo, poderá lucrar bastante.

MEU: Outra conclusão importante deste projeto: Imagine que você criou um jogo e, depois de finalizado, percebe que provavelmente deveria tê-lo desenvolvido usando o ECS para Unity ou qualquer um dos sistemas da pilha de tecnologia orientada a dados (DOTS) . Você não precisa fazer uma conversão completa do seu jogo e reescrevê-lo. Estamos usando apenas o compilador Burst e muitos dos tipos de dados nativos.

Rochas Profundas Galácticas: Sobrevivente Está disponível no Steam, no Xbox , na App Store e no Google Play . Confira mais histórias de desenvolvedores da Unity no Blog da Unity e na Central de Recursos .