Melhor solução para jogo Android em tempo real para vários jogadores [fechado]

11

Pretendo criar um jogo em tempo real para vários jogadores para Android (de 2 a 8 jogadores) e considero qual a melhor solução para a organização de vários jogadores:

  1. Tornar servidor no PC e cliente no celular, toda a comunicação passar pelo servidor (ClientA -> PC SERVER -> All Clients)

  2. Use bluetooth, ainda não usei e não sei se é difícil criar multijogadores no bluetooth

  3. Torne o servidor em um dos dispositivos e outros dispositivos se conectem (através da rede, mas não sei se é difícil resolver problemas com dispositivos através do NAT?)

  4. Outra solução?

Piotrek
fonte
3
Você planeja que este seja um jogo apenas local ou deseja que as pessoas possam brincar com outras pessoas na Internet? Você está hospedando máquinas para jogos?
Tétrada
Escolho um jogo multiplayer em pequena escala, pretendo criar um jogo onde as pessoas se encontrem na sala e possa jogar o mesmo jogo (este é o tópico da minha tese: multiplayer na plataforma móvel). Mas se alguém tiver uma solução interessante para jogar pela internet, também estou interessado.
Piotrek

Respostas:

2

Aviso Legal; Eu não fiz muito com java e a plataforma android.

No entanto, minha experiência mais extensa com os idiomas '.net' nas plataformas Windows Mobile, juntamente com a plataforma Windows, é que entre 75 e 90% de todo o código necessário para criar e manter uma conexão de dados de rede ou Bluetooth são mantidos / com suporte no sistema operacional ou nas bibliotecas que precisariam acessar o hardware.

Até agora, isso também parece verdade no Android, com o SO expondo métodos para criar conexões de dados via Bluetooth ou internet, além de ativar / desativar o respectivo hardware.

Eu imaginaria que o Bluetooth seria o método preferido de conexão, pois esse seria o menos caro para implementar (sem servidores). E permita uma reunião / jogo mais local. O Bluetooth é bastante fácil de usar. Ele funciona de maneira semelhante aos soquetes de rede normais quando você sabe a qual dispositivo deseja se conectar.

Os outros estão corretos, pois o Bluetooth v2.0 / v2.1 atualmente não é capaz de suportar grandes cargas de dados. Isso mudará com o eventual spread da v3.0 e superior. e existem maneiras de contornar essa limitação.

Por enquanto, embora exista um conceito simples, solução ainda complexa, que você pode querer experimentar. Uso-o há algum tempo, é semelhante ponto a ponto, mas envolve ter o jogo hospedado em todos os dispositivos simultaneamente. Dessa forma, se uma conexão for temporariamente perdida, desacelerada ou um jogador cair por qualquer motivo, outros jogadores não serão afetados. Isso permite que os usuários que desistiram de entrar no jogo em andamento com pouca ou nenhuma interrupção para outros jogadores ou seu próprio jogo.

CON: Cada jogador realmente jogaria sua própria instância algo única do jogo, que seria vinculada aos outros jogadores para impedir que os jogos se desviassem muito da sincronia entre si.

CON: O código de suporte pode ser extenso / complexo e difícil de entender, dependendo do que você deseja alcançar.

PRO: Não é necessário servidor ou dispositivo central! Não é necessária manutenção de $$$.

PRO: Uma troca pesada de dados só ocorreria quando um jogador (re) ingressasse ou um jogo fosse inicializado. - Mesmo isso pode ser reduzido, garantindo que todos os jogos sejam gerados e progredindo da mesma maneira por todos os jogadores. POTENCIALMENTE reduzindo o consumo de energia que ocorre devido ao uso intenso da rede.

PRO: os dados se tornam menos sensíveis ao tempo, pois os dispositivos já teriam todos os dados necessários para manter o jogo sem os outros jogadores. Permitindo que você se concentre mais na experiência de jogo real para usuários individuais, em vez de um grupo de jogadores.

Faltava-me tempo para implementar um mecanismo de jogo completo que o utiliza. Os jogos que fiz foram limitados a recriar jogos semelhantes ao Monopoly e Uno, que pareciam funcionar extremamente bem.

O mais fácil foi o que emulou o Uno. Eu basicamente empilhei os decks dos perdedores depois que um jogador venceu, para garantir que ele vencesse todos os jogos. Em 95% das vezes, eu não sabia dizer que não estava jogando exatamente o mesmo jogo que todos os outros.

