Simulações físicas do servidor com centenas de jogadores

9

Atualmente, estou trabalhando em um jogo voltado para a física para um jogador, onde gostaria que a física fosse simulada no servidor. Isso porque o jogo terá tabelas de líderes, progressão persistente de jogadores, etc. e eu quero evitar qualquer tipo de trapaça - basicamente uma arquitetura pura de cliente-servidor, o cliente é "burro" e exibe apenas o que o servidor deseja que você exiba.

O problema, porém, é que o jogo provavelmente será jogado por centenas (talvez milhares) de pessoas ao mesmo tempo. Isso me preocupa, pois provavelmente matará o poder de processamento do servidor se eu tiver que fazer e manter centenas de estados ao mesmo tempo.

Eu não teria problemas para mover todas as simulações de física para o lado do cliente, mas precisaria realmente de uma maneira de validar se o resultado de uma simulação de cliente é válido. No entanto, não consigo descobrir como.

Pensei em executar a simulação do lado do servidor de vez em quando para validar se o cliente ainda está jogando limpo, mas realmente quero que o servidor tenha o menor esforço possível.

A física se tornará tão complexa quanto a demonstração da GDC 2011 de Glenn Fiedler , talvez até mais simples. No entanto, muito mais corpos rígidos sempre em colisão estarão em uma única cena e todos serão visíveis ao mesmo tempo.

Tenho dificuldade em obter uma resposta para esse caso em particular, pois a maioria dos recursos da Web - novamente, o site de Glenn Fiedlers é ótimo - fala sobre física em rede em pequena escala (por exemplo, um FPS com 30 jogadores, como o Halo).

Qualquer conselho, sites, documentos ou similares sobre o assunto será muito apreciado.

Uma recapitulação das perguntas às quais gostaria de responder:

Quão viável é um modelo cliente-servidor? A minha preocupação com o poder de processamento do servidor é legítima e fundamentada?
É possível validar com segurança uma simulação física executada pelo cliente no servidor? Se sim, como?

— Lennard Fonteijn
fonte

Deixarei essa questão em aberto um pouco mais, na esperança de que mais pessoas postem seus pensamentos. Meus agradecimentos vão para aqueles que já fizeram!

— Lennard Fonteijn

Contanto que diferentes clientes sejam independentes, você não terá problemas em dimensionar horizontalmente. Use algo como EC2, coloque capacidade on-line conforme necessário.

— Ipeet 8/03

11

Onde está o problema se alguém trapaceia em um jogo para um jogador? Basta deixá-los, deixá melhor a ideia leaderboard e foco em fazer um divertido jogo single player

— Maik Semder

2

"É possível validar com segurança uma simulação física executada pelo cliente no servidor?" Sim, é possível validá-lo, mas lendo seus comentários abaixo: Seu planejamento de distribuir dinheiro de RL para pontuações máximas e é semelhante a um jogo de dardos, ou seja, após o lançamento inicial da física. O problema aqui é menor para validar a física, isso é fácil. O problema é que você terá trapaceiros que deixarão um programa de computador dar a eles pontuação perfeita.

— Daniel Carlsson

A física validada por servidor em um mundo compartilhado é inteiramente possível, o DCUO é um bom exemplo disso. Observe que "servidor" realmente significa "um monte de caixas de servidor" enquanto você parece escrever em termos de um "servidor" sendo uma única caixa em algum lugar. Atualmente, não é possível simular milhares de atores independentes no mesmo espaço físico, daí a falta de discussão sobre o assunto; o que você pode fazer é espalhar milhares de jogadores em ilhas independentes de simulação que não interagem.

— Patrick Hughes

5

Você pode validar do lado do cliente os envios de outros usuários e fazer com que o cliente relate ao servidor se um envio parecer inválido.

Depois, você pode agir (banir o trapaceiro ou banir quem falsificou o relatório falso). Para verificar se esse envio é realmente inválido ou não, você pode usar um cliente especial ou o que for.

— o0 '.
fonte

3

Isso é realmente muito inteligente! Não teria pensado nisso, obviamente, pelo menos 2 ou 3 clientes teriam que executar a simulação, caso o cliente que está executando outra pessoa esteja enganando - nesse caso, o servidor sempre pode fazer a simulação final se todos os clientes reportarem algo estranho .

— Lennard Fonteijn

1

Seu jogo é para um jogador, a única 'interação' com os outros jogadores é um líder. Você pode gerar uma instância para verificar uma simulação em seu servidor para cada envio. Você não precisa de todos os truques para garantir que a física seja a mesma com mais de 30 clientes. Portanto, acho que você não precisa de mais recursos do que já tem desde a física já está funcionando :).

Verificar se todos os resultados serão um pouco exagerados, você pode enviar a simulação compactada para o servidor sempre que alguém enviar uma pontuação para o líder, depois apenas verificar as 5% melhores pontuações no seu próprio servidor, ou talvez até o 1% ou mais mais inteligente apenas verifica novos recordes e assume que todos que não são melhores que o número 1 provavelmente têm uma simulação não enganada.

