Como a RUST LTD construiu a simulação de armas de fogo profunda para Hot Dogs, Horseshoes & Hand Grenades 2

Criar Hot Dogs, Horseshoes & Hand Grenades 2 (H3VR2), um sandbox de armas de fogo de física VR autônomo e roguelike de extração, significou começar do zero em vez de carregar uma década de dívida técnica e de design para uma sequência.

Em vez de portar o jogo original, a RUST LTD começou com um projeto Unity novo e passou quase seis meses focada em arquitetura e ferramentas antes de passar para a produção completa de conteúdo.

Essa fundação suporta tudo, desde componentes de armas de fogo e balística até percepção do inimigo, renderização, áudio e ferramentas de Editor. Dados do mundo real alimentam muitos desses sistemas, permitindo que diferenças mecânicas surjam através da simulação em vez de a equipe criá-las como valores de jogabilidade isolados.

Conversamos com Luke Noonan, cofundador e chefe de produção da RUST LTD, e Anton Hand, cofundador e diretor de jogos, sobre a reconstrução do jogo do zero, o aumento da complexidade da simulação, o equilíbrio entre fidelidade física e desempenho em VR, e a construção das ferramentas necessárias para gerenciar centenas de armas de fogo mecanicamente distintas.

O que mudou para a sequência – em escopo e em ambição?

Luke Noonan: Uma das grandes coisas que queríamos fazer com o novo título era corrigir muita da dívida técnica e de design que havia se acumulado.

Nós fizemos uma reescrita do zero para H3VR2. Este era um projeto Unity novo quando começamos. Analisamos partes do jogo existente e tiramos aquela experiência disso, mas isto não foi um *port*. Foi uma reconstrução.

AH: Tecnicamente, construímos este projeto quase exatamente o oposto da maneira como construímos H3VR.

Com H3VR2, passamos quase seis meses em arquitetura e ferramentas puras antes de nos preocuparmos com qualquer coisa que se aproximasse da produção de conteúdo completa. Nós sabíamos como construir as armas, já que já tínhamos feito isso por 10 anos. Precisávamos de sistemas que pudessem escalar para um projeto de adições de conteúdo de cinco ou dez anos.

LN: Nós também sabíamos desde o início que este seria um time muito maior. H3VR foi em grande parte Anton com outras pessoas apoiando diferentes partes da produção. Com H3VR2, somos mais de 20 pessoas.

Isso exigiu melhores operações de desenvolvimento desde o início: boa higiene de Version Control, Build Automation, ferramentas de Editor personalizadas e processos de produção que funcionam para uma equipe distribuída em cinco fusos horários diferentes.

O que envolve o nível de simulação por baixo dos panos, e o que você se propôs a acertar?

AH: Nosso processo começa com uma quantidade obsessiva de pesquisa clássica. Começamos encontrando material de referência real, incluindo livros e documentação técnica reais.

Do ponto de vista de uma simulação, nosso princípio básico é construir um modelo onde possamos alimentar dados reais e fazer com que o modelo converja em algo entre o realismo coloquial recebido e algo que funcione para o jogo.

Isso se torna importante no momento em que você constrói uma simulação realmente complexa com um grande número de entradas. Eventualmente teremos centenas de armas, centenas de cartuchos e dezenas de materiais.

Com H3VR2, nós conseguimos ir muito mais longe. Podemos perguntar se podemos alimentar constantes de mola reais em um sistema e descobrir que, sim, podemos. Podemos incorporar dimensões do mundo real e relações mecânicas no sistema operacional da arma de fogo? Sim.

LN: Nós pagamos um custo inicial por essa abordagem sistemática, mas obtemos muitos benefícios posteriormente. Se quisermos adicionar um novo tipo de cartucho, por exemplo, podemos analisar propriedades como massa do projétil e as características do cartucho, em vez de inventar um número mágico de jogabilidade.

Onde o NVIDIA PhysX se encaixa na pilha e onde você decidiu que precisava de sistemas personalizados em vez de, ou ao lado, do motor de física embutido?

AH: Usamos uma quantidade bastante contida da complexidade disponível através NVIDIA PhysX.

