Há alguns anos, nossa equipe teve a honra de criar uma “Almaty” móvel. Seguindo as regras "criamos um jogo, não a tecnologia" , criamos um protótipo sobre o que já está no motor. Era o UE 4.9, baseado no modelo físico - PhysX Vehicles, e muita dor (com e sem).

Além disso, nossa equipe criou o plugin de código aberto PsRealVehicle , disponível sob a licença MIT . Este plug-in está ajustado para a física de tanques e veículos com rodas para atiradores de rede altamente carregados, e você pode observar o seu trabalho a qualquer momento em nosso projeto Armored Warfare: Assault .

Nomes, aparências, senhas.

Claramente. Eu vejo. E apenas a negócios.

Repositório de plugins

Documentação principal de configuração

Usado no projeto: Guerra Blindada: Assalto

Um pouco de história, ou de volta às raízes

Começamos a trabalhar no projeto no Unreal Engine 4.9 . Naquela época, a física da máquina "pronta para uso" suportava apenas veículos de quatro rodas e, para os "bancos" de seis rodas (LAV-400, nosso primeiro veículo protótipo de "combate"), tivemos que usar imediatamente o conjunto do motor personalizado. Com a física interna dos tanques, foi ainda pior: os dados sobre como tudo funciona e está configurado, tiveram que ser aos poucos para pescar fora do código.

Seguindo a regra "protótipo" , formamos os seguintes requisitos para nós mesmos:

• A física deve simular o movimento de um tanque (programa mínimo) e veículos com rodas (altamente desejável - esse é um recurso da série de jogos AW).
• Um servidor dedicado deve suportar até 20 máquinas por sessão online e o cliente deve lidar com elas.
• Todas as rodas e esteiras devem seguir irregularidades na superfície, a suspensão deve funcionar e o tanque deve oscilar.
• A configuração física deve ser determinada por valores reais (massa da máquina, potência do motor) e levar a um comportamento realista (a capacidade de superar certos tipos de terreno).
• Quanto menos código técnico escrevermos, melhor: a Epic Games deve fazer o motor, não nós .

Portanto, os requisitos são aproximadamente claros, vamos ao que interessa. Rapidamente, montamos o primeiro protótipo, os tanques foram, os carros dirigiram, mas tivemos dois problemas:

1. Tudo isso estava consumindo muito vigorosamente o processador.
2. A imagem criada do mundo não queria se encaixar na estrutura do comportamento realista de equipamentos pesados. O tanque de trinta toneladas, sob qualquer configuração, não pode subir 15 graus (e esta é uma das opções mais fáceis). Passamos muito tempo mexendo nas configurações de simulação e atrito da paisagem, mas isso levou ao aumento da potência em valores cósmicos (mais de 20 vezes mais que os valores reais e, como resultado, os carros se comportaram de maneira instável e imprevisível) ou a massas de equipamentos de brinquedos (PhysX funciona bem com uma massa de veículo na região de uma tonelada e meia).