Eu não sei se a sua simulação é como, configure e não interaja (fácil de verificar) ou se os jogadores podem interagir com o sim enquanto ele está sendo executado, mas certifique-se de fazer sua física de tal maneira que diferentes flutuações representações de pontos não atrapalham as coisas e fazem com que uma execução válida pareça inválida.

— Roy T.
fonte

Não quero entrar em detalhes específicos da jogabilidade, mas você pode comparar meu jogo ao do jogo de dardos: depois de mirar e fazer o arremesso, a física assume o controle e não há nada que você possa mudar. não mais. Esse conhecimento mudaria sua resposta?

— Lennard Fonteijn

Não, isso não mudaria nada :). Apenas armazenar replays no servidor e só verificar aqueles suspeitos (por exemplo, novos recordes)

— Roy T.

1

Não faça isso, posso garantir que simular a física apenas no servidor é uma péssima idéia. O principal problema não é a carga do servidor, mas a capacidade de resposta. A capacidade de resposta do cliente será incrivelmente baixa. O jogador apertará um botão, então você terá que fazer uma ida e volta ao servidor antes de obter os resultados da simulação. Eu fiz variações disso no passado (principalmente pressionando apenas os botões), e os resultados não são bonitos e devem ser feitos apenas para jogos muito lentos que têm chances de se safar (e mesmo nesses casos, a percepção falta de capacidade de resposta é um grande problema).

Um esquema melhor que pretendo tentar na próxima vez em que esse tipo de cenário se apresentar é escolher para os jogadores um subconjunto muito pequeno da sua base de jogadores e simular para eles o servidor por um tempo e comparar seus resultados com os deles, sem o conhecimento deles. Se eles estão se desviando muito (você deve esperar alguns graus de divergência), então os classifica como trapaceiros em potencial e continua a simulá-los por mais algum tempo para confirmar. O que você obterá é algum tipo de curva de quanto um jogador legítimo diverge em comparação com o servidor, influenciado pelas condições da rede, etc., e você verá rapidamente que os trapaceiros estão fora dessa curva. Este sistema possui os seguintes benefícios:

Automatizado
Você não sacrifica a capacidade de resposta
Como você apenas simula um subconjunto muito pequeno da sua base de jogadores, a carga será gerenciável e até escalável (talvez você escolha menos jogadores para simular se a carga for alta)
Aplicável a todos os jogos que consigo pensar, tão altamente reutilizáveis

— Ylisar
fonte

Assim, como Roy, você basicamente diz: mantenha-o do lado do cliente, armazene "replays" quando os clientes enviarem uma pontuação e valide esses replays de vez em quando (nem todos, uma pequena porcentagem). E se, com base na pontuação que o cliente enviar, o pagamento for realizado - a parte de progressão do jogador, os créditos também podem ser comprados com dinheiro real (!!!) - você ainda recomenda esta abordagem? Se trapacear der quantias excessivas de créditos e eu validar apenas de vez em quando, eu basicamente perderia dinheiro. Você provavelmente pode sinalizar uma pessoa quando sua pontuação está acima de um determinado limite, mas haveria uma maneira melhor?

— Lennard Fonteijn

Se o mecanismo de física for determinístico (deveria ser) e o servidor simular usando o mesmo estado de início e entradas que o cliente (o que deve ser possível), os resultados deverão estar dentro dos limites razoáveis de erro de ponto flutuante (insignificante). Mesmo se houver efeitos aleatórios e não for possível passar pelo estado RNG, você pode passar os números aleatórios e usá-los para verificar (e até mesmo verificar sua distribuição, no caso de falsificar jogadas aleatórias fazer uma grande diferença na jogabilidade) .

— Ipeet 8/03

Os créditos estão envolvidos, é melhor verificar cada repetição, já que a trapaça não é mais para ficar no topo da lista de recordes, mas para ganhar dinheiro. Você quer muito mais segurança se houver dinheiro envolvido, não posso ajudá-lo lá.

— Roy T.

@RoyT. Provavelmente farei isso de qualquer maneira, mesmo que não pague dinheiro com base em créditos (alguém leu errado, eu acho?). Pretendo ter uma política de tolerância zero, portanto, basta enviar o arquivo de repetição para validação. Se é realmente suspeito, tomo uma atitude.

— Lennard Fonteijn

1

Como Daniel afirmou, o grande problema aqui serão os programas que executam a ação para o jogador; nenhuma inclinação física no jogo seria necessária se o jogador fosse um braço robótico com precisão normalmente resolvida para neurocirurgia.

— SomeGuy
fonte

Eu poderia ter sido um pouco claro. Meus jogos concederão créditos virtuais depois que você concluir um jogo. Você pode usar esses créditos para desbloquear novos conteúdos para brincar. Você também pode usar dinheiro real para comprar créditos para desbloquear o conteúdo mais rapidamente (lembre-se de que não é o Pay2Win, eu odeio isso). Não tenho intenções de pagar dinheiro real com base em créditos. Dito isto, os dardos eram apenas uma metáfora para descrever quanta influência um jogador tem no estado dos corpos rígidos, não tenho medo de "aimbots", pois isso lhe dará 0 vantagem.

— Lennard Fonteijn