Lidando com a latência em jogos em rede

Question

Estou pensando em fazer um jogo em rede.Sou um pouco novo nisso e já me deparei com muitos problemas ao tentar montar um bom plano para cálculo morto e latência de rede, então adoraria ver alguma boa literatura sobre o assunto.Descreverei os métodos que considerei.

Originalmente, eu apenas enviava a entrada do jogador para o servidor, simulava lá e transmitia as mudanças no estado do jogo para todos os jogadores.Isso dificultou a trapaça, mas sob alta latência as coisas eram um pouco difíceis de controlar, já que você não vê os resultados de suas próprias ações imediatamente.

Este artigo do GamaSutra tem uma solução que economiza largura de banda e faz com que a entrada local pareça suave, simulando também no cliente, mas parece jogar a proteção contra fraudes pela janela.Além disso, não tenho certeza do que fazer quando os jogadores começam a manipular o ambiente, empurrando pedras e coisas do gênero.Esses objetos anteriormente neutros se tornariam temporariamente objetos sobre os quais o cliente precisa enviar PDUs, ou talvez vários jogadores o façam ao mesmo tempo.Quais PDUs venceriam?Quando os objetos deixariam de ser duplamente rastreados por cada jogador (para comparar com a versão considerada morta)?Deus não permita que dois jogadores se envolvam em uma partida de sumô (por exemplo,comecem a empurrar um ao outro).

Este bit do gamedev.net mostra a solução gamasutra como inadequada, mas descreve um método diferente que realmente não corrige meu exemplo colaborativo de empurrar pedras.A maioria das outras coisas que descobri são específicas para atiradores.Eu adoraria ver algo mais voltado para jogos como SNES Zelda, mas com um pouco mais de física/momentum envolvidos.

• Observação:Não estou perguntando sobre simulação de física aqui - outras bibliotecas cobrem isso.Apenas estratégias para tornar os jogos suaves e reativos, apesar da latência da rede.

Answer 1

Confira como a Valve faz isso no Source Engine: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Se for um jogo de tiro em primeira pessoa, você provavelmente terá que se aprofundar em alguns dos tópicos mencionados, como:previsão, compensação e interpolação.

Answer 2

eu acho esta postagem do blog de física de rede por Glenn Fiedler, e mais ainda a resposta/discussão abaixo dele, incrível.É bastante demorado, mas vale a pena.

Resumindo

O servidor não consegue acompanhar a repetição da simulação sempre que a entrada do cliente é recebida em uma simulação de física de jogo moderna (ou seja,veículos ou dinâmica de carroceria rígida).Portanto, o servidor ordena a latência + jitter (tempo) de todos os clientes à frente do servidor, para que todos os pacotes recebidos cheguem no JIT antes que o servidor precise deles.

Ele também fornece um esboço de como lidar com o tipo de propriedade que você está solicitando.Os slides que ele mostrou no GDC são fantásticos!

Sobre trapaça

O próprio Sr. Fiedler (e outros) afirmam que este algoritmo sofre por não ser muito à prova de fraude.Isso não é verdade.Este algoritmo não é menos fácil ou difícil de explorar do que a previsão cliente/servidor tradicional (veja o artigo sobre a previsão cliente/servidor tradicional em Resposta de @CD Sanchez).

Para ser absolutamente claro:o servidor não é mais fácil de trapacear simplesmente porque recebe o posicionamento físico da rede bem a tempo (em vez de x milissegundos de atraso, como na previsão tradicional).Os clientes não são afetados de forma alguma, pois todos recebem as informações posicionais de seus oponentes com exatamente a mesma latência da previsão tradicional.

Não importa qual algoritmo você escolha, você pode querer adicionar proteção contra cheats se estiver lançando um título importante.Se estiver, sugiro adicionar criptografia contra robôs fantoches (por exemplo uma cifra de fluxo XOR onde o "keystream é gerado por um gerador de números pseudo-aleatórios") e verificações simples de integridade contra cracks.Alguns desenvolvedores também implementam algoritmos para verificar se os binários estão intactos (para reduzir o risco de cracking) ou para garantir que o usuário não esteja executando um depurador (para reduzir o risco de desenvolvimento de um crack), mas esses são mais discutíveis.

Se você está apenas fazendo um jogo indie menor, que só pode ser jogado por alguns milhares de jogadores, não se preocupe em implementar nenhum algoritmo anti-cheat até que 1) você precise deles;ou 2) a base de usuários cresce.

Answer 3

implementamos um jogo multiplayer de cobra baseado em um servidor obrigatório e jogadores remotos que fazem previsões.A cada 150ms (na maioria dos casos) o servidor envia de volta uma mensagem contendo todos os movimentos consolidados enviados por cada jogador remoto.Se os movimentos do cliente remoto chegarem atrasados ​​ao servidor, ele os descartará.O cliente irá reproduzir o último movimento.

Answer 4

Confira os tópicos de educação em rede no site do XNA Creator's Club.Ele se aprofunda em tópicos como arquitetura de rede (ponto a ponto ou cliente/servidor), previsão de rede e algumas outras coisas (no contexto do XNA, é claro).Isso pode ajudá-lo a encontrar as respostas que procura.

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

Answer 5

Você poderia tentar impor latência a todos os seus clientes, dependendo da latência média na área.Dessa forma, o cliente pode tentar contornar os problemas de latência e será semelhante para a maioria dos jogadores.

É claro que não estou sugerindo que você force um atraso de 500 ms para todos, mas pessoas com 50 ms podem ficar bem com 150 (100 ms extras adicionados) para que a jogabilidade pareça mais suave.

Em poucas palavras;se você tiver 3 jogadores:

• John:30ms
• Paulo:150ms
• Amém:80ms

Após os cálculos, em vez de enviar os dados de volta aos clientes todos ao mesmo tempo, você contabiliza a latência e passa a enviar para Paul e Amy antes de John, por exemplo.

Mas esta abordagem não é viável em situações de latência extrema, onde conexões dial-up ou usuários sem fio podem realmente atrapalhar a vida de todos.Mas é uma ideia.