Comecei a construir um jogo semelhante ao Master of Orion II, mas o jogo em si era um pouco demais para eu realizar sozinho.

Grothos
fonte
9

Depende muito do jogo, mas alguns amigos e eu estávamos pensando nos mesmos problemas apenas alguns meses atrás, e aqui está o que determinamos. Estou de bom humor novamente.

Servidor baseado em computador

Prós

  • Experimentada e verdadeira
  • Escalável

Contras

  • Precisa escrever um "multi-servidor" que possa hospedar vários jogos ao mesmo tempo. Isso provavelmente usará uma tecnologia ligeiramente diferente da do seu telefone Android. Você ainda pode usar java, mas ainda pode usar os pacotes do Android?
  • Pode ser caro para executar e manter
  • Você pode retirá-lo um dia por vários motivos. Os fãs podem não ficar felizes se o servidor cair apenas alguns meses após a compra do jogo.

Ponto a ponto com um deles no controle

Prós

  • Servidores ad-hoc onde os amigos podem se juntar a outros quando quiserem
  • Pouco ou nenhum custo operacional de sua parte
  • O código do servidor será misturado ao código do cliente, sem a necessidade de escrever um aplicativo de servidor separado.

Contras

  • Precisa escrever um localizador de pares simples e centralizado. (Eu fiz o meu no php + mysql em algumas centenas de linhas fáceis)
  • Os servidores estão sendo executados em telefones. Telefones podem ser lentos. Todos os telefones de destino poderão hospedar um jogo?
  • O que acontece se o telefone do servidor for desconectado?
  • Mais fácil que o cliente-servidor para os hackers entrarem

Quanto ao bluetooth, eu esperaria que isso fosse semelhante ao método ponto a ponto acima. Também não acho que você deva ter problemas com o NAT.

EDIT : Também depende muito da sua experiência. Eu começaria escrevendo alguns jogos cliente / servidor relativamente pequenos para pegar o jeito da rede primeiro. É um tópico difícil, fácil de se errar da primeira vez. Eu peguei a minha na terceira tentativa. Siga padrões conhecidos e não tente inventar algo sozinho.

John McDonald
fonte
Não acho que isso possa ser feito via bluetooth, duvido que seja compatível com transmissões: AFAIK conecta apenas um host a outro, possui um número máximo de conexões muito baixo e é lento.
o0 '.
4

Uma das maiores considerações que você precisa fazer é a confiabilidade. Telefones não são muito confiáveis; de fato, você provavelmente deve presumir que em um jogo com 8 jogadores é provável que alguém desconecte (chamada recebida, recepção ruim, jogador sai ...)

Com isso em mente, entenda que você deve minimizar o impacto de um usuário desconectado. Na sua segunda opção, você essencialmente transformou um telefone no servidor. Se esse telefone for MIA, o jogo terminará efetivamente para todos os jogadores.

John abordou os prós e contras de uma arquitetura tradicional de servidor <-> cliente. Esta é provavelmente a maneira mais flexível de fornecer uma experiência multiplayer confiável para todos.

Você também pode considerar uma técnica ao longo das linhas de uma simulação de etapa de bloqueio. Isso pode ser implementado de maneira puramente ponto a ponto. A idéia geral é que todo cliente deve enviar sua atualização (série de comandos ou falta dele) a cada etapa da simulação. Em uma etapa de simulação subsequente, os comandos de cada jogador são aplicados à lógica do jogo. Muitos jogos RTS empregam esse tipo de esquema de rede.

A técnica pode ser difícil de implementar e pode ser muito difícil de depurar. É certamente mais difícil do que ter uma arquitetura cliente-servidor mais tradicional. Isso também implica um atraso entre a entrada de um jogador e quando o jogo responde à entrada. No entanto, se um jogador desistir, os jogadores restantes poderão excluí-lo do jogo e continuar. Também pode potencialmente diminuir o tráfego de rede em comparação com outros esquemas.

Se você quiser aprender mais sobre essa técnica, comece com este excelente artigo sobre o assunto. Caso contrário, eu desencorajaria fortemente um esquema de rede em que um único telefone é responsável por uma sessão multiplayer e sugeriria a arquitetura mais simples do servidor do cliente <->.

entalhe
fonte