Como prever o movimento corretamente quando um jogador está invisível?

Eu tenho um jogo multiplayer e estou fazendo previsões do lado do cliente, mas alguns jogadores podem beber uma poção e se tornar invisíveis ...

O problema é que, quando eles se tornam invisíveis, não compartilho nada que o cliente possa usar para saber que ele está lá; portanto, quando um jogador tenta entrar em um ladrilho ocupado por um jogador invisível, ele prevê que será bem-sucedido e obterá um correção de posição feia enviada pelo servidor.

Uma solução seria compartilhar algo para o cliente saber, mas os hackers poderiam usá-lo para descobrir onde estão os jogadores invisíveis, trapaceando.

Btw eu já resolvi previsão de movimento regular, ele funciona perfeitamente.

Isso pode ser considerado um problema de animação. Se uma correção de posição retornar do servidor devido a uma tentativa de se mover para um objeto invisível, envie de volta não apenas a correção, mas um sinalizador indicando por que a correção foi necessária. Em vez de um jogador dar um pulo para trás, ele pode fazer um tipo de "woah", animando para trás, tornando mais provável que pareça que ele acabou de encontrar alguma coisa.

Nos jogos que usam essa abordagem, não é incomum remover a invisibilidade (pelo menos momentaneamente) de qualquer coisa que tenha ocorrido. Entre outras coisas, isso incentiva os jogadores invisíveis a evitar multidões ou se aproximarem demais de outros personagens, reduzindo a frequência de colisão com um jogador invisível. Assim, mesmo que sua animação para esse tipo de colisão seja fraca (ou inexistente), ela é um pouco escondida pelo personagem invisível surgindo em visibilidade e claramente telegrafando para todos o que aconteceu.

A necessidade de animação pode ser removida não permitindo que a invisibilidade funcione de perto. Isso dá ainda mais incentivo aos jogadores invisíveis para evitar se aproximar de outros personagens. Essa é uma abordagem comum para jogos furtivos e IA (substitua "invisível" por "não visível para o alvo") e pode ser vista em jogos PvP como o World of Tanks. Não há necessidade de se preocupar com a resposta à colisão com caracteres invisíveis se você nada invisível estiver perto o suficiente para colidir (dentro dos limites de latência).

A solução da Dracor para simplesmente ignorar colisões com objetos invisíveis também é boa. Isso requer novamente algumas animações (para o cliente dos jogadores invisíveis) para que os objetos não estejam apenas cortando o avatar do jogador na tela. Se nada mais, você pode fazer com que objetos visíveis sempre empurre objetos invisíveis, de modo que o jogador invisível saia automaticamente do servidor, se alguém colidir com ele.

Colisões invisíveis e invisíveis são um pouco mais complicadas. Pode ser vantajoso desabilitar as colisões, pois ninguém pode ver se dois objetos invisíveis estão unidos (assumindo "invisível", queremos dizer que ambos os objetos não são visíveis para o mesmo cliente). Se um dos objetos se tornar visível, ele reverte automaticamente para a resposta de colisão visível-invisível (empurre o objeto invisível).

Isso tudo fica mais complicado se a invisibilidade tem conjuntos complicados de quem pode ver quem. A primeira ou a segunda solução acima provavelmente é melhor aqui, se você precisar. Nem todo problema como esse precisa de uma solução técnica; muitos precisam apenas de soluções de design (por exemplo, não permitem esse recurso aos seus designers).

Eu realmente só vejo duas opções aqui se você não quiser dizer ao cliente onde está o jogador invisível: 1) Você ignora a colisão de unidades para jogadores invisíveis - uma solução simples, e os jogadores não conseguiriam encontrar os jogadores invisíveis testes de colisão também. 2) Depois de decidir o caminho previsto, você envia ao servidor o caminho previsto, corrige o caminho no lado do servidor e envia o novo caminho de volta.

A menos que eu esteja entendendo algo errado, a solução é simples. Não envie informações ao cliente sobre todos os jogadores invisíveis, apenas aqueles que estão dentro do alcance que poderiam estar sujeitos a colisão dentro dos limites de movimento durante o intervalo previsto. Em outras palavras, se o cliente precisar prever apenas 200 ms no futuro, envie apenas informações sobre players invisíveis dentro de max_player_velocity units/sec * 1/5 secunidades de distância.