Por que alguns jogos em rede usam interpolação e outros usam pathfinding para movimento remoto?

Essa é uma pergunta em aberto, mas eu gostaria que alguém contribuísse com um bom raciocínio para ambas.

Para um rápido exemplo de ambos:

Modelo de Interpolação

Pense no modelo Valve em que o cliente está recebendo atualizações de posição com freqüência e os controles remotos atualizam suas posições usando a interpolação nesses dados.

Encontrando o caminho

Nesse modelo, pense que o usuário envia um destino e todo mundo encontra o caminho.

Que tipos de jogos são adequados para cada um e quando um deve ser usado?

Eu trabalhei no código de rede para dois jogos em rede AAA em tempo real, um para smartphones e outro para um console portátil.

Para responder diretamente à sua pergunta "por que", bem, alguns jogos usam um ou outro, porque combina mais com eles do que com o outro. Isso depende não apenas do tipo de jogo, mas também do tipo de rede que estamos falando (os gabinetes de fliperama vinculados têm condições diferentes em comparação aos jogos que devem ser jogados em 3G). Alguns jogos realmente usam ambos, ou mesmo completamente. abordagens diferentes para sincronizar dados!

Eu gostaria de generalizar e considerar não apenas dados posicionais, mas praticamente qualquer tipo de dados que você possa sincronizar entre dois clientes em rede.

Em vez de duas possibilidades, gostaria de propor um espectro entre atualizações bruscas e bruscas.

• Atualizações muito difíceis são eventos discretos que alteram imediatamente o estado no outro cliente, sem qualquer tipo de interpolação, seja porque os dados são de natureza crítica (um jogador morreu), porque não são um tipo de dados aos quais a interpolação se aplica (um jogo de xadrez, mensagens de bate-papo, etc.) ou porque sua rede permite que você faça isso (pense em gabinetes de fliperama vinculados, onde o envio confiável de todo o estado do jogo 60 vezes por segundo está dentro das possibilidades).

  Com esse método, os atrasos na rede sempre aparecem como atualizações atrasadas e se manifestam como caracteres pulando.

• As atualizações difíceis com inter / extrapolação são semelhantes às atualizações muito difíceis, mas para dados em constante mudança, para os quais não é praticamente possível enviar os dados de maneira confiável sempre que eles são alterados. Pense em enviar uma posição e um vetor de velocidade; você deve poder interpolar dados entre dois pontos e extrapolá-los depois deles. Você deve ter um plano de contingência se os dados recebidos discordarem de suas extrapolações. Eu diria que a maioria dos jogos que exigem atualizações de posição usa esse método.

• As atualizações rígidas com sincronização são semelhantes às rígidas com inter / extrapolação, mas raramente requerem sincronização raramente. Você deve usar isso para dados que são realmente triviais para inter / extrapolar, como o relógio em um jogo de luta (uma vez definido nos dois lados, não é realmente necessário sincronizar novamente depois)

• As atualizações de hardware atrasadas são semelhantes às atualizações de hardware, mas o que você vê são dados do passado. Eu suspeito que em muitos jogos de arcade de música no Japão, onde você pode tocar uma música contra outra pessoa, na verdade você está jogando contra dados de jogadores gravados no passado, possivelmente horas ou mesmo dias antes. Obviamente, esse tipo de atualização é utilizável apenas quando você realmente não interage com o outro jogador.

• As atualizações flexíveis consistem no envio de dados de planejamento e na execução do plano em todos os hosts. Isso é o que você chama de "pathfinding". A quantidade de dados necessária para sincronizar dados como esse é muito menor; você pode usar esses tipos de atualizações quando conseguir se livrar de certas discrepâncias na forma como os dados são apresentados ao usuário, como na sincronização de centenas de inimigos.

  O planejamento das atualizações de dados também pode ser tão difícil quanto você quiser, é claro.

• Atualizações muito brandas são usadas quando o resultado de uma ação pode ser calculado com segurança muito antes de acontecer. Você acabou de enviar o resultado e o outro cliente apenas o reproduz. Por exemplo, alguns jogos de navegador e smartphone permitem que você lute contra outras pessoas, mas a batalha real leva horas para ser resolvida (pense em jogos do tipo Travian). É muito possível que esses jogos calculem o resultado no momento exato em que a batalha é iniciada, e você apenas vê os resultados dessa batalha.

  Outro exemplo sem rede disso seria na Civilização 4, com animações de batalha ativadas. Quando você ataca alguém, o resultado da batalha é calculado imediatamente, mas você vê uma animação dela sendo reproduzida. Posso garantir que a batalha não está sendo calculada, pois está sendo animada.

Como você pode ver, existem muitas maneiras de sincronizar dados, e tenho certeza que você pode imaginar muitas outras. Todos os jogos on-line, exceto os mais simples, provavelmente usarão uma combinação desses métodos, dependendo do tipo de dados que estão sendo sincronizados, do tipo de jogo e até do estado da rede (use atualizações físicas quando o atraso estiver baixo e siga em frente) atualizações mais suaves quando o atraso aumenta).

Não tenho informações sobre o processo de desenvolvimento da Valve, portanto, essa é apenas a minha opinião, mas:

Interpolação : eu diria que seria melhor para jogos de ritmo acelerado, como FPSs, por exemplo, onde é importante ter uma posição consistente para um inimigo pontualmente entre os jogadores. Interpolar significa que, mesmo que alguns pacotes sejam descartados (AFAIK, a maioria dos FPSs para vários jogadores usa UDP em vez de TCP / IP, o que garante nem a integridade nem a ordem de chegada dos pacotes), você terá um movimento suave na tela.

localização de caminhos : se o tempo não é um elemento crucial da sua jogabilidade e o seu algoritmo encontra um caminho consistente quando executado novamente, a busca de caminhos pode ser interessante porque não exige que você envie atualizações frequentes e, portanto, pesadas, com a posição de cada jogo. entidade. Eu diria que isso parece adequado para um sistema baseado em turnos, por exemplo, onde você pode limitar a quantidade de solicitações de rede (uma no início da curva, uma quando a curva terminar, para garantir que todos os clientes estejam "sãos" " Estado.

Mais uma vez, nunca trabalhei em um jogo em rede ou em um estúdio de grandes jogos, mas pelo que li algumas vezes, é assim que eu faria :):

A resposta do Panda Pyjama é muito boa.

Basicamente, a questão se resume à quantidade mínima de dados que você pode enviar que colocará vários clientes na mesma consciência do estado de cada um dos outros e como você lida com o atraso em que durante esse período os clientes podem estar em um estado diferente.

Então, processualmente gerado, onde todas as interações são conhecidas antes da mão é mais fácil, pois se todas as variáveis ​​forem conhecidas, o resultado será conhecido. Por exemplo, isolar alguém em uma sala que você conhece os métodos de processamento e fornecer a ele algum conjunto de dados, é possível prever com precisão os resultados. Portanto, você pode fornecer a todos os outros clientes os resultados sem esperar que eles concluam seu cálculo.

No entanto, ele não mencionou um método. Resultados forçados.

Se o sistema espera uma ação de alguma entidade e outras ações dependem dessa ação, e outros cálculos levam em conta essa ação e já foram pré-processados ​​com o resultado esperado. Então, para manter a sincronização, todo o sistema é parado enquanto a única entidade que não está no lugar certo é colocada corretamente novamente em seu caminho.

Um exemplo do mundo real são todas as outras entidades em um padrão de retenção para garantir que a compensação adequada seja enviada a mim.