Otimizando Sonic Dream Team para atingir metas de fps em dispositivos Apple Arcade

Sonic Dream Team é um jogo de plataforma desenvolvido pela Hardlight e publicado pela SEGA. O jogo, uma edição da série Sonic the Hedgehog, tem Sonic e seus amigos acelerando pelos sonhos distorcidos do malvado Doutor Eggman para frustrar sua busca pela dominação mundial.

Apple Arcade exige que os estúdios atinjam as mesmas metas de desempenho em todos os dispositivos suportados, o que coloca mais pressão na equipe para otimizar e fazer com que o jogo fique ótimo em tudo, desde um iPhone 6s Plus até um iPhone 16. Aqui está como eles atingiram a taxa de quadros necessária em dispositivos de baixo e alto desempenho.

Sonic Dream Team: Um estudo de caso da Unity

Como uma equipe otimiza para atingir a taxa de quadros necessária em dispositivos de baixo e alto desempenho?

Após 10 anos com o ouriço, a Hardlight queria um novo desafio ao intensificar a narrativa, envolvendo mais personagens e misturando estilos de ação e aventura com visuais de alta fidelidade – que ficavam ótimos na ampla gama de dispositivos onde os jogos da Apple Arcade podem ser jogados. Enquanto trabalhavam em direção a esses objetivos, a equipe encontrou problemas de desempenho relacionados à CPU e GPU que os levaram a continuar otimizando.

Os resultados

Reduziu os tempos de quadro da CPU de 52 ms para 16 ms em dispositivos de médio e alto desempenho

Reduziu o tamanho da build no iOS de 4 GB para 2 GB

Reduziu a memória em tempo de execução das variantes de shader de 1 GB+ para menos de 100 MB

Abordando problemas de renderização

Para analisar o desempenho, a equipe utilizou as várias ferramentas de análise que a Unity oferece – em particular, o Profiler, o Frame Debugger e o Memory Profiler. Essas ferramentas ajudaram a equipe a entender melhor de onde vinham os problemas para alcançar 30 fps e 60 fps em dispositivos.

A renderização ocupou uma grande parte do orçamento total de tempo de quadro, especialmente em dispositivos de baixo desempenho. A equipe confiou no agrupamento SRP para ajudar a reduzir esse custo.

“Escolhemos o Universal Render Pipeline (URP) devido à sua abordagem moderna de renderização e seu suporte contínuo no futuro pela Unity,” diz Fraser Hutchison, um artista técnico da Hardlight. A equipe priorizou recursos como SRP Batching e Shader Graph para permitir novas maneiras de aprimorar seus visuais em dispositivos móveis. “O agrupador SRP fez muito trabalho pesado para nós e deu aos nossos artistas a flexibilidade de não se preocupar com restrições de material como no agrupamento estático padrão,” continua Hutchison. “Mediamos de 100 a 200 lotes, principalmente na fila opaca, o que funcionou bem.”

A equipe também reduziu as sondas de reflexão e usou uma fila de ordenação de materiais e iluminação pré-processada para aumentar a eficiência do agrupamento e reduzir seu custo de renderização.

Devido ao tamanho de seus níveis, implementaram um sistema de culling hierárquico personalizado para reduzir a sobrecarga de renderização. “Cada nível foi dividido em grandes pedaços, que chamamos de ‘ilhas’, e foi desativado ou ativado dependendo da posição do jogador,” diz Hutchison. “Isso também significava que podíamos desativar animadores e efeitos de partículas para essas ilhas também. No geral, essa foi uma solução leve que atendeu bem às nossas necessidades.”

“Os artistas da equipe queriam gráficos de alta fidelidade com muitos dados de malha únicos, efeitos de shader e pós-processamento para ajudar a impulsionar a qualidade onírica do mundo que estavam criando. Com o URP, ter recursos como pós-processamento embutido significa que podemos criar visuais rapidamente sem sempre precisar de soluções completamente personalizadas.” – Simon Dew, Diretor de Arte, Hardlight

Reduzindo os tempos de quadro da CPU

Para garantir um jogo consistente em todos os dispositivos iOS, a equipe da Hardlight definiu sua frequência de física para 60 Hz, em vez do padrão de 50 Hz. Eles usaram FixedUpdate para impor um intervalo de tempo esperado entre as atualizações de um objeto específico para melhorar o determinismo.

Quando o tempo de quadro aumenta significativamente devido a problemas de desempenho, várias chamadas de FixedUpdate dentro de um único quadro são feitas no Unity para manter a taxa de atualização de física desejada.

“Eventualmente, a simulação não conseguiu processar todas as atualizações necessárias a tempo, levando a tempos de quadro ainda mais longos”, diz Louis Macan, engenheiro-chefe de software da Hardlight. O impacto de ter o mesmo intervalo de tempo de física levou a um aumento na quantidade de chamadas de FixedUpdate por quadro em dispositivos de baixo desempenho, que executam o jogo a 30 fps.