Motores de física de jogos não lidam realmente com componentes minúsculos dentro de um quadro de referência local enquanto o jogador carrega o objeto pai e potencialmente o joga pela sala. Então nós temos muitas simulações internas muito personalizadas para componentes de armas de fogo que efetivamente existem em seus próprios universos. Nós gerenciamos a tradução de forças e impulsos entre esses sistemas internos e o espaço maior do jogo.

No nível do espaço do jogo, usamos a física de forma muito mais direta. Os Sosigs, nossos personagens de salsicha, são provavelmente nosso maior uso da física. Eles são efetivamente bonecos de física perpétuos.

LN: Na escala muito pequena, para simulação de componentes dentro dos canos, construímos sistemas personalizados. Na outra ponta, para balística e uma parte significativa dos sistemas de agentes, construímos outra camada usando ECS para Unity e Burst.

Como você arquitetou a simulação de balística usando ECS para Unity?

LN: Sabíamos que tínhamos que ter muitas armas disparando, que armas podem disparar muito rápido, e que todos esses tiroteios poderiam estar acontecendo ao mesmo tempo. Isso coloca muita pressão de desempenho na simulação, e tivemos que fazer concessões em torno disso no primeiro jogo.

Usar ECS para Unity e Burst nos permite gerar enormes quantidades de Entities balísticas para armas de fogo, explosões e outros sistemas.

Ajudou-nos a aumentar a fidelidade em vez de simplesmente atingir o nosso alvo original. Podemos fazer amostragem de sub-passos menores para colisão mais precisa, modelar a resistência do ar de forma mais precisa e fazer um manuseio de maior fidelidade de penetração e projéteis movendo-se para dentro e para fora de diferentes materiais.

Quais foram os maiores desafios de desempenho que uma simulação tão profunda criou?

LN: Grande parte do período inicial de desenvolvimento foi sobre testar sistematicamente essas áreas. O que é barato? O que é caro? O que esta nova plataforma pode ou não fazer? Uma vez que tínhamos esses limites, ficou muito mais fácil manter o tempo de quadro alinhado.

AH: Desenvolvemos um entendimento muito apurado do que é rápido e do que não é durante H3VR. É uma das razões pelas quais ficamos fora do VR autônomo até o Quest 3.

No lado da CPU, isso significava construir os sistemas de simulação central em torno de ECS e Burst. No lado da renderização, sabíamos que modelos 3D sofisticados de armas iriam consumir uma parte significativa do orçamento de quadros, então todo o resto – contagem total de polígonos, memória de textura, largura de banda, estrutura do ambiente – tinha que permanecer muito enxuto.

Nós não estávamos dispostos a dizimar a coisa pela qual as pessoas estão vindo ao jogo. Então nós projetamos os ambientes, a densidade de interação, a tipologia de conteúdo e a estrutura de nível em torno dessas restrições desde o início.

A otimização não foi uma trilha paralela que veio depois de um conjunto de decisões de design inflexíveis. Fez parte do processo de gestação verticalmente por todo o projeto.

LN: A instalação usa níveis montados proceduralmente que construímos a partir de kits modulares, então também validamos muito cedo como o modelo de iluminação funcionaria. Analisamos como poderíamos usar sondas de luz, sondas de reflexão e o restante da pilha de iluminação, e então seguimos essas decisões para trás até a própria direção de arte.

Como a atualização para Unity 6.3 beneficiou o projeto?

AH: Mudar para o Unity 6.3 para H3VR2 é basicamente um salto de uma década em comparação com o H3VR.

Existem as melhorias óbvias na qualidade de vida, como nested prefabs, mas algumas das coisas mais impactantes para nós foram o desempenho do SRP Batcher, as melhorias na compilação de shaders e o pós-processamento em tiles.

A compilação de shaders ajudou a tornar esses grandes uber shaders menores em disco. O pós-processamento no tile foi especialmente importante para nossa abordagem visual. Eu não quero enviar um jogo sem mapeamento de tons, mas originalmente escrevemos nosso passe de mapeamento de tons HDR diretamente em nossos shaders porque ter um blit de pós-efeito separado não era performático o suficiente no hardware VR autônomo. Com pós-processamento no local, conseguimos remover esse código.

