Como o Highstreet Market escalou um MMO VR com ECS para Unity

Highstreet: Calamity é uma fatia em escala de cidade do MMORPG de próxima geração do Highstreet Market. A equipe lançou para a comunidade de jogadores para testar recursos principais como combate e progressão.

Neste estágio, a equipe está focada em escalar a experiência multiplayer. Durante o desenvolvimento, eles encontraram gargalos técnicos, mas através de um perfilamento cuidadoso e iteração, identificaram e resolveram as questões principais. Aqui está como eles fizeram isso.

Highstreet: Calamity: Um estudo de caso da Unity

Como um estúdio escala o desenvolvimento multiplayer enquanto supera desafios técnicos?

Quando eles estavam começando a configurar seu jogo em rede, a equipe enfrentou dois grandes desafios: ineficiências de computação e renderização.

“Do lado da computação, nosso maior desafio era lidar com a computação de forma eficiente. Isso é especialmente verdadeiro para o nosso servidor, que é encarregado de simular o mundo”, diz Jack Qiao, CTO da Highstreet. “À medida que adicionamos mais jogadores e entidades de rede, o servidor teve dificuldades para processar todos eles de forma eficiente.”

No lado da renderização, construir grandes mundos imersivos em VR é difícil. “A VR exige um ambiente envolvente com muitos objetos e pontos de interesse para os jogadores explorarem,” explica Qiao. “Mas o hardware de VR autônomo tem poder de GPU limitado em comparação com as GPUs modernas de PC, o que restringe o que podemos renderizar.”

Para manter a qualidade, a equipe projetou cuidadosamente cenas para parecerem boas de todos os ângulos, enquanto equilibrava os limites de desempenho inerentes à VR.

Os resultados

Atingiu 72 fps nas áreas de jogo mais otimizadas

Reduziu o número de chamadas de desenho do Scriptable Render Pipeline (SRP) de 80 para cinco

Diminuiu o número de triângulos em uma única malha de dois milhões para 500.000

Adotando ECS para Unity para eficiência de rede

A equipe primeiro construiu um servidor personalizado em cima da camada de transporte do Mirror para gerenciar o fluxo de dados e a lógica do jogo. “Na época, a maioria das ferramentas de rede foi projetada para títulos casuais de mobile, não para MMOs de grande escala, então tivemos que criar a nossa própria,” diz Omar Sleam, arquiteto técnico chefe da Highstreet.

Quando a Unity introduziu o Netcode for Entities – uma estrutura pronta para produção construída para desempenho e jogos de grande escala – a equipe viu uma oportunidade de transição para o Sistema de Componentes de Entidade (ECS) da Unity e o Netcode for Entities. Projetada com escalabilidade em mente, a estrutura introduziu chunking, que divide dados complexos do jogo em unidades menores e mais gerenciáveis – algo que a equipe considerou essencial para seu MMO.

“Com o Netcode for Entities, os dados são enviados apenas para jogadores dentro do alcance, em vez de serem transmitidos para todo o servidor,” explica Sleam. “Também é multithreaded, o que torna as operações do servidor muito mais eficientes.”

Além da rede, a equipe também desenvolveu um sistema de árvore de comportamento construído inteiramente com ECS para Unity. Iterações anteriores dificultaram a implementação de recursos genéricos – particularmente aqueles relacionados ao controle de fluxo. A árvore de comportamento personalizada baseada em ECS para Unity resolveu essa limitação, fornecendo ferramentas flexíveis e reutilizáveis sem comprometer o desempenho.

A equipe projetou o sistema para operar perfeitamente em um ambiente em rede, dando a flexibilidade de executar árvores de comportamento no servidor, cliente ou ambos. Isso permitiu que eles descarregassem comportamentos não críticos para o cliente, melhorando o desempenho enquanto mantinham o controle centralizado para a lógica central do jogo.