Para manter uma boa taxa de quadros em dispositivos mais antigos como o iPhone 6s Plus, a equipe otimizou cada FixedUpdate. Enquanto perfilavam uma chamada de FixedUpdate individual, notaram que a grande maioria do tempo de FixedUpdate era ocupada por chamadas de atualização de centenas de instâncias de scripts. Mesmo que esses scripts saíssem rapidamente por meio de uma condição de saída antecipada, as chamadas de FixedUpdate ainda eram executadas.

“Mesmo que pareça que o FixedUpdate não está fazendo nada se uma condição não for atendida, cada função de evento do Unity declarada em um script causará uma sobrecarga,” diz Macan. “Embora a sobrecarga seja pequena por si só, os milhares de chamadas de Update, FixedUpdate e Late Update executadas por scripts adicionados durante a criação de níveis tiveram um grande impacto.”

Corrigir isso exigiu uma combinação de abordagens. Primeiramente, um gerenciador foi adicionado para que os scripts se registrassem, e o gerenciador acionaria cada objeto em sequência na frequência de atualização necessária. Isso significava que todas as funções de evento do Unity poderiam ser removidas e não estavam mais ocupando tempo na CPU. Finalmente, objetos que não interagiam com a física do jogador foram configurados para atualizar, reduzindo pela metade o custo computacional em dispositivos de baixo desempenho.

Aprimorando os sistemas de partículas do jogo

A equipe também percebeu que a quantidade excessiva de sistemas de partículas em uma cena afetava o desempenho da CPU. Como parte de um sistema de pooling de partículas, a equipe ativou ou desativou sistemas de partículas usando a API ParticleSystemRenderer através de um componente personalizado ParticleEffectsWrapper. Com mais de 500 atualizações de sistemas de partículas sendo processadas na thread principal e de trabalho, isso levou cerca de 5,2 ms do tempo de quadro da CPU.

“O Visual Effect Graph do Unity não era uma opção para nós neste projeto, já que muitos de nossos dispositivos de baixo desempenho não suportam computação GPU na qual esse sistema depende,” diz Hutchison. “Se pudéssemos tê-lo usado, teríamos nos beneficiado de sua melhor tecnologia de culling e instancing.”

Sistemas de partículas no Unity podem ser procedurais ou não procedurais. Um sistema de partículas procedural pode ser retrocedido ou avançado livremente para qualquer momento no tempo.

“Com o procedural, o Unity pode descartar com segurança o sistema de partículas e todo o seu processamento associado quando está fora da tela, e então simplesmente avançá-lo para o estado correto quando se torna visível novamente,” diz Hutchison. “Isso pode gerar ganhos de desempenho consideráveis. No entanto, isso é frequentemente uma parte negligenciada da criação de efeitos de partículas e é muito fácil acidentalmente tornar o efeito não procedural.”

Para evitar isso, o componente ParticleEffectsWrapper não apenas descartou partículas com base no frustum da câmera, mas também definiu limites de renderização personalizados para que mesmo se uma partícula fosse marcada como procedural, limites definidos manualmente ainda pudessem descartar o sistema.

“Com um grande número de sistemas de partículas em uma cena, tornou-se importante garantir que o maior número possível de sistemas fosse procedural e, se não, que seus limites de renderização fossem definidos no componente ParticleEffectsWrapper,” diz Macan. “Isso impediu cálculos e chamadas de desenho desnecessárias, o que melhorou significativamente o desempenho.”

Juntamente com o culling, a equipe priorizou boas práticas de criação para efeitos. Eles usaram apenas o número necessário de sistemas de partículas e limitaram o número máximo de partículas para reduzir a sobrecarga de alfa e a alocação de memória. Eles também se concentraram em trabalhar com o atlas de texturas de seus efeitos de partículas e evitar tempos de duração excessivos. Eles também habilitaram o agrupamento dinâmico através da opção ‘Mostrar Todas as Propriedades Ocultas’ nas configurações de renderização do URP, e essa pequena mudança os ajudou a reduzir as chamadas de desenho de partículas e acelerar a renderização.

Enfrentando gargalos de GPU

A visão para Sonic Dream Team exigia gráficos avançados e jogabilidade rápida. Para personalização, eles usaram recursos de renderização para certos efeitos como Oclusão Ambiental em Espaço de Tela, efeitos personalizados em tela cheia e decalques em espaço de tela. Isso criou atrasos na renderização e problemas de memória.

“Durante o desenvolvimento, descobrimos que ao usar decalques em espaço de tela baseados em profundidade para sombras de personagens e inimigos, o recurso de renderização estava causando uma pré-passagem de profundidade-normal desnecessária,” diz Hutchison. “Isso significava que uma grande parte do tempo de renderização estava sendo gasta em trabalho desnecessário e aumentava a memória do alvo de renderização, já que não precisávamos do buffer normal. Trabalhamos com a equipe da Unity para resolver isso, e a correção foi adicionada em um lançamento de patch do motor.”

