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.

multiplayer client-server

— afirmação
fonte

Basta enviar as informações sobre todos os jogadores. Trapaceiros vão trapacear. Não prejudique a experiência de jogadores honestos e pense em criar um sistema de sinalização para trapaceiros.

— user1306322

@ user1306322 Ao tornar mais fácil para os trapaceiros, você também prejudicará jogadores honestos. Um sistema de sinalização é uma boa idéia, mas se a invisibilidade for uma grande parte do jogo, algo preventivo pode ser necessário.

— ThatOneGuy

@ user1895420 geralmente é bom o suficiente para não enviar essas coisas em texto sem formatação, para que nenhum jogador comum possa facilmente acessar esses dados. Se apenas uma pessoa com experiência em tecnologia pode fazer isso, é a melhor medida preventiva possível.

— User1306322

Ou, talvez, seja uma idéia melhor mudar um pouco a mecânica da invisibilidade para que não funcione muito perto, para que mesmo aqueles que são capazes de trapacear nos dados do jogo não possam realmente obter nenhuma vantagem.

— user1306322

Que tal apenas enviar a posição do jogador invisível (com uma bandeira para mantê-lo invisível) somente quando um jogador visível estiver próximo? Isso deve fornecer alguns quadros para evitar o problema de excesso de movimento, enquanto não deve dar aos trapaceiros tempo suficiente para reagir. Para dois jogadores invisíveis, eu simplesmente ignoraria a colisão. Se você tiver um servidor central com todas as posições do jogador, também poderá coordená-lo quando transmitir a posição e quando não.

— JDM

Respostas:

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).

— Sean Middleditch
fonte

O jogo Team Fortress 2 usa essa primeira abordagem ... Se um espião invisível toca outro jogador, o outro jogador pode vê-lo (ou, por trás, pelo menos sente algum obstáculo).

— Xantix

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.

— Daniel Rusznyak
fonte

o problema de ignorar a colisão de jogadores invisíveis é se um jogador invisível deixa de ser invisível quando está colidindo com outra pessoa. Além disso, não parece certo. No meu jogo, eu realmente não tenho caminhos ou busca de caminhos, os jogadores só podem se mover nas 4 direções, um passo de cada vez

— affiszervmention

O que resta é enviar o movimento previsto (um único vetor ou uma matriz de vetores) e fazer uma verificação no servidor. Ou apenas anime a correção, como dito abaixo.

— Daniel Rusznyak

Se você possui um mapa baseado em grade e está verificando cada quadrado um por um, tente codificar a localização dos caracteres invisíveis no lado do servidor com uma codificação unidirecional, como SHA-1 ou SHA-2 , verifique seu próprio caminho, codificando as coordenadas marcadas com o mesmo algoritmo. Não posso dizer que é eficaz em termos de desempenho, mas se você realmente deseja fazê-lo no lado do cliente, esta solução pode funcionar também com um número limitado de posições, e os hackers podem ser realmente problemáticos devido à grande quantidade de pontos de grade a serem codificados e combine com os dados na memória.

— Daniel Rusznyak

Eu posso ver isso funcionando. Meu menor mapa tem 1500 posições diferentes. Devo usar o HMAC com a chave mudando a cada poucos segundos para impedir que o invasor pré-calcule todas as posições?

— Affiszervmention

Não, qualquer esquema que você possa criar não seria "seguro" contra hackers. Se o cliente puder determinar se o jogador irá colidir contra uma determinada posição, alguém poderá invadir seu jogo. HMAC com uma chave rotativa não impedirá que o cliente faça 1500 HMACs por segundo. Você não tentar fazer criptografia de si mesmo. Se você deseja atingir o objetivo original, envie a posição invisível do jogador para o cliente se ele estiver a 1 ou 2 peças do jogador. Então você pode apenas hackear para saber se alguém está ao seu lado (o que não é útil porque você pode simplesmente passar para verificar isso).

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.

— R ..
fonte

Acho que poderia funcionar, mas meu jogo é baseado em blocos (esqueci de dizer).

— affiszervmention

Portanto, apenas revele jogadores invisíveis em blocos adjacentes, ou a 2 passos de distância, ou o que for.

— R ..

então não é certeza de que iria colidir, e os jogadores invisíveis teria que ficar longe de qualquer um hacker para não ser descoberto

— affiszervmention