War Thunder background
Físicas de Colisão de Veículos no jogo - Explicação
Atenção! Formato de notícias desatualizado. O conteúdo pode não ser exibido corretamente.
Atenção! Esta notícia foi publicada na versão antiga da página. Pode haver problemas com a mostragem da mesma em certas versões do navegador.


Nós recebemos algumas reclamações e faltas de entendimento acerca de como os veículos colidem com outros no jogo, e Anton (CEO da Gaijin e War Thunder Lead Developer) decidiu tentar escrever uma explicação de como o nosso jogo interpreta as físicas do mundo virtual.


Um pequeno resumo de como o net-code trabalha no War Thunder

  1. O cliente aplica os controlos que simulam as físicas e enviam os controlos para o servidor. O servidor recebbe os controlos e aplica-os no passado (devido ao ping, os controlos enviados aconteceram no passado).
  2. O servidor envia para o cliente o chamado "authority state" - por exemplo a posição ''real''.
  3. Claro que quando chega ao cliente já está no passado (desatializado) devido ao ping. Com isto, o cliente reaplica todos os controlos que foram aplicados desde essa altura a esta ''antiga'' posição (mas verdadeira para o servidor).
  4. Isto dá a ''nova'' posição.

Embora seja de difícil compreensão e muito extenso ao nível computacional (quando comparado com por exemplo, o netcode do Battlefield, que basicamente acontece no passado) isto dá um resultado muito bom em qualquer latência aceitável quando se controla um veículo.



Experiência de jogo offline, online?

Isto dá um bom nível de controlo, qualidade de tempo-single player-offline se as três condições se confirmarem:

Ping estável. Tal como você pode ver do algoritmo, ambos servidor e cliente confiam em informação ao longo do tempo. E se o ping é muito instável, os resultados são instabilidade no geral. Com isto, 100 ms estáveis é melhor que 50 de média entre o 10 e 110..

Packet-loss aceitável. É por isto que é sempre melhor jogar com cabo do que wireles. Claro que todos os dados são enviados com uma certa redundância. Mas se todos os controlos do cliente para o servidor são perdidos em 700 ms, então torna-se demasiado obsoleto os reaplicar (lembre-se que o cliente não está só no mundo, há outros cliente e eles precisam de interagir com a posição de alguém, pelo que não podem permitir reaplicar os controlos dos último, digamos, 10 segundos - isso resultaria num teleporte significativo no servidor e por conseguinte em todos os outros clientes). No entanto, se você possuir um packet loss de 3-5%, então isso será bom. Além disso, tenham em mente que a perda de informação que o jogo mostra nas estatísticas não é a perda que o cliente tem, isso é apenas medido na base do tráfego ''de confiança'', pois o tráfego não confiável não pode de facto determinar a informação perdida. Ainda, mesmo 5% em média não significa que perdeu tudo ao nível, digamos, dos controles.

Sem interações com outros jogadores. Claro que não é verdade no jogo. No entanto, na maioria das vezes 99,9% do tempo não há interações, e em 99% das interações são disparos. Os disparos são realmente interações fantásticas (para o net code/imersão dos jogadores), pois na maioria das vezes não está fazendo nada (ricochetes ou falhanços) ou dando realmente danos, pelo que algumas dessincronizações (pequenos teleportes se você se mover 100 ms quando de facto a sua esteira foi danificada 200 ms atrás) parece ok e não desfaz a imersão.

Claro, como todo o netcode no War Thunder funciona assim você ''vê'' o outro jogador num tempo extrapolado - exemplo, nós sabemos da sua posição antiga, a sua velocidade e controlos e nós prevemos a posição futura baseada niso pois os veículos são altamente previsíveis e possuem uma elevada inércia, pelo que é bom na maior parte das vezes.



O netcode do War Thunder

Tanto quanto sei este net-code foi inventado no War Thunder. O padrão industrial para shooters mostra cada cliente interpolado no passado (Battlefield, CS) - mas não coloca ninguém com melhor ping numa melhor posição (e não funciona tão bem com físicas de colisões por razões óbvias - estes movimentos já aconteceram) ou nenhuma interpolação (extra) qualquer (Q3) onde você necessita de prever o seu ping e disparar à frente do inimigo (o que não funciona bem com qualquer colisão e coloca todo o mundo com ping elevado numa muito má posição). Há uma solução óbvia que é chamada de ''thin client'' onde mostramos apenas o que o servidor envia e prevê/compensa o lag aplicando todo os controlos no futuro (com um certo atraso). É por isso que muitos MMORPG trabalham (e outros jogos), mas não é aceitável para veículo a elevadas velocidades com estados críticos instáveis, como aeronaves e por vezes até mesmo veículos terrestres (movimentos a elevadas velocidades em ângulos elevados), pois torna os controlos demasiado lentos a responder.

Não há solução ideal para um jogo online (claro que podíamos ''confiar'' no cliente, podíamos melhorar muito as colisões para cada cliente), mas a nossa solução trabalha muito bem para veículos na maioria das situações. O principal senão (e óbvio) é que não trabalha bem com colisões físicas entre veículos (especialmente com os controlados pelos jogadores).



Resolvendo as colisões no jogo

Resolver físicas de colisões é normalmente uma das mais difíceis tarefas, mas torna-se especialmente difícil quando você tenta recriar eventos, que, não se tratando apenas de corrigir colisões mas também tentar ''confiar'' nos controles dos utilizadores (e não na posição dos jogadores) no passado (exemplo, reaplicando-os para o último momento do ping do cliente). Claro que quando você observa a dita colisão de outro cliente (repetição) tonra-se ainda mais estranho - não apenas porque um cliente irá reaplicar os seus controles após a colisão no passado, mas também porque você está vendo uma extrapolação, futuro, posição do veículo inimigo, que está vendo a mesma coisa(replicando os controlos no servidor).

Em alguns exemplos dados, a colisão em si pode de facto acontecer. Os tanques viram-se, mesmo em terreno nivelado sem ajuda de outros tanques (você pode ver vídeos de testes de condução de tanques/biatlo de tanques, etc). Mas o comportamento observado que leva a resultados naturais pode parecer tudo menos natural, em parte devido a você nunca ver o que de facto aconteceu (no servidor) e porque o servidor em si tem de recriar os eventos (controles) em condições muito específicas.

No nosso jogo, o servidor transmite as posições, não controlos, pelo que ninguém depende do cliente mais lento. Normalmente com melhor ping- você terá uma melhor consciência do que está à sua volta e melhor mira. Mas os controlos do seu próprio veículo não são dependentes do pont (apenas a perda de informação - packet loss), se você não está colidindo com outro veículos. Desde que o controlo é a norma, e a colisão é rara (não há de facto nenhuma boa solução online para uma solução de colisão, se não forçar uma lentidão (latência nos controlos) ou no chamado "thin client"), isto permite oferecer uma experiência geral e permite aos jogadores de todo o mundo jogar juntos.

Nós gostaríamos de terminar com a recomendação de manter o seu espaço e tentar não colidir com colegas de equipe. Em suma, na realidade isto pode causar problema sérios à tripulação e danificar quaisquer veículos envolvidos e até mesmo a pintura.


A Equipe War Thunder

Ler mais:
Ganhe a Alcione no Evento Voo do Albatroz!
  • 16 julho 2024
Armored Apex 2024 e prémios exclusivos via Twitch Drops!
Thunder Show: DESTROYER OF WORLDS
Floats!
  • 26 julho 2024