rede multiplayer com física


12

Estou curioso para saber como a rede multiplayer com a física é implementada em jogos de corrida. Temos um mundo físico com vários veículos velozes controlados por pessoas diferentes. Digamos que os veículos possuam armas e podem atirar um no outro (Twisted Metal, Vigilante v8)

Estou ansioso por hits e colisões. Servidor autorizado ou uma alternativa melhor?

Respostas:


5

Geralmente, um servidor é empregado, armazenando o estado "verdade" que é periodicamente compartilhado com os clientes. As colisões acontecem independentemente em Clientes e Servidores, com os estados dos Clientes estimados a partir dos estados anteriores, usando um processo semelhante ao que geralmente é chamado Dead Reckoning . Quando um estado do servidor alcança um cliente, se houver diferenças, o cliente realiza uma transição do estado atual para o recém-recebido principalmente por meio de interpolação.

No entanto, com muitos objetos, as colisões podem ser um problema real; portanto, o que geralmente é feito é manter o tempo simulado dos clientes um pouco atrás do tempo simulado do servidor para permitir vários graus adicionais de flexibilidade. Este artigo sobre o código-fonte do mecanismo de fonte da Valve é bastante explicativo. Além disso, se você ainda estiver indeciso sobre qual middleware / biblioteca de rede usar, sugiro que você analise o RakNet e seu componente "ReplicaManager3" .


2

Há várias coisas que você pode fazer.

  1. Você pode centralizar todos os objetos de física no servidor e sincronizar as coordenadas com os objetos dos jogadores em todos os clientes. É o mais fácil e funciona sem muitas falhas, no entanto, usa muitos recursos e requer muita largura de banda. Você pode otimizar o uso da largura de banda enviando apenas valores ao player de outros players que estejam dentro de um determinado raio.

  2. Você pode fazer o que Neenster mencionou e fazer com que o servidor e os clientes simulem a física; de vez em quando o servidor corrige os clientes. Isso significa que todos os clientes calculam sua própria física para cada jogador, e você sincroniza os eventos de pressionamento de tecla no servidor, fornecendo a trajetória de cada jogador em cada cliente. A cada 5 segundos, digamos, o servidor transmite sua simulação de física e todos os clientes aceitam a alteração. Isso pode criar pequenos desvios que são imperceptíveis na maioria das vezes, mas durante o atraso na rede e a perda de pacotes (inevitável com UDP de alto tráfego), você notará que seu player e / ou outros players andam pela tela e mudam de posição rapidamente e com agilidade. palavra?).

  3. Você pode fazer com que cada cliente calcule sua própria física e sincronize suas coordenadas. Isso dificulta a simulação da física em objetos compartilhados entre clientes. É um conceito bastante complexo a ser implementado se você deseja fazer algo sofisticado, porque determinado objeto não pertence necessariamente a nenhum cliente.

O primeiro é provavelmente o mais fácil e deve permitir que você tenha cerca de 4-5 jogadores com pouco atraso. Exigiria que cada partida tivesse seu próprio servidor. Se você estiver fazendo partidas pela LAN, esse é o caminho a percorrer.

O segundo é provavelmente o mais prático, porém pode ser difícil de implementar. Também é bastante útil executar simulações de física no servidor. Se você possui servidores centralizados, provavelmente precisará carregar o saldo de várias máquinas, talvez permita 10 correspondências por servidor, carregue novas correspondências no servidor com menos correspondências.

A terceira é definitivamente a menos estressante no servidor e provavelmente é a melhor solução se você estiver executando um esquema de rede ponto a ponto. Como mencionei, pode ser difícil sincronizar objetos que não sejam o seu player, porque esses objetos também podem ser alterados por outros clientes.

Não sei dizer qual usar, porque não sei como o seu jogo funciona. Tudo o que posso fazer é fornecer os fatos. Se você tiver mais perguntas, não hesite em comentar.


Você sugere que deixar os clientes fazerem sua física é uma solução aceitável, mas você não se identificou com trapaça.
Cubuspl42 16/05/19

@ cubuspl42 Pelo esforço de permanecer no tópico, omiti os detalhes. Considero oportuno que o OP possa explorar ainda mais a solução para explorar possíveis maneiras de mitigar a trapaça.
Tsturzl 16/05/19

Uma dessas maneiras é permitir que o desvio do que cada cliente fornece seja limitado a um limite. Por exemplo, a maioria dos clientes diz que um determinado objeto está na posição 5,8 ou 6,9, mas um relata 12,19 como coordenada, que pode ficar fora de um limite em comparação com o quanto ele se desvia dos outros clientes. Esta é apenas uma solução parcial, mas a maioria dos jogos oferece apenas soluções parciais para trapacear, daí a razão pela qual ainda acontece. Essa solução não significa que eles estão trapaceando, mas significa que seu posicionamento precisa ser corrigido e pareceria um atraso para eles.
tsturzl 16/05/19

Bem, eu discordo um pouco. Alguns tipos de truques são corrigíveis, outros não. Por exemplo, na minha opinião, é um design de jogo ruim se alguém puder fazer um speedhack para um jogo de tiro online competitivo. Ou algum truque maluco que permite que você voe pelo mapa com um modo de deus e munição infinita (acredito que aconteceu em Crysis 1 em algum momento). Estes são corrigíveis, basta projetar seu jogo corretamente. Coisas como o wallhack são quase impossíveis de corrigir (isso exigiria enormes recursos do servidor). Aimbot é praticamente impossível de fixar. Sua solução nº 3 aumenta o risco desse pior tipo de fraude.
Cubuspl42

@ cubuspl42 Acho que você está perdendo a idéia do que é um exemplo. A opção 3 pode impedir exatamente o problema que você está falando. Você normalmente tem um TCP que compartilha velocidade e, em seguida, pode verificar facilmente a velocidade entre clientes e formar um consenso; também é possível fazer algumas contas simples para determinar se as coordenadas do UDP são plausíveis, dada a velocidade fornecida, pressupondo que seus clientes tenham um relógio sincronizado (pode ser estabelecido na conexão do relógio HW).
Tsturzl 18/05/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.