Como resolver problemas técnicos e de desempenho no Laser Matrix

Marius Thorvaldsen, Martin Sivertsen e Sindre Askim Gronvoll fundaram a Breach em 2016 para criar jogos imersivos, experiências XR e simulações 3D. Durante os últimos nove anos, o estúdio contratado forneceu soluções de XR e desenvolveu seus próprios jogos. Em 2024, eles inventaram ideias e começaram a criar protótipos enquanto procuravam um novo projeto interno. Um conceito de jogo logo passou para a produção e se tornou a Laser Matrix.

O título é um jogo de ação de quebra-cabeça de realidade mista em que os desafios de fitness, diversão e futurismo colidem. Os jogadores podem resolver quebra-cabeças baseadas em luz, evitar lasers de deslocamento e desbloquear níveis usando agilidade e inteligência.

Sentamos-nos com Andreas Weibye, diretor de engenharia na Breach, e Jonathan Jørgensen, um dos desenvolvedores de jogos, para discutir o desenvolvimento do jogo para Meta Quest e Android XR, e como eles superaram os desafios técnicos e de desempenho.

O que é Laser Matrix?

Andreas: Laser Matrix é um jogo de quebra-cabeça de ação de movimento em VR. É muito arcade e pode transformar sua sala de estar em um labirinto perigoso que você tem que mover com rapidez e habilidade.

Como funcionou o processo de implementação para Meta Quest e Android XR?

Andreas: Desde o início do projeto, não implementamos Meta Quest e Android XR simultaneamente. O protótipo começou apenas para o Meta Quest. Trabalhamos intensamente com a plataforma, então a implementamos rapidamente. O Android XR também não existia quando iniciamos esse protótipo, então acabamos por levar durante o processo de desenvolvimento.

Jonathan: Começamos com a ferramenta “building block” da Meta para realizar prototipagem rápida. Ele tornou a validação do conceito mais conveniente. Finalmente percebemos que queríamos buscar XR entre plataformas e decidimos estruturar o jogo de maneira mais agnóstica à plataforma. A jogabilidade principal não depende de recursos específicos para cada plataforma, por isso foi uma transição fácil entre plataformas.

Quais foram as etapas tomadas ao implementar o rastreamento de mão no OpenXR?

Jonathan: Nós lemos dados de rastreamento em tempo real do tempo de execução do OpenXR. Depois, os dados são processados por meio de camadas de abstração nas quais os dados brutos são convertidos em posições e rotações que são então aplicados a malhas de mão. Essas malhas de mão são então interfaces com os sistemas de interação integrados em Unity, que fornecem utilitários para coisas comuns, como tocar em algo com o dedo. Depois, finalmente, nossas próprias camadas de jogabilidade acima disso.

Trata-se da abstração multicamada desses dados brutos. Muitos jogos XR geralmente têm necessidades semelhantes, por isso tentamos usar as soluções existentes estáveis o máximo possível e amarrá-los bem juntos. Para o Laser Matrix, não há muitos aspectos não padrão para o rastreamento de mão.

Quais desafios técnicos a equipe encontrou?

Andreas: É uma configuração OpenXR bastante intuitiva quando se trata da cena e dos componentes usados. Tivemos que trabalhar com problemas relacionados aos momentos em que as mãos perderam ou ganharam rastreamento e gerariam em um local diferente nesse quadro. Em algum momento, os jogadores começaram a perder a rastreabilidade das mãos, o que fez com que perdessem vidas.

Jonathan: Criar em torno do rastreamento de mão foi um dos maiores desafios. Os diferentes pontos de contato na mão causaram alguns problemas. É mais direto para interações normais e em ritmo lento de IU, como pressionar um botão. No entanto, no Laser Matrix, você está constantemente movendo seu corpo e cabeça, o que pode reduzir a precisão do rastreamento de mão baseado em câmera.

Andreas: Para IU fora da jogabilidade, implementamos botões que você precisa tocar com os dedos, em vez de usar raycasting. Em nossa experiência, a transmissão com rastreamento de mão não é precisa o suficiente para ter uma ótima experiência de jogo, então isso ajudou.

Jonathan: Para jogos de tela plana, os desenvolvedores podem limitar o uso de entradas, como mouse, teclado e controles. XR é diferente, porque um jogo nunca pode realmente parar suas mãos físicas. Por exemplo, os botões no menu Laser Matrix são bastante planos, e você pode apertar a mão até o botão. Essa é uma interação para a qual você não precisa necessariamente projetar, e não está claro o que realmente deve acontecer. É uma pressão de botão válida? No geral, há algumas implicações interessantes que surgem ao traduzir padrões mais tradicionais de interface de usuário para XR.

Quais problemas relacionados ao desempenho a equipe encontrou?

Andreas: Nosso principal problema de desempenho está no lado gráfico. Desde o início, se trata de encontrar o equilíbrio com overdrawing de transparência. É um dos maiores desafios com o design atual do jogo, pois se você usasse apenas esboços para essas caixas, você poderia ver onde elas estão ao olhar para cima ou para baixo e compará-las com algo. Mas quando você olha direito na frente e tenta entender sua distância de uma parede ou quão longe você pode estender sua mão sem tocar, isso fica mais difícil.

Como queremos que o usuário possa ver todo o labirinto ao mesmo tempo e tomar decisões estratégicas de localização, precisamos de uma solução de transparência ou uma alternativa, ambas exigindo GPU.

