A física se tornou parte integrante de qualquer jogo moderno. Seja uma simples simulação de tecido ou uma física de tráfego completa. Jogos para celular não são exceção. No entanto, ao configurar a física para eles, é necessário revisar as limitações associadas ao desempenho relativamente ruim dos dispositivos de geração antiga suportados.
Games Roman Tersky contou como sua equipe integrou a física na jogabilidade do jogo de luta móvel Shadow Fight 3, que técnicas foram usadas para otimização e como ele reescreveu a física dos personagens do zero para alcançar seu determinismo completo no PVP síncrono.
Física do Estado Sólido
O equipamento dos personagens de Shadow Fight 3 tem muitos elementos sujeitos a simulação física, o que adiciona dinâmica ao que está acontecendo na tela. Uma das principais dificuldades que encontramos ao estabelecer a física para esses elementos é o fato de que os ossos aos quais eles são esfolados estão dentro da hierarquia do esqueleto do próprio personagem. Ao se moverem, eles repetem a transformação dos ossos dos pais e não recebem um impulso fisicamente realista.
Detector de Ossos
A solução mais fácil foi destacar o osso. Após inicializar todos os elementos do equipamento usando um script, removemos os ossos dos elementos fisicamente ativos da hierarquia do esqueleto do personagem e, usando o componente
Articulação do
personagem , criamos uma conexão com o osso pai.
No entanto, nos deparamos com um pequeno erro decorrente do rebaixamento do fps: nesse caso, um osso sujeito a simulação física, com um pequeno atraso, “alcança” o osso com o qual o Joint está conectado. Como regra, esse erro é tão insignificante que pode ser negligenciado. Para outros casos, uma solução alternativa foi aplicada.
Impulso falso
Considere esta solução usando o exemplo de um capacete para saqueadores, cuja crista espartana está sujeita a simulação física. Dividimos o pente em 5 partes, cada uma delas com a pele de ossos diferentes. Nas configurações de junção desses ossos, eles estabelecem limites de rotação ao longo do eixo desejado e o parâmetro
Twist Limit Spring , que é responsável pelo efeito da mola.
Para uma simulação fisicamente realista, os ossos da crista foram retirados da hierarquia de caracteres, no entanto, em caso de queda de fps, por exemplo, em um dispositivo fraco, a malha era esticada devido à "recuperação" dos ossos.
Portanto, decidimos deixar os ossos da crista dentro da hierarquia dos personagens e aumentar o dinamismo deles, dando-lhes um impulso falso. Para fazer isso, precisávamos em cada animação (exceto na posição de combate) para determinar o momento em que aplicar o impulso, bem como sua direção.
Pode-se ler o número de quadros na animação atual, subtrair 15-20 quadros desse valor e aplicar um impulso após a diferença recebida. No entanto, conseguimos evitar aritmética desnecessária vinculando o momento do pulso ao final do
intervalo ininterrupto da animação.
Cada animação (novamente, exceto a posição de combate) tem um período pré-configurado durante o qual o jogador não pode interrompê-lo. Após esse período ou no momento de receber o impacto, o intervalo
ininterrupto encerra sua ação e, neste momento, nosso impulso é acionado. Tudo o que era necessário era configurar exceções para várias animações.
Assim, o impulso é acionado vários quadros antes do final de cada animação, conforme necessário. No momento da inicialização do pulso, lemos as coordenadas nas quais o osso estava no quadro anterior e atual, recebendo seu vetor de movimento. Nesse eixo, nosso impulso é aplicado.
Itens de equipamento
Para otimizar, tentamos usar os coletores o menos possível ao simular a física de vários elementos do equipamento dos personagens. Na maioria dos casos, conseguimos fazer isso manipulando apenas as restrições ao longo dos eixos nas configurações conjuntas dos ossos para os quais a simulação é realizada.
Em alguns casos (por exemplo, com placas de metal), o uso de colisores é inevitável. No entanto, o principal ônus não é a presença dos colisores, mas o cálculo de suas colisões. O ajuste fino da
matriz de colisão de camadas nas
configurações do projeto ajuda a minimizar essa carga. Para esses elementos, usamos duas camadas separadas que colidem apenas entre si, evitando assim o erro de cálculo de colisões com colisores de outras camadas (armas, pisos, paredes etc.)
Clone físico
Shadow Fight 3 tem vários tipos de armas para as quais a simulação física é usada fora das animações de ataque. No momento, esta é uma faca em uma corrente, kusarigama, nunchaku e mangual. Pelas razões descritas acima, decidimos remover os ossos da arma da hierarquia dos personagens fora das animações atacantes e devolvê-los quando a simulação física não for necessária. Ao manipular o parâmetro
Is Kinematic no componente
Rigidbody dos ossos, dependendo da situação,
ativamos e desativamos a física para eles.
No entanto, ao usar Kusarigama e uma faca na corrente, encontramos uma carga aumentada em dispositivos fracos e diminuímos os fps. O problema surgiu exatamente quando os ossos retornaram à hierarquia do personagem e a simulação física foi desativada para eles. Isso se deve ao fato de que a alteração do osso pai se transforma na hierarquia do esqueleto sobrecarrega o mecanismo de física de cada osso filha no qual existe um componente
Corpo rígido , mesmo se o parâmetro
Is Kinematic estiver ativo. E quanto maior a hierarquia, maior a carga.
A solução foi criar um clone físico. Considere isso com um exemplo de uma faca em uma corrente.
Durante o carregamento da batalha, dois esqueletos são inicializados para ele: o principal, localizado dentro da hierarquia do personagem, e seu clone físico. Não há componente de
corpo rígido nos ossos do esqueleto principal; apenas as trilhas de animação afetam sua transformação. Os ossos do segundo possuem conexões ajustadas (juntas) e um componente de
corpo rígido com o parâmetro ativo é cinemático.
Enquanto a transformação dos ossos do esqueleto principal é afetada pela faixa de animação, por exemplo, durante um ataque, o parâmetro
Is Kinematic no componente
Rigidbody dos ossos do clone físico permanece ativo. Ossos não são transformados e não estão sujeitos a simulação física. Durante o último quadro da animação, as transformações ósseas dos dois esqueletos são sincronizadas. Um clone físico lê a posição e a rotação dos ossos do esqueleto principal e define exatamente os mesmos parâmetros. O Cinemático é então desativado e os ossos do clone físico são simulados. Além disso, até o início da próxima animação atacante, já o esqueleto principal, cada quadro lê as transformações dos ossos do clone físico, que naquele momento se movem na física, e define esses parâmetros para seus ossos. Essa abordagem reduziu significativamente a carga no mecanismo de física e melhorou o desempenho em dispositivos fracos.
Simulação de tecidos
Ao configurar a simulação de tecidos como parte do desempenho de dispositivos móveis, a principal limitação é o uso de colisões de tecidos com colisores. Uma alternativa mais barata é ajustar a
penetração de superfície para construções de tecido. Como em nosso jogo existem muitas animações e várias poses dos personagens, uma lista das mais "perigosas" foi compilada, na qual todos os tecidos foram verificados quanto à penetração em outras partes do corpo.
Também usamos uma simulação de tecido para criar o efeito da chama FX nas armas e na cabeça do chefe Shadow Mind. Nas configurações de
Cloth para esses elementos, desligamos a influência da gravidade e ajustamos os valores de aceleração ao longo do eixo Y: constante, para que a chama se movesse para cima e aleatoriamente, para o efeito de vibração. Para que, ao se mover, não ocorra uma distorção acentuada da geometria, definimos o valor aumentado da resistência (
Amortecimento ). Assim, conseguimos um preço bastante realista e barato em termos de efeito de chama de desempenho.
Física determinística para PvP síncrono
No momento da morte e em certas situações, ao ser atingido por personagens no Shadow Fight 3, uma simulação de física é ativada. Durante muito tempo, a física de estado sólido das ações da Unity foi usada para isso. No entanto, ao introduzir o PVP síncrono no projeto, ele teve que ser abandonado em favor de seu próprio desenvolvimento.
O PVP síncrono implica a mesma simulação de um jogo em dois clientes. Não há problemas com a animação, pois tudo foi calculado antecipadamente, enquanto certos problemas surgem com a física.
O fato é que os cálculos de ponto flutuante, usados na física do Unity, funcionam de maneira diferente em processadores de diferentes fabricantes. Nesse sentido, durante o jogo, erros na posição dos personagens se acumulam - em um cliente, o personagem está localizado de maneira diferente do outro. E se fora da física essa discrepância pode ser facilmente corrigida sincronizando periodicamente a posição com base em indicadores de um dos clientes, então no momento da inicialização da física, devido ao erro inicial da posição, a simulação física se desenvolve diferentemente em dois clientes.
Como resultado, o personagem está significativamente em lugares e posições diferentes. Após essa discrepância, mais cedo ou mais tarde surgirá uma situação na qual os ataques serão gravados em um cliente e não no outro.
A solução mais simples, à primeira vista, é assumir a posição do personagem em um cliente e transferi-lo para outro enquanto os sincroniza durante uma simulação física. Mas o regdoll do personagem é uma longa hierarquia de ossos com um grande número de sólidos independentes separados (membros, cabeça), para a sincronização correta da posição da qual você precisa transferir uma grande quantidade de dados em um curto período de tempo. Essa opção acabou sendo muito "cara", por isso decidimos escrever nossa própria física, o que seria determinístico. Para que possamos ter certeza de que em qualquer cliente os estados físicos dos caracteres coincidem, independentemente do processador em que os cálculos são feitos.
Então, qual é o nosso regdoll? O corpo é constituído por nós, que são pontos materiais, sem orientação, mas existe uma posição e uma massa e, entre eles, são realizados elos de rigidez ajustável. Um grupo desses nós é anexado a cada osso dentro do esqueleto do personagem. Essa arquitetura implica a ausência de colisões e limitações internas nas juntas, e colisões e atritos externos são implementados no nível do nó. Quando os nós se movem no espaço, a gravidade, forças externas e inércia são levadas em consideração.
Entre os nós, existem dois tipos de conexões:
costelas rígidas (azul) e
músculos elásticos (vermelho). As costelas desempenham o papel de ossos, forçando os nós a uma certa distância um do outro e impedindo que eles se espalhem em direções diferentes. Músculos de qualquer posição inicial formam uma certa pose nos nós, juntando-os se a distância entre eles for maior que o valor-alvo e afastando-os se for menor.
Dê uma olhada "por baixo do capô" e veja como funciona. Primeiro, permitimos que os nós se movam livremente, depois ajustamos iterativamente os links para que recuperem às características de destino. Para uma iteração do ajuste muscular, são necessárias duas iterações do ajuste da costela. Ao tornar as costelas mais rígidas, podemos ter certeza de que as conexões das costelas não quebrarão depois que os músculos forem expostos aos nós.
Como resultado, quanto mais fortes os nós conseguem mudar no estágio de livre circulação, mais custos computacionais devem ser investidos para restaurar as costelas e os músculos. Para minimizar esses custos e o risco de interrupção estrutural, decidimos dividir o processo iterativo em várias etapas. Ou seja, em um quadro várias vezes ocorre a livre circulação de nós e sua correção. Em uma etapa, os nós conseguem se mover muito menos e ajustá-los se torna muito mais fácil. Assim, economizamos seriamente o número de iterações necessárias para ajustar as costelas e os músculos.
O conjunto de comprimentos musculares determina a pose do alvo, que o personagem procura em qualquer posição após a transição para uma simulação física. Para evitar transições muito abruptas e interrupções estruturais, adicionamos a posição de interpolação. No momento em que entram na física, pegamos a pose atual do personagem e o tornamos o alvo, e depois por cinquenta quadros, interpolamos para a pose pré-definida, obtendo uma transição suave.
O principal problema que encontramos ao usar nossa física é a torção periódica dos membros, principalmente dos braços. Isso se deve ao fato de que, no momento da transição para a física, o personagem pode estar em uma posição distante do alvo, à qual seus músculos se contraem. Para minimizar e, no futuro, evitar completamente tais situações, várias medidas foram aplicadas. Primeiro de tudo, montamos várias poses de alvo nas quais os músculos podem apertar os nós. No momento em que entramos na física, tomamos a pose atual, observamos qual das metas pré-definidas é a mais próxima e apertamos os nós.
Inicialmente, ao passar para a física, os músculos empurravam rigidamente os nós, trazendo-os para a posição desejada. Freqüentemente, a nitidez dessa repulsão também levou ao fato de que as extremidades se retorciam fortemente. Adicionamos um aumento suave da força muscular, o que melhorou bastante a situação. Durante os dois primeiros quadros após o início da simulação física, a força muscular permanece máxima para estabilizar os nós após aplicar um impulso neles. Então os músculos relaxam, sua força se torna 55% e, em mais de 120 quadros, a força aumenta gradualmente até 100%.
O último passo foi a adição de dois nós estabilizadores: a frente ao nível do peito e as costas ao nível das pernas. Esses nós têm conexões nas costelas com nós fixos no tórax e na pelve, respectivamente, e nós instáveis se contraem com os músculos. Os nós estabilizadores têm um baixo valor de massa e não têm colisão com o piso, ao contrário de outros nós.
No gif abaixo, você vê o resultado: obtivemos uma física completamente determinística, baseada em cálculos de números inteiros que funcionam de maneira estável a 60 fps, mesmo nos dispositivos mais fracos que apoiamos.
Siga os jogos da Banzai nas redes sociais: Facebook , Vkontakte , Instagram , LinkedIn
A equipe da Banzai Games requer um especialista experiente em efeitos visuais. Leia mais sobre a vaga aqui .