LN: A estabilidade e confiabilidade geral da versão atual do Unity também foram genuinamente importantes. Estamos empurrando muitas ferramentas personalizadas através do Editor, e esse processo tem sido muito tranquilo.

Cada arma no jogo tem seu próprio comportamento mecânico. Como você autoriza e mantém isso orientado por dados, e como você mantém uma lista daquele tamanho?

AH: Manter a manutenibilidade é uma luta constante. O volume puro de Documentos Google que temos para tudo é bem louco, embora os próprios ativos acabem se tornando a única fonte de verdade sobre como configuramos essas armas de fogo.

Volta a ter ferramentas de Inspetor muito poderosas. Essas ferramentas não são simplesmente para inserir informações. Temos ferramentas de Editor centradas em cálculos, ferramentas de validação e ferramentas de análise que construímos especificamente para armas de fogo.

A simulação é profunda o suficiente para que eu descreva muito do trabalho como sendo mais próximo de marcenaria de armas de fogo na vida real. Estamos inserindo coisas como constantes de mola e massas de componentes. Cartuchos têm dados de curva de pressão e informações descrevendo os diferentes componentes do cartucho.

Se esses valores estiverem errados, a arma de fogo na simulação não cicla corretamente.

Como o Odin Inspector e a Asset Store ajudaram sua equipe a gerenciar a complexidade de desenvolver e manter o jogo?

AH: Se eu tivesse que identificar a proposta de valor central da Unity para um jogo como o nosso, seria a extensibilidade do Editor.

Nós usamos o Odin Inspector extensivamente e não acho que este projeto seria viável da mesma forma sem ele.

Todos que escreveram código para o jogo escreveram inspetores personalizados. Odin minimiza dramaticamente a quantidade de trabalho envolvido porque lhe dá um atalho incrivelmente poderoso para construir essas ferramentas.

Isso é especialmente importante quando se lida com algo tão ontologicamente e taxonomicamente complexo quanto uma arma de fogo. Para qualquer arma individual, talvez 95% ou 98% de tudo o que o sistema base poderia configurar teoricamente é irrelevante para aquele objeto em particular. Odin nos permite suprimir essas opções irrelevantes.

Technie Collider Creator 2 da Triangular Pixels na Asset Store também tem sido um divisor de águas. Economizou centenas, senão milhares, de horas da equipe ao longo da produção.

Para um jogo de VR com foco em física, a criação de corpos de física requer uma combinação desajeitada de trabalho manual e automação. Uma solução totalmente automatizada geralmente não é apropriada. Você quer usar primitivas de física o máximo possível e depois malhas convexas apenas onde você realmente precisa.

Qual é a sua principal dica para desenvolvedores que procuram criar um jogo de simulação tecnicamente complexo?

AH: Valide o que você precisa cedo o suficiente. Há uma diferença muito grande entre construir sistemas de simulação porque você gosta do processo de construir sistemas de simulação e construir sistemas de simulação que o seu jogo precisa.

Se eu olhar para trás em H3VR, há trabalho de simulação que escrevi que não era legível para o jogador. O usuário final não experimentou realmente sua presença. Não facilitou minha vida, em alguns casos tornou minha vida mais difícil como desenvolvedor e designer, e não resultou em jogabilidade mais gratificante.

Esse é o risco com qualquer jogo de simulação complexo. Você pode acabar fazendo um trabalho que não beneficia ninguém, exceto talvez sua própria experiência ao fazê-lo, enquanto o afasta do objetivo macro do projeto.

LN: Eu também apontaria para as pessoas. Nós nos beneficiamos imensamente ao encontrar os especialistas certos para a equipe: um especialista sólido que também é profundamente conhecedor de armas de fogo, artistas de armas que entendem o assunto e as necessidades de VR, e engenheiros que estão interessados nos tipos de sistemas que estamos construindo.

Hot Dogs, Horseshoes & Hand Grenades 2 pode ser pré-encomendado agora para o Quest 3. A versão Steam pode ser adicionada à lista de desejos agora antes do seu lançamento em 2027. Confira mais histórias de desenvolvedores no Blog da Unity e no Unity Resource Hub.