Jonathan: Algumas das nossas soluções afetaram os visuais finais do jogo. Por exemplo, mudamos a fronteira amarela externa da área de jogo. Tinha uma tonalidade amarela transparente que cobria toda a superfície da parede, mas reduzimos para apenas as bordas, com um gradiente desaparecendo para totalmente transparente. Como a fronteira do jogo é visível a qualquer momento ao jogar, isso reduziu consistentemente a quantidade de chamadas de overdraw, que foi uma das principais contribuições para o nosso tempo de quadros.

Também analisamos os cubos vermelhos a laser que o jogador está tentando evitar ao se movimentar no jogo. Eles têm um padrão de grade quadrado em sua superfície. Podemos usar a mesma abordagem do cubo de fronteira amarelo, tentando reduzir o overdraw novamente. Como apenas as bordas das células da grade são renderizadas totalmente, fizemos as células maiores, resultando em mais da superfície sendo totalmente transparente em média.

Também houve alguns problemas de desempenho relacionados ao carregamento. Um grande pico ocorreu toda vez que o nível começou. No início, assumimos que estava relacionado ao carregamento de níveis no geral. Carregar um nível Laser Matrix significa que muitos elementos diferentes precisam ser gerados. No entanto, o culpado foi especificamente a música. Por meio de perfis, descobrimos que o sistema recarregou o áudio em cada nível. Configuramos para pré-carregar a música com o aplicativo, o que tornou o pico invisível.

Andreas: Alguns dos nossos problemas de desempenho surgiram porque transformamos um protótipo em um jogo de produção. Devíamos ter reescrito o sistema.

Quais ferramentas e recursos do Unity foram fundamentais durante a compilação?

Andreas: O benefício do Unity é que nos permite criar um asset e um código e fazer com que funcionem em várias plataformas desde o início.

O VFX Graph foi ótimo pois permitiu que o proprietário do nosso produto, que não é artisticamente inclinado, esboçasse o que imaginava nos efeitos visuais. De lá, nosso artista técnico e desenvolvedor o aperfeiçoou.

Jonathan: Shader Graph foi uma ferramenta muito valiosa para a criação do jogo. A maioria dos elementos 3D do jogo são shaders puros. Além de alguns cubos, mãos e botões, há muito poucos modelos 3D reais neste jogo.

O XR Device Simulator também foi usado muito. Quando você trabalha em XR, os testes podem ser bastante físicos e fiscais a longo prazo. Entre todas as etapas — em pé, usando o headset, se movendo e muito mais —, as horas realmente somam. Ao configurar o simulador e usar entradas de mouse para estimular interações, economizamos muito tempo e frustração.

Andreas: Como eu tinha o XR Device Simulator disponível desde o início, eu queria desenvolver novos recursos de maneira que pudesse testá-los com mais facilidade de forma isolada. Isso motivou-me a escrever sistemas mais modulares e testáveis desde o início, o que também melhorou a qualidade do nosso código.

Jonathan: O Unity Profiler também foi essencial para nos ajudar a detectar os picos de desempenho. Por exemplo, com o problema de carregamento de áudio mencionado, o Profiler nos ajudou a identificar o pico e as chamadas acionadas no momento exato. Esse tipo de informação geralmente oferece algumas dicas claras sobre onde começar ao implementar uma solução.

Quais novos recursos ou atualizações no Unity 6 foram mais benéficas?

Jonathan: Nós desenvolvemos para diversos alvos e em diferentes contextos. Ao avançar entre plataformas, precisamos que as builds tenham diferentes configurações para recursos e serviços específicos da plataforma. Portanto, a capacidade de ter perfis de build no Unity 6 nos permitiu personalizar as builds para essas diferentes plataformas. Fazer isso manualmente seria tedioso e propenso a erros.

Quais foram os principais padrões de desempenho?

Jonathan: Quando identificamos os problemas de desempenho, que é um grande problema em XR especificamente devido à doença de movimento, medimos o FPS médio e buscamos quedas de quadros. Há alvos bem definidos para o que é confortável ou não.

Ao ajustar os limites nos diferentes shaders de cubo , ganhamos cerca de 10% em FPS. Nós traçamos o perfil do jogo em um ambiente de teste, onde desenhamos a quantidade máxima de cubos para o jogo. Isso nos forneceu um contexto muito fixo e confiável para testes.

Andreas: Para desempenho, nossos limites são 72 FPS no Meta Quest 2 e 90 FPS no Meta Quest 3. Estamos na meta para a taxa de quadros média, mas podemos produzir situações em que o usuário obtém um resultado menor. São casos muito específicos em que você pode acabar no pior local possível.

Jonathan: Em mais de um projeto e nível de equipe, nosso tempo de iteração ficou muito mais eficiente nos últimos meses. Como empresa, preparamos nosso processo de garantia de qualidade e o vinculamos à nossa pilha de automação, e agora nosso ciclo de feedback e correção é bem rápido. Podemos resolver problemas rapidamente o suficiente para que um atraso de tarefas não acumule ou saia de controle.

Havia alguma coisa que a equipe desejava ter feito de forma diferente durante o desenvolvimento?

Andreas: Deveríamos ter começado a usar o OpenXR um pouco antes. No início do projeto, planejamos usar o recurso de marcação de sala da Meta para definir o formato e o tamanho da área de jogo. Embora funcionasse, não nos deu a funcionalidade de jogabilidade que buscávamos sem abrir desafios de design para os quais ainda não tínhamos ótimas soluções. Nós percebemos isso durante a discussão sobre a digitalização da sala. Devíamos ter descontinuado esse sistema antes porque passamos muito tempo tentando resolvê-lo. Além disso, olhando para trás, uma vez que o código protótipo evoluiu para um código de produção, reconhecer que o sistema não atendia mais ao projeto teria economizado tempo.

Para ler mais sobre projetos Made with Unity, acesse a página Recursos.