Como posso criar um jogo multiplayer ponto a ponto? [fechadas]

Como posso fazer um jogo multiplayer p2p? Eu gostaria de ter um jogo multiplayer sem servidor. Mas então, como todos os clientes se conhecem?

Por que o protocolo p2p é tão famoso na transferência de arquivos, mas não nos jogos multiplayer?

Os jogos ponto a ponto geralmente ainda têm um host de jogos. É o host do jogo que lança o jogo na lista de jogos principais e aceita novas conexões. Sempre que o host do jogo aceita um novo cliente para o jogo, ele notifica todos os clientes existentes sobre o novo cliente, para garantir que eles se conectem ao novo cliente.

A maneira mais simples de implementar o p2p é com um lobby. Todos os clientes se conectam ao host em um lobby (ou sala de bate-papo). Quando o host está pronto, o jogador pressiona start e todos entram no jogo ao mesmo tempo (comumente usado em jogos de estratégia). Uma abordagem mais complexa é usar "drop-in drop-out" onde os jogadores podem entrar e sair no meio do jogo, no entanto, isso é muito mais complexo de implementar em um jogo p2p e requer um recurso chamado migração de host.

Um bom número de jogos usa redes ponto a ponto, incluindo a maioria dos títulos de estratégia, esportes e direção. Quase todos os jogos Xbox360 e PS3 usam redes p2p. A arquitetura cliente-servidor é usada principalmente em jogos de tiro em primeira pessoa ou MMO.

Geralmente, o cliente-servidor é mais fácil de implementar, pois apenas 1 máquina não conhece todo o estado do jogo; os clientes são basicamente apenas renderizadores com alguma previsão para tornar as coisas mais suaves.

Quando você cria um mecanismo p2p, todos os clientes precisam de um estado completo do mundo do jogo e todos são obrigados a permanecer sincronizados.

Para obter mais detalhes sobre arquiteturas p2p e cliente-servidor, sugiro que você leia o seguinte artigo: O que todo programador precisa saber sobre redes de jogos .

E se você é novo na rede, confira os outros ótimos artigos desse site. Glenn é um gênio da rede.

Há muitas razões pelas quais o P2P não é popular nos jogos, principalmente devido ao atraso. Todo mundo é tão lento quanto o jogador mais lento. Não estamos falando de largura de banda aqui, mas de tempo de ping.

O p2p pode transferir toneladas de dados, mas com um ping bastante alto, os jogos precisam transmitir quantidades muito pequenas de dados, com tempo mínimo de ping.

Existem alguns aspectos interessantes sobre sistemas ponto a ponto e jogos de ação. Tentei publicá-las como um comentário no blog de Glenn Fiedler, mas aparentemente ele não gosta de se provar errado e, em vez disso, puxou o artigo inteiro. Está no Internet Archive, caso você queira lê-lo.

Ele não deixou o comentário on-line, então vou citar aqui:

A sugestão ponto a ponto da primeira postagem é realmente um ponto de partida interessante, embora às vezes seja um pouco ingênuo: a primeira possibilidade seria combinar o sistema com um modelo de cliente / servidor padrão com previsão conforme descrito em sua postagem sobre redes de jogos. O ping P2P mais baixo reduziria drasticamente o atraso de previsão entre os jogadores, dependendo da localização: o efeito provavelmente não seria visível para a maioria dos jogadores dos EUA, mas aqui na Europa os pings de mais de 200 são normais na maioria dos servidores e uma conexão direta reduziria o previsão de atraso para a de um servidor europeu.

Uma verdadeira abordagem P2P sem servidor é um pouco mais complexa: a principal preocupação com redes descentralizadas é garantir consistência, especialmente se a simulação puder sofrer efeitos borboleta devido ao tempo ligeiramente diferente dos comandos enviados pela rede ou a problemas de ponto flutuante. Isso é possível através da rede do estado de cada objeto (jogadores, NPCs, ...) pelo menos periodicamente. Nem seria necessário fazê-lo para todos os objetos de uma só vez, e cada cliente poderia se apossar de certos objetos. A conexão em rede de objetos suficientes em um determinado período de tempo deve reduzir a diferença que se acumula entre cada sincronização de um objeto, o suficiente para se tornar irrelevante, mesmo para intervalos de sincronização de um segundo ou mais.

O segundo problema com sistemas P2P é a segurança, mas isso pode ser resolvido com uma correção relativamente pequena neste caso: Os clientes podem usar suas simulações de física para coletar informações sobre o nível de erro em cada objeto de física. A física manipulada sempre resulta em um erro maior; portanto, os clientes simplesmente "votam" para se desconectar do ponto que controla um objeto suspeito. Além disso, as mensagens de controle para objetos não-físicos são encaminhadas entre clientes com base em sua importância: as atualizações do Player podem ser encaminhadas aleatoriamente, atualizações importantes e pouco frequentes sempre devem ser enviadas, mas ainda para um player aleatório. Dessa forma, um jogador teria que controlar uma grande parte dos clientes conectados para conseguir trapacear de qualquer maneira perceptível.