O pré-aquecimento de shaders também era uma preocupação, com picos significativos de CPU/GPU ao longo dos níveis causando travamentos. “Para pré-aquecer efetivamente shaders no Metal, os shaders devem conter todas as palavras-chave necessárias e ter o grupo de layout de vértices específico de cada malha que eles renderizarão. Isso significava que o cache apenas para o Editor não era possível,” diz Hutchison.

Para combater isso, os engenheiros da Hardlight criaram um sistema para “renderizar rapidamente” todos os objetos na frente da câmera no momento do carregamento, atrás da tela de carregamento.

“Nossa tecnologia de culling de ilha forneceu fácil acesso a listas de todos os renderizadores na cena. Fazer isso no dispositivo significava que tínhamos todos os dados corretos do estado do pipeline e palavras-chave das configurações de qualidade antes que o jogador entrasse oficialmente no nível,” diz Hutchison. “Isso aumentou ligeiramente os tempos de carregamento do nível, no entanto, valeu a pena pela experiência do jogador.”

Embora satisfeito com seus resultados superando o pré-aquecimento de shaders, Hutchison está analisando outras opções para o futuro. “Desde o lançamento do jogo, a Unity lançou cache PSO e pré-aquecimento através de GraphicStateCollections, que queremos usar no futuro.”

Diminuindo o tamanho da memória com Addressables

Durante o desenvolvimento, o jogo usou 1,35 GB de memória em tempo de execução. Considerando que o iPhone 6s Plus tinha apenas 2 GB de memória física, isso poderia ter levado a problemas, incluindo o risco do sistema operacional encerrar o aplicativo.

“A duplicação de ativos foi um grande obstáculo. O jogo tinha mais de 3.000 ativos duplicados, o que aumentou seu tamanho e fez com que os mesmos ativos fossem carregados várias vezes durante a execução,” diz Macan.

Na época, o Sistema Addressable do Unity gerenciava apenas uma pequena fração dos ativos do jogo. Isso levou a casos em que os ativos estavam sendo referenciados tanto no binário quanto através de Grupos Addressable, causando duplicação.

No início do desenvolvimento, a equipe usou um único Grupo Addressable e o configurou para empacotar separadamente. Isso significava que cada ativo no grupo tinha seu próprio AssetBundle separado. Embora útil em casos específicos, essa abordagem granular também levou a uma grande quantidade de ativos duplicados. Garantir que todos os ativos fossem Addressable e ter uma abordagem estruturada para Grupos Addressable reduziu pela metade o tamanho da build no iOS de 4GB para 2GB.

Reduzindo a memória de variantes de shader

As variantes de shader foram uma grande área de foco para a equipe durante a produção do jogo, com a memória de shader em tempo de execução aumentando para mais de 1 GB. O número de variantes também aumentou os tempos de build. Eles enfrentaram o problema usando vários métodos – principalmente a remoção de shaders com IPreprocessShaders, o pré-filtragem do Unity, o carregamento dinâmico de shaders do Unity e a redução de ramificações de shaders.

“Usamos nossa própria implementação personalizada de remoção de IPreprocessShaders, que removeu globalmente palavras-chave de shader de todos os shaders e uma abordagem local através do Shader Control da Unity Asset Store,” diz Hutchison. “Ser mais intencional sobre quando usar uma palavra-chave em shaders também foi uma grande vitória.”

Seus shaders usaram Shader Graph, que inclui inerentemente palavras-chave predefinidas pelo Unity, e adicionar palavras-chave extras a esses teve um efeito exponencial. Trocar alguma lógica para ramificações dinâmicas ou remover completamente palavras-chave reduziu significativamente o total de variantes.

“Com todos esses métodos combinados, diminuímos a memória de variantes de shader em tempo de execução para uma média de 100 MB ou menos”, diz Hutchison. “Também usamos o Auditor de Projetos da Unity, que fornece uma visão global de todos os ativos e configurações na construção. Usando isso em combinação com o Profiler de Memória, identificamos texturas e malhas que se beneficiaram de predefinições de importação aprimoradas. Isso reduziu ainda mais a pressão sobre a memória dos ativos de arte e áudio.”

Celebrando as vitórias e olhando para o futuro

Ao longo de mais de uma década, a Unity e a Hardlight construíram uma camada compartilhada de tecnologia na qual o estúdio confia. “Ainda estamos apoiando jogos que fizemos na Unity há 10 anos”, diz Macan.

A Unity adicionou tanto ao longo dos anos, ele observou, que o estúdio simplificou sua manutenção ao descartar algum código nativo da API da Unity. “A Unity lida com tanto suporte de dispositivo de baixo nível, que podemos nos concentrar em fazer o jogo real. À medida que a tecnologia evolui, estou confiante de que a Unity nos ajudará a acompanhar,” ele exclama.

Sonic Dream Team prova que você ainda pode ensinar um velho ouriço a fazer novas truques. E, assim como Sonic, a Hardlight e a Unity têm um forte histórico e um futuro brilhante.

Baixe agora o Unity Pro

Comece a criar jogos que competem e superam a qualidade e o sucesso de lançamentos de grandes estúdios com a ajuda de ferramentas poderosas, suporte, parceiros verificados e uma comunidade vibrante.