O que está envolvido na criação de um jogo de plataformas multiplayer em tempo real?


13

Estou criando um jogo de plataforma que possui um recurso "cooperativo" que eu gostaria de trabalhar através de redes / internet.

Agora, já li sobre programação de jogos em rede, incluindo artigos como o que todo programador precisa saber sobre redes de jogos e, portanto, entendo a diferença entre técnicas como a etapa de bloqueio ponto a ponto e as arquiteturas de previsão de servidor e cliente:

  • Concluí que para qualquer jogo em tempo real que será jogado pela Internet, o bloqueio ponto a ponto simplesmente não é uma opção.
  • Também estou preocupado que, mesmo para um jogo de plataforma, uma arquitetura simples de cliente-servidor (sem algum tipo de previsão do cliente) resulte em jogabilidade degradada devido ao atraso entre a ação e a reação causada por uma ida e volta a um servidor. (Dito isto, quero eliminar a necessidade de um servidor central e, portanto, apenas um dos jogadores, o cliente, realmente experimentará esse atraso).

Isso deixa a previsão do cliente, mas mesmo para um jogo simples como um jogo de plataforma, isso ainda parece bastante complexo.

Como eu criaria um sistema preditivo de trabalho para um jogo multiplayer de plataformas?


1
Uma coisa que você terá muito menos com que se preocupar em um jogo cooperativo é trapacear;)
Jonathan Connell

Eu sinalizei isso como não construtivo. As perguntas colocadas ("Quanto trabalho é escrever um jogo em rede que usa a previsão do cliente? Vou acabar com metade da minha base de código composta por código de rede?") São muito amplas e não são específicas para o problema. A resposta seria basicamente "depende", o que não é uma boa resposta.
22411 TravisG

-1, "Quanto trabalho" é subjetivo.
Tetrad

1
A quantidade de trabalho não é subjetiva, pois fica sozinha, mas depende de alguns fatores (tamanho do jogo, requisitos de precisão etc.) que podem afetar se for muito trabalho, pouco trabalho ou algo entre eles (embora que tipo de trabalho é uma pergunta melhor); no entanto, acho que o OP está realmente perguntando quanto esforço é necessário e qual o tamanho da parte do código-base que esse tipo de código seria. Conforme redigido, pode ser muito amplo. Eu escolhi uma interpretação mais restrita e respondi isso. Eu acho que o PO deveria se esforçar um pouco mais para restringir as perguntas a alguns pontos muito específicos.
Nate

@ Tetrad Desculpe - eu tentei fazer essa pergunta o mais objetiva possível, mas minha pergunta se resume a "é difícil criar um sistema preditivo de cliente que funcione para um jogo do tipo Y" - se não, então vou aprender como eu mas meu tempo é limitado, então aprender que dá muito trabalho depois de X dias de jogo é tarde demais. Eu tentaria fornecer mais detalhes sobre Y, mas não quero tornar a pergunta "muito localizada". O principal problema aqui é o movimento, que é comum a todos os plataformas (quero que outros achem essa pergunta útil). Se eu puder melhorar essa pergunta, as sugestões serão apreciadas.
11137 Justin

Respostas:


5

Eu não acho que metade da sua base de código se transformará em código de rede se você decidir implementar um recurso como este.

Na minha opinião, a maneira mais simples de fazer isso é configurar um servidor "central" (mesmo que isso signifique que um jogador "hospede" o jogo e depois se conecte ao seu próprio servidor) que aceite todas as entradas do usuário o mais rápido possível e envia de volta para cada cliente.

No cliente, você implementa isso de maneira diferente do que se estivesse fazendo um jogo cooperativo para dois jogadores localmente, exceto que você lê P1 no teclado e P2 na rede.

Você precisará que o servidor envie um estado completo do jogo de vez em quando, e os dois clientes podem ajustar para o novo estado autoritativo do servidor ou deslizar para o novo estado (por alguns segundos). A menos que você tenha uma perda terrível de pacotes ou toneladas de clientes por servidor, essa abordagem deve ser suficiente para a situação descrita.


O que é tão fácil quanto a abordagem de um servidor cliente (exceto que um cliente hospeda o servidor -> você não precisa de um servidor dedicado, mas precisa ir com algo semelhante à linha UDP + NAT Punchthrough que precisa de um servidor deduzido). Em segundo lugar, você propõe o método lockstep (como você está falando sobre o envio de gamestates completos), esse não é o IMHO, o melhor método se o jogo for executado na Internet (provavelmente na LAN), onde o cliente-servidor é muito mais fácil implementar.
Valmond 14/07

1
Não, estou sugerindo que você envie estados completos do jogo ocasionalmente, para que o cliente possa ter certeza de que não está muito longe.
Nate

2

Eu tenho um jogo no estilo mMORPG totalmente funcional com previsão do cliente (o jogo está longe de terminar, mas roda 'OK') e tenho algo ao longo de 40.000 linhas de código para o servidor e o dobro para o cliente (adicione a mesma quantidade para ferramentas, etc. .). A previsão provavelmente não é mais do que algumas centenas de linhas (se é que isso é verdade) e toda a rede divide algumas milhares de linhas, mas não mais do que 5.000 (depende um pouco de onde você desenha a linha).

Pergunta confusa resposta confusa ;-)


2

Uma proporção significativa do código de rede pode ser independente do jogo que você está jogando. Por isso, e como você é novo em redes, a primeira coisa que sugiro que você faça é encontrar bibliotecas que farão esse trabalho para você. RakNet por exemplo.

Uma coisa que você deseja no código do jogo é a capacidade de lidar com vários estados diferentes do jogo, que você pode usar para interpolação e previsão. É bastante simples de projetar com antecedência, mas pode ser uma quantidade significativa de trabalho se você estiver modificando um jogo para um jogador existente.

Observe também que, se você quiser que estranhos joguem um jogo ponto a ponto pela Internet, provavelmente precisará de pelo menos um servidor em algum lugar que lide com o lobby / organização de partidas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.