[...]

Você pode encontrar o tópico que estou referenciando em http://www.devmaster.net/forums/showthread.php?t=14640 .

Acho que alguém mencionou os problemas de firewall ponto a ponto em um dos tópicos do artigo. Uma solução possível seria um NAT-Punchthrough:
- Visão geral do NAT Punchthrough
- Comunicação ponto a ponto entre tradutores de endereços de rede

Não existe uma taxa de sucesso de 100%, então você deve pedir aos jogadores para abrir uma porta de qualquer maneira.

Um bom exemplo de jogabilidade 'verdadeiro ponto a ponto' seria um jogo de estratégia em tempo real, como Starcraft.

Em um jogo com centenas de unidades / projéteis em movimento, não é prático enviar repetidamente posições / estados de unidades pela rede para todos os outros jogadores; portanto, uma solução aqui é que todos os jogadores executem a (exatamente) simulação em sincronia.

Quando um jogador executa uma ação, o comando / ordem ('mover zergling para X, Y') pode ser enviado a todos os outros jogadores, para ser executado por todas as instâncias da simulação uma fração de segundo depois.

Nessa situação, se algum jogador se desconectar, o jogo poderá continuar - como não é necessário que um servidor / host esteja executando o jogo, os jogadores restantes poderão continuar.

No entanto, manter os jogos sincronizados não é trivial, você precisa usar um timestap fixo para as atualizações da lógica do jogo e deve ter muito cuidado com o uso e propagação de geradores de números aleatórios, para garantir que as simulações não divergam!

Seria um pouco falso afirmar que não é famoso por jogos quando a maioria dos jogos de estratégia em tempo real (séries Star Craft, séries Command e Conquer) e muitos jogos FPS (Call of Duty: Modern Warfare 2) os usam.

Dito isto, como se aprende sobre o jogo depende do serviço de correspondência / lobby que você usa ou cria. Mas mesmo depois que alguém aprende sobre o jogo, ainda pode haver um ou mais pares iguais a outros. Considere o caso de 3 clientes que desejam jogar, um atrás de um nat aberto, 2 atrás de nats restritos (fechados). O ponto aberto nat pode obter conexões dos outros dois. Mas o 2 strict não pode se conectar diretamente um ao outro, eles exigirão que o nat aberto retransmitir os pacotes. Se o ponto aberto nat cair do jogo, outro relé precisaria ser encontrado ou o jogo seria interrompido.

você também pode querer conferir o Badumna (www.badumna.com), que afirma ser uma solução de rede ponto a ponto para jogos online. Parece fazer a sincronização do estado do jogo de maneira distribuída e, de acordo com o site deles, está chegando uma versão em Flash.

Você provavelmente deseja rodar com um jogador (nós o chamaremos de "Anfitrião") como um servidor não autorizado. Todos os outros jogadores comunicarão o que estão fazendo com nosso anfitrião, e o anfitrião transmitirá as mensagens aos outros jogadores.

Você provavelmente também deseja passar uma lista de quais computadores estão conectados ao player de hospedagem, para que, se eles abandonarem, um novo host possa ser escolhido de alguma forma e começar a se comunicar com os demais jogadores.

A documentação do smartfoxserver pode ajudá-lo e / ou você pode querer usá-lo também para o seu jogo. Você acabou de incorporá-lo ao jogo do cliente, em vez de ter um programa separado de cliente e servidor.

Estou um pouco interessado nesse assunto. Você está dizendo que há muitos problemas ao criar um jogo p2p em vez de um modelo clássico de cliente-servidor. Mas tenho certeza de que o p2p é como cliente-servidor, mas todos os pares têm a chance de se tornar um servidor. Sobre o LAG Se você adicionar mais uma máquina como servidor, há mais probabilidades de que muitos clientes estejam mais distantes do servidor, mas usando o p2p não há máquinas extras no lobby, você pode gerenciar os testes de latência e criar grupos com ping mínimo. Sobre a geração de tráfego, como aprendi, você deve pedir aos clientes que transmitam menos que menos, ou seja, os clientes precisam descobrir que todos os outros clientes estão dispostos a dizer.

Se você estiver criando um mmorpg de aparência relativamente simples, com baixos requisitos de sistema, sugiro criar um programa interno que crie uma "frequência" com base no conteúdo da pasta do jogo e na consistência dos arquivos. Isso fará com que as pessoas com a mesma "frequência" sejam reproduzidas nos mesmos canais. Clientes modificados, manipulados ou normais serão separados. Isso funcionará apenas para hacks ou mods nativos, mas tenho certeza de que isso cobre todos os trapaceiros "burros". Combinado com o método de verificação de erros mencionado por uma pessoa, significa pouca ou nenhuma moderação necessária. No que diz respeito às portas, basta cobrir a porta 52225 com um processo em segundo plano que a mantém conectada aos roteadores sem portas de acionamento.