Os designers de jogos não estavam entusiasmados. Os programadores choraram, picaram, mas continuaram a comer um cacto (a festa exige uma solução funcional!). O protótipo foi aprovado pela liderança e enviado para criar uma versão alfa (a propósito, o vídeo do protótipo está no Youtube . Mas o tempo passou e as esperanças de um futuro melhor para essa física se tornaram cada vez menos. As configurações não eram suficientes, o comportamento parecia magia negra. “Jogo, não tecnologia” amarrou suas mãos à sua maneira, pelo menos com dúvidas sobre se conseguiríamos.

Armado silenciosamente com a Wikipedia, conhecimento residual da escola e experiência trabalhando em física “em pontões” no Assassin's Creed, em alguns dias criei um protótipo da nova física de tanques, que formava a base do plugin PsRealVehicle. Em uma semana, a prova de conceito foi colocada em pé, as equipes de CTO foram mostradas e protegidas por testes de carga. Os números diziam: ser sua física.

...-... e em produção

O caminho do protótipo para as vendas foi muito mais longo. Se uma semana foi suficiente para uma verificação conceitual, levou um mês e meio para uma versão beta adequada . A criação de uma versão completa de “prod” levou cerca de seis meses, aperfeiçoamento e correção constantes - durante todo o tempo de trabalho no projeto. De muitas maneiras, devemos uma velocidade tão alta ao desenvolvimento e implementação da física no projeto ao designer técnico de jogos Igor, que chegou à nossa equipe na época, cuja meticulosidade nos aspectos do modelo matemático e sua percepção subjetiva pelos jogadores levaram ao resultado atual. Devo admitir que, em um sentido tecnológico, sou um bárbaro : é meu trabalho fazer um machado para derrubar uma floresta. Após o processamento de Igor e o ajuste fino do modelo com outras pessoas, obtivemos uma solução aberta pronta para produção, escalável e altamente otimizada para as necessidades do multiplayer . Há algo para se orgulhar: dos muitos plug-ins disponíveis no mercado (incluindo os PhysX Vehicles), nossa configuração mais rápida e transparente.

A propósito, houve alguns casos engraçados. Enquanto estávamos trabalhando com o veículo PhysX e nossos veículos de rodas extremamente escorregadias não podiam escalar pequenas colinas, ouvi críticas mais de uma vez, dizem eles, nossa equipe não pode configurá-lo para que as pessoas o tenham. A decisão de usar seu plugin foi tomada, inclusive sob a influência desse quadro:

O mais recente desenvolvimento do exército soviético! Um tanque de aranha que pode escalar paredes de 89 graus . Simplesmente não havia nada para cobrir: D

Recursos da nossa solução

Antes de passar a descrever a configuração de tanques e veículos no PsRealVehicle como um exemplo do nosso AW: Assault, quero mencionar algumas coisas que formaram a base do modelo físico usado.

Em primeiro lugar, aderimos claramente ao fato de não estarmos criando um simulador de física de tanques, mas um jogo que é suficientemente arcade. É triste, mas poucas pessoas precisam de um tanque real em seu comportamento - isso é legal apenas nos vídeos de apresentação, e não no controle, e ainda mais no jogo de tiro. O jogador precisa de um tanque que se comporte como um tanque no sentido que outros blockbusters já criaram. E para trabalhar em um dispositivo normal, e não em algum Titan.

O primeiro ponto tem uma consequência: algumas coisas no jogo funcionam muito falsas. Se algo se parece com um tanque e se comporta como um tanque, então é um tanque , e não importa que dentro dele haja uma pequena fragata ou que parte da física esteja configurada com magia de fricção condicional. Uma dessas convenções é controlar a rotação da máquina alterando a velocidade angular, e não pelas forças aplicadas às rodas e à suspensão. Convencionalmente, o tanque gira em X graus por segundo, porque decidimos isso com base em considerações de jogabilidade, e não porque suas trilhas giram a tal velocidade.

A propósito, isso não nega o fato de que "sob o capô" você pode ativar a física de rotação "real", que foi usada nos primeiros protótipos . De uma maneira boa, vale a pena prender o trabalho da suspensão angular, a base da roda e assim por diante. Se começarmos a fazer simulações de corrida, definitivamente voltaremos a isso, mas por enquanto esse é um dos itens da lista de prováveis ​​melhorias.

Estrutura do tanque em AW: assalto

Hierarquia de classes

AAwmVehicle é a principal classe C ++ responsável pela máquina no jogo, dividida em vários componentes (movimento - UPsRealVehicleMovementComponent , sons, VFX, estatísticas, armaduras e outros). O BP_DefaultVehicle herdado dele, que é uma camada adicional para as configurações padrão de todas as máquinas. Todos os outros são planos privados de configurações para cada equipamento no jogo.

Cada máquina é um conjunto desses dados:

• Blueprint, onde todos os ativos externos são registrados, sons, propriedades à la "veículos com rodas / rastreados" são definidos e a física é configurada.
• Um esqueleto de malha e ativos vinculados a ele:
  - Ativo físico (não há mágica, tudo é padrão).
  - Árvore animada.
• Texturas (difusa, mapa normal, RMM).
• Material da instância (casco, esteiras + condição quebrada).
• Um conjunto de malhas de armadura para o sistema de penetração.
• Câmeras, verificadores de nível de água e outras colisões auxiliares.

Animação de tanque

Montar um tanque é um pouco, por mais complexa que seja a árvore de animação. Configurar dezenas desses tanques e mantê-los atualizados ao trocar ossos, malhas etc. é uma quantidade completamente inadequada para o trabalho manual . Felizmente, no nosso caso, estamos falando de um "personagem" bastante padronizado: um tanque pode ser dissecado em entidades e denominado estereotipado. Naturalmente, trata-se de nomear ossos.

Essa abordagem nos permitiu usar essencialmente a mesma árvore de animação, que santos Ctrl + C / Ctrl + V se multiplica por qualquer número de tanques e não requer nenhum suporte, exceto a verificação de controle de qualidade original.

Toda a magia acontece dentro de nós sipy personalizados. Isso permitiu não apenas padronizar a árvore, mas também reduzir bastante o número de cálculos por animação (os nós padrão gostam de conduzir os sistemas de coordenadas para frente e para trás).

Materiais do tanque

Para todas as partes do tanque, é usado um material mestre , personalizado por um par de nós do Switch.

Em seguida, obtemos uma árvore como esta:

  - M_Vehicles
  - - MI_Vehicles_Clean_Body
  - - - MI_Leopard2
  - - - - MI_Leopard2_LOD
  - - MI_Vehicles_Clean_Treads (marcado "Passos")
  - - - MI_Leopard2_Treads
  - - - - MI_Leopard2_Treads_LOD 

O "peso" real aqui são apenas M_Vehicles e MI_Vehicles_Clean_Treads , todas as outras instâncias são apenas conjuntos de parâmetros e consomem um mínimo de memória e espaço em disco.

Em geral, o conjunto de recursos gráficos para o tanque é muito padrão para qualquer jogo.

Trabalho de armadura

Várias vezes ao se comunicar com os colegas, surgiu a pergunta: por que cada peça de armadura tinha uma malha separada e por que não usamos o sistema de colisões Anrilov?

De fato, usamos as colisões habituais de Anrilov, mas apenas para "pegar" a bala . Depois que o projétil está preso no tanque, o dano é calculado poligonalmente em todas as folhas da armadura, levando em consideração as propriedades de cada peça, multicamadas, re-reflexão do projétil, funil cumulativo e outras mecânicas interessantes.

O mais conveniente para este caso é ler os dados de malha "simples", que não retiramos para um servidor dedicado.

Otimização de rede e extra

Alguns pontos "quase tanque" que eu também gostaria de mencionar brevemente.

• Todo o movimento dos tanques é realizado apenas no servidor , os clientes interpolam apenas os valores recebidos. Nenhuma extrapolação é usada. A frequência de sincronização é 10 vezes por segundo .

  
  

• Dependendo do tamanho da tela do tanque, pulamos um ou outro número de tiques da malha do esqueleto, o que inclui um cálculo de todas as animações e algumas interações físicas. Se o tanque não estiver visível na tela, é uma caixa estúpida e não animada flutuando no espaço . A otimização da taxa de atualização interna, apesar de uma boa ideia, possui uma implementação muito grosseira que não fornece um aumento de desempenho tangível. Especialmente quando se trata de telefones celulares.

  
  

• Para todos os tanques, exceto os próprios, todos os componentes, exceto os mais básicos, são cortados no cliente: câmeras, damas e outras coisas que compõem o tanque. De fato, eles não têm nada além de aparência .

  
  

• Um tanque LOD1 dedicado é acionado em um servidor dedicado. Menos picos - menos uso da CPU. Além disso, a atualização da posição das peças de armadura personalizadas ocorre apenas no momento em que o projétil atinge: não faz sentido atualizar o estado das peças a cada marca.

Eu, eu mesmo e tanques

No Pushkin Studio, acreditamos que a troca de experiências de desenvolvimento é muito importante, inclusive para o crescimento do nível profissional dentro da equipe. Os projetos de código aberto são um componente significativo dessa abordagem e estou feliz por poder apresentar à comunidade tecnologias como PsRealVehicle .

Na minha opinião, é muito importante que nós próprios usemos todos os plugins e utilitários publicados por nós diariamente. Afinal, o caminho claramente demonstrado pela Epic Games é que o sucesso da boa tecnologia é usá-la pelos próprios desenvolvedores em seus próprios produtos. Agora já estamos trabalhando na versão UE 4.20 , nosso plugin foi até aqui e não vamos parar!