Sincronização multijogador e busca de caminhos

Eu tenho uma interface do tipo aponte e clique em um cliente, que executa um A * no servidor, para encontrar o caminho.

O jogo é controlado como um RTS, mas o mundo é persistente; portanto, os jogadores devem poder entrar / sair a qualquer momento, e haverá apenas 30 unidades no máximo na tela.

Qual é a melhor maneira de sincronizar os movimentos do player entre o servidor e o cliente, depois de calcular o (s) caminho (s)?

O servidor precisa sincronizar os clientes em todas as etapas / quadros da animação? ou pode apenas dizer ao cliente "vá para a posição X, Y" para cada nó no caminho e para cada jogador em movimento? Ou é melhor apenas executar os cronômetros de animação no cliente e no servidor e sincronizar implicitamente dessa maneira?

Como seria a troca de dados típica para o movimento baseado em caminhos?

EDITAR:

Alguns de vocês têm sugerido um bloqueio, porque eu disse "RTS", mas o jogo não é um RTS, apenas tem o mesmo tipo de interface. A grande diferença é que preciso ter jogadores para entrar e sair do jogo a qualquer momento . Desculpe por não ser mais específico.

Uma alternativa é fazer a busca de caminhos no cliente que possui a unidade. Isso tem a vantagem de espalhar o trabalho de maneira mais uniforme. Uma desvantagem de fazer toda a busca de caminhos no servidor é que o servidor precisa fazer tudo isso; Uma desvantagem de enviar apenas comandos 'mover para X, Y' para os clientes é que cada cliente precisa encontrar todos os caminhos. Em vez disso, a cada 'tick' no ciclo de bloqueio, cada cliente informa ao servidor, literalmente, o próximo passo de sua unidade. O servidor garante que a unidade possa realmente se mover para lá e a move. Como o cliente não possui todas as informações (principalmente o que as unidades do outro cliente estão fazendo), um comando de movimento inválido não é tratado como um erro. Isso está perdendo largura de banda para ganhar mais tempo no cálculo de caminhos.

Substitua o servidor por pares; esse método também funciona para jogos ponto a ponto, desde que você verifique se a ordem na qual os movimentos da unidade são considerados é a mesma em todas as máquinas.

Os jogos RTS normalmente possuem sincronização de trava (a sincronização acontece a cada quadro). A indicação de qualquer caminho para o cliente permitiria que os clientes invadidos abusassem das informações extras.

Nem. A única coisa que você deve enviar são os comandos. Exemplo: Essas 20 unidades devem passar para (X, Y) e deixar cada jogador descobrir como chegar lá. A parte complicada é garantir que todos façam exatamente a mesma coisa. Para conseguir isso, um modelo de passo de bloqueio é usado, os links abaixo devem explicá-lo em detalhes. Além disso, você deve sincronizar apenas as peças importantes. Qualquer coisa que não mude a jogabilidade não deve ser sincronizada. Animações em jogos RTS geralmente são apenas para o lado visual.

Outra coisa, jogos RTS geralmente não são cliente-servidor, mas P2P. Dessa forma, um dos jogadores não pode trapacear porque, quando qualquer inconsistência é detectada, você simplesmente desconecta.

Aqui está algo para ajudá-lo a prosseguir: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://altdevblogaday.com/2011/07/09/synchronous-rts-engines-and- a-tale-of-desyncs / http://altdevblogaday.com/2011/07/24/synchronous-rts-engines-2-sync-harder/

Depois que o caminho é calculado, o servidor apenas usa esse caminho para controlar o personagem. A presença de um caminho não faz diferença para esse problema - você ainda envia os mesmos dados, sejam atualizações regulares da posição ou qualquer outra coisa. Normalmente, é bom enviar posições regulares (interpoladas no cliente para suavizá-las) e uma mensagem separada quando a unidade parar.

No meu jogo (um jogo tipo RPG multiplayer), envio partes do caminho para o cliente (para NPCs próximos), ou seja. as 3 próximas posições e o horário em que o NPC deve estar lá. Para os jogadores, enviei a última posição válida + o carimbo de data e hora para que no cliente eu possa fazer um cálculo morto (ou algo mais elaborado, se desejado).

Isso funciona completamente bem, principalmente porque não há colisões entre jogadores / NPC (com um atraso baixo, você não percebe nada, com um, digamos, um atraso de mais de 250 ms, você percebe a diferença se pode ver as duas telas (de dois jogadores ) ao mesmo tempo, mas ainda não é realmente perceptível em 'uma tela').

Então, eu diria: vá com a criação do servidor (validaçãog posições + timestamps dos jogadores e também para a IA no início, você pode criar um sistema mais elaborado para o NPC mais tarde, sem grandes problemas) + previsão do cliente.

ps. Eu uso uma precisão de milissegundos que funciona perfeitamente bem, exceto que um int assinado é retido por apenas três semanas antes que eu precise reiniciar o servidor.

Você também pode verificar a previsão de tempo (por exemplo, tentando entrar em sincronia o mais próximo possível do servidor).