Para gerenciar a estrutura baseada em sessões do jogo, a equipe se apoiou no ecossistema de serviços multiplayer da Unity. O Multiplay Hosting permitiu a alocação dinâmica de servidores, o que era ideal para a natureza baseada em sessões do jogo. “A automação reduziu nossa carga de DevOps e nos deixou focar na construção do próprio jogo”, diz Sleam. O Matchmaker foi usado para agrupar jogadores com base em vários fatores, como configurações e localização, ajudando a garantir partidas equilibradas e de baixa latência.

O Lobby da Unity alimentou o sistema de festas para que os jogadores pudessem formar e gerenciar grupos antes de entrar em uma sessão de jogo. Amigos foram integrados ao Lobby para manter festas em diferentes servidores, permitindo que os jogadores permanecessem conectados com um esforço de implementação mínimo e sem exigir um backend personalizado.

Juntos, essas ferramentas forneceram uma base multiplayer completa – cobrindo hospedagem, matchmaking, gerenciamento de festas e sistemas sociais – enquanto mantinham a implementação leve, escalável e otimizada para jogabilidade de alto desempenho.

Melhorando a modularidade com ECS para Unity

Embora a equipe tenha enfrentado uma curva de aprendizado acentuada durante sua transição do design baseado em GameObject para ECS para Unity, a produtividade melhorou significativamente uma vez que foram integrados.

“ECS para Unity reduziu muito a sobrecarga – em parte devido à sua arquitetura, e em parte porque mudamos para uma abordagem de design de cima para baixo”, diz Qiao. “Ao contrário dos GameObjects, que muitas vezes levavam a lógica duplicada, a menos que fossem cuidadosamente arquitetados, ECS para Unity impôs um design modular baseado em componentes. Isso naturalmente promoveu sistemas mais limpos e mais fáceis de manter.”

A equipe compartilhou que um dos maiores benefícios do ECS para Unity é quão fácil foi lidar com mudanças no design do jogo. “No sistema antigo, mudanças frequentemente exigiam tocar em vários scripts MonoBehaviour. Com ECS para Unity, muitas mudanças podem ser feitas simplesmente adicionando ou removendo componentes, uma vez que os comportamentos são impulsionados por sistemas vinculados a esses componentes,” diz Qiao. “No geral, a modificabilidade e escalabilidade melhoraram muito com ECS para Unity, e isso tornou nosso pipeline de desenvolvimento muito mais eficiente.”

A equipe também enfrentou um grande desafio em torno da arquitetura do jogo. Ao contrário do software tradicional, a lógica do jogo depende não apenas do código, mas também de onde esse código está localizado. Por exemplo, anexar um script de rotação a uma roda de carro simula movimento, mas aplicar o mesmo script a um skybox pode gerar um ciclo dia-noite. Essa dependência espacial e hierárquica significava que a equipe precisava de uma maneira de arquitetar sistemas não apenas em código, mas também em termos de colocação e hierarquia.

Para resolver isso, Mohamed Hamdy, um arquiteto de software da equipe, elaborou uma abordagem criativa baseada em gráficos para ECS para Unity. Esse método permitiu que a equipe projetasse entidades, componentes, autorizações e sistemas de uma maneira visual e modular, enquanto também definia sua colocação e configuração. Ao fazer isso, pequenos blocos reutilizáveis de código poderiam alcançar propósitos muito diferentes dependendo de onde eram aplicados.

O sistema foi posteriormente estendido para integrar não apenas entidades ECS para Unity, mas também MonoBehaviours, GameObjects, árvores de comportamento e o Gráfico de Comportamento do Unity. Usando uma combinação de diagramas do Lucidchart e planilhas do Excel, a equipe mapeou e validou toda a arquitetura do jogo de maneira clara e eficiente. Olhando para o futuro, eles planejam construir uma ferramenta dedicada do Unity para tornar esse método de arquitetura totalmente visível no Editor, com a capacidade de validá-lo em relação à implementação real.

Usando um sistema de arquitetura híbrido

Após migrar de seu servidor personalizado, a equipe inicialmente adotou uma abordagem completa de física ECS para Unity. Eles escolheram esse método por sua manipulação eficiente de dados e escalabilidade, especialmente no lado do servidor, mas também por certas otimizações de renderização do lado da CPU.

“Uma vantagem chave está em lidar com animações de malha skinning via animação de vértices, que o ECS para Unity pode processar de forma muito mais eficiente do que sistemas tradicionais baseados em ossos”, diz Alwin Joshy, artista técnico do Highstreet Market. “No entanto, em VR, tanto a CPU quanto a GPU estão limitadas, e para aproveitar totalmente a animação baseada em ECS para Unity, primeiro precisávamos reduzir a complexidade da cena para liberar recursos.”

Devido às complexas animações do jogo, seu fluxo de trabalho evoluiu para um sistema híbrido combinando ECS para Unity com MonoBehaviours através do Sistema de Componentes de Entidade (ECS).

Para visualizar múltiplos personagens na tela, eles descarregaram parte do processamento para a GPU. Como estava claro que a CPU ficaria sobrecarregada devido aos aspectos de rede e lógicos do loop do jogo – eles empregaram o Rukhanka Animation System.

“Para a física, construímos tudo no mundo principal da física, sincronizando todas as entidades físicas entre o servidor e o cliente”, explica Sleam. “Foi complexo no início, pois o servidor sincronizava cada entidade física. Então exploramos ter múltiplos mundos físicos e enfrentamos uma escolha entre continuar com um calculador de física local no ECS para Unity ou fazer física local em MonoBehaviour.”

MonoBehaviour permite integração com ferramentas de VR de terceiros como Hurricane e Freehand, que possibilitam interações físicas realistas, como pressionar botões ou garantir que as mãos não atravessem paredes. ECS para Unity, por outro lado, exigiu que a equipe construísse esses sistemas do zero, pois não havia ferramentas de terceiros prontas disponíveis na loja como no MonoBehaviour.

“No final, usamos MonoBehaviour para interações de VR do lado do cliente, como colisões de mãos, para garantir responsividade e imersão,” diz Sleam. “Enquanto isso, a física do lado do servidor lidava com interações críticas de jogabilidade – como atingir um monstro – para validação.”

Essa abordagem híbrida equilibra imersão com segurança, executando a detecção de colisão crítica para a jogabilidade no servidor para evitar trapaças, enquanto gerencia interações locais, menos críticas, no cliente.

Reduzindo chamadas de desenho para desempenho estável em VR

Enquanto ECS para Unity e Rukhanka abrem possibilidades de escala – como suportar milhares de personagens animados – um dos maiores desafios da equipe em VR tem sido a otimização de desempenho, especialmente sob restrições rígidas de CPU/GPU.

“Ao contrário dos jogos tradicionais, VR exige totalmente tanto CPU quanto GPU,” explica Joshy. “Descarregar nem sempre é uma opção, a menos que a cena esteja altamente otimizada.”

Após construir o projeto, eles primeiro realizaram uma verificação preliminar de desempenho usando a ferramenta OVR stat no Meta Quest para identificar áreas pesadas ou quedas de quadros. Em seguida, criaram builds de desenvolvimento e conectaram o Meta Quest ao Unity Profiler para analisar a transferência de dados de CPU-GPU, uso de memória de textura, hierarquia de renderização e tempo de desenho.

“Para melhorar o desempenho, recentemente nos concentramos em reduzir quebras de chamadas de desenho controlando manualmente a renderização. A iluminação foi um grande desafio – enquanto inicialmente assamos lightmaps com compressão estilo toon para reduzir o tamanho, misturar objetos com e sem lightmaps causou problemas de variantes de shader,” diz Joshy. “Para resolver isso, abandonamos completamente os lightmaps e adotamos um shader toon totalmente iluminado pelo ambiente. Isso nos deu um desempenho mais consistente e melhor controle sobre a renderização.”

A equipe também usou holofotes com queda gradual e manteve suas variantes de shader mínimas – apenas um shader cel para clipes opacos e de transparência, e possivelmente grama. Eles controlaram manualmente a ordem de desenho: objetos opacos na camada 1, objetos transparentes na 2 e objetos de clipe na 3. Isso ajudou a reduzir quebras de chamadas de desenho mantendo o agrupamento consistente.

“Para detectar problemas ocultos que dividem chamadas de desenho, confiamos muito no Unity Frame Debugger para verificar o agrupamento e a ordem de desenho,” continua Joshy. “A profilagem de GPU também foi uma das nossas principais ferramentas para otimizar a renderização e reduzir a sobrecarga de chamadas de desenho.”

Equilibrando flexibilidade e desempenho

À medida que a equipe escalou o desenvolvimento, eles encontraram desafios de renderização, especialmente na cena da arena onde ocorre o combate.

“Nosso objetivo é manter 72 fps em dispositivos como o Meta Quest 2, mas mesmo com contagens de triângulos abaixo de 500.000, estamos enfrentando problemas de desempenho,” diz Joshy.

Eles estão usando o SRP Batcher para reduzir as trocas de shader da GPU, mas em VR autônomo, as restrições da GPU são muito mais rigorosas do que no PC. “Descobrimos que até cenas com dois milhões de triângulos renderizam suavemente – se for uma única malha com um único material. Mas os ambientes abertos e verticais do nosso jogo tornam esse tipo de simplificação impraticável,” diz Joshy.

Para melhorar o desempenho, a equipe se concentrou em minimizar chamadas de desenho por:

Fabricação de malha personalizada pela equipe de arte

Agrupando ativos em sub-malhas para equilibrar o agrupamento com a flexibilidade do material

Dividindo o mundo e gerando LOD em nível de chunk em vez de por ativo

Transmitindo chunks usando um ECS para um sistema compatível com Unity

Usar sistemas LOD sozinhos ajudou a reduzir cenas de cerca de dois milhões de triângulos para 500.000.

Essa abordagem sacrificou um pouco de flexibilidade e aumentou a carga de trabalho para os artistas, mas era necessária dadas as limitações de hardware – especialmente em dispositivos como o Meta Quest 2, onde os desenvolvedores não podiam atualizar a GPU.

“No final das contas, minimizar chamadas de desenho de 80 para cinco é nossa maior vitória”, diz Joshy. “Estamos reestruturando conteúdo e fluxos de trabalho em torno disso – mesmo que limite a variedade de materiais – porque é o caminho mais viável para um desempenho estável em VR no hardware atual.”

Escalando de uma maneira inteligente

À medida que a equipe desenvolve seu MMORPG em VR, eles continuam a se concentrar no que consideram ser a consideração mais crítica – escalabilidade, tanto do ponto de vista da arquitetura quanto dos gráficos.

“Se você está mirando em um MMO de grande escala desde o primeiro dia, precisará do ECS para Unity para lidar com altas contagens de entidades e rede concorrente. Se você não tiver uma visão muito detalhada desde o início, escalar incrementalmente também funciona bem”, diz Qiao. “Inicialmente, adotamos uma abordagem de “0 a 100”, otimizando cedo para a escala máxima. Em retrospectiva, construímos infraestrutura demais muito cedo, consumindo recursos que poderiam ter sido direcionados para jogabilidade e conteúdo.”

Do ponto de vista gráfico, a equipe está ciente dos prós e contras do VR. “Malhas orgânicas e suaves consomem recursos computacionais significativos e não têm um bom desempenho em VR. Nosso jogo usa um estilo toon com elementos orgânicos, o que limita nosso orçamento gráfico para outras áreas como design de personagens ou ambientes,” diz Qiao.

No geral, a equipe recomenda optar por ambientes mais limpos, de baixo detalhe e estilo técnico para maximizar o desempenho em seu jogo VR. “Com um design de cena e construção de mundo mais limpos, você poderá ter mais gráficos, e orçamento de recursos e gráficos para outras coisas como design de personagens e design estrutural. É fundamental projetar com o desempenho em mente,” diz Qiao.

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.