Arquitetura do lado do servidor para jogos online


7

basicamente, eu tenho um cliente de jogo que se comunica com um servidor para quase todas as ações necessárias, o jogo está em Java (usando LWJGL) e agora vou começar a criar o servidor.

A base do jogo é normalmente um cliente se comunicando apenas com o servidor, mas exigirei mais tarde que vários clientes trabalhem juntos para algumas funcionalidades.

Eu já li como o servidor de autenticação deve ser separado e pretendo fazê-lo. O problema é que eu sou completamente inexperiente nesse tipo de programação do lado do servidor. Tudo o que eu já programei foram aplicativos da Web JSF.

Eu imagino que farei conexões de soquete para praticamente todas as comunicações de jogos, já que o HTML é muito lento, mas ainda não sei por onde começar no servidor.

Eu gostaria de ler o material ou as diretrizes sobre onde começar, qual arquitetura o servidor do jogo deve ter e talvez algumas sugestões sobre estruturas que possam me ajudar a obter a comunicação cliente-servidor.

Eu procurei no JNAG, mas não tenho experiência com esse tipo de coisa, então não sei dizer se é uma camada de mensagens sólida e boa.

Qualquer ajuda é apreciada, obrigado !

EDITAR:

Apenas um pouco mais de informação sobre o jogo. Pretende-se ser um jogo muito complexo, com várias funcionalidades, tornando algumas funcionalidades um "programa" dentro do programa. Não é um jogo comum, como FPS ou RPG, mas pretendo ter muitos usuários usando esses muitos "programas" diferentes dentro do jogo.

Se eu não fosse suficientemente claro, eu realmente apreciaria as pessoas que já desenvolveram jogos com arquitetura cliente / servidor java, como se comunicaram, qualquer estrutura, API, sistema de mensagens etc.

Não é uma questão de falta de conhecimento da linguagem, é mais uma questão de conselho, por isso não acabo criando algo que funcione, mas nos estágios posteriores terá que ser reescrito por qualquer motivo limitador. PS: desculpe se o meu inglês não é perfeito ...


11
Os servidores do Multiverse são escritos em Java, até onde se lembra, mas parece que você já tem um jogo. Ainda assim, há uma boa alto nível visão geral você pode olhar para aqui: update.multiverse.net/wiki/index.php/...
DrDeth

Enquanto a arquitetura do servidor do jogo será definida pelo jogo em geral. É muito dependente de plataforma e gênero. Se você está planejando para muitos usuários, o Java é uma boa oportunidade de usar o [Elastic Beanstalk] da Amazon [1]. Essa é uma ótima maneira de escalar seu servidor sob demanda. Talvez você deva nos contar mais sobre o jogo - o JNAG pode ser mais do que o que você precisa, ou seja. em um jogo baseado em turnos de no máximo 4 jogadores. [1]: aws.amazon.com/elasticbeanstalk
Konrad K.

Respostas:


12

Infelizmente, não conheço nenhum (bom) recurso ou livro on-line sobre esse tópico. E eu não sei Java. No entanto, como ainda não há respostas, compartilharei algumas dicas da experiência pessoal.

Primeiro, você precisa de um mecanismo RPC rápido e confiável , ou pelo menos da fila de mensagens. É isso que deve ser usado para a comunicação cliente-servidor e servidor-servidor. Não sei se existem soluções prontas para Java. Com o .NET, sempre criamos nosso próprio método personalizado, pois esse mecanismo é realmente importante. Geralmente, é usado um protocolo leve de mensagens binárias sobre TCP, mas outras opções podem ser melhores dependendo do tipo de jogo. Uma estratégia baseada em turnos pode ser melhor com XML ou SOAP, e um shooter em ritmo acelerado pode garantir UDP.

O mínimo absoluto para o sistema de mensagens é a capacidade de invocar ações remotas de maneira confiável, enquanto garante seu pedido . Uma adição realmente útil é o suporte ao padrão de solicitação-resposta, em que uma ação remota pode retornar algum tipo de resultado ao seu iniciador. Isso não é necessário, mas pode facilitar sua vida.

Depois de ter suas mensagens, pense em particionar seu servidor. Provavelmente, uma única máquina servidor não será suficiente para hospedar o jogo para todos os jogadores. Você precisa considerar cuidadosamente quais tarefas podem ser independentes umas das outras e, portanto, podem ser delegadas a diferentes servidores. Autenticação e logon são os candidatos mais óbvios para esse particionamento. Entre outros, estão cálculos estatísticos e de classificação, comunicação com o banco de dados (um servidor para atuar um cache de banco de dados especializado). O problema dos jogos MMO, ao contrário dos aplicativos da Web, é que eles tendem a ser altamente controlados pelo estado, com muitos dados necessários para cada jogador. E a maioria das operações exige acesso a todos ou quase todos esses dados.

Mesmo se você usar um único servidor, precisará praticamente tirar proveito de vários processadores. Qualquer servidor MMO é um programa altamente simultâneo (nosso servidor atual possui cerca de 30 threads simultâneos). Para ter alguma esperança de resolver problemas de sincronização, é necessário isolar segmentos diferentes. Como servidores diferentes, eles terão seus próprios dados e se comunicarão usando algum tipo de interface de transmissão de mensagens. Possivelmente até o mesmo RPC usado pela sua rede, se for rápido o suficiente.

Então você tem seu banco de dados. Os jogadores de MMO geralmente fazem muitas coisas e geram muitas conversas no mundo do jogo, que precisam ser salvas no banco de dados. Todos os servidores com os quais trabalhei não os salvaram imediatamente - em vez disso, as alterações foram acumuladas na memória e salvas em massa a cada 5 minutos. Isso permite que o jogo progrida de maneira mais suave, com o custo de um possível atraso na escrita. Esse atraso é o principal motivo para ter uma máquina separada para comunicação com o banco de dados.

Geralmente, os jogos MMO usam bancos de dados relacionais como back-end de dados, mas acredito que os bancos de dados NoSQL possam ser melhores. Normalmente, você tem um monte de dados em seu banco de dados para cada personagem, carrega tudo quando o referido personagem faz login e muito raramente, se é que alguma vez faz alguma consulta complexa. Este modo de operação parece ser o forte do NoSQL. Dito isto, ainda não utilizei um banco de dados NoSQL com um servidor MMO real, portanto, posso estar errado aqui.

Outra coisa relacionada ao banco de dados sobre a qual quero alertá-lo é essa. Muitos desenvolvedores, especialmente no início do ciclo de produção, são tentados a armazenar dados de "design de jogos" em um banco de dados. Estou falando de coisas como parâmetros de itens e NPCs, habilidades e outras coisas assim. Não faça isso. Na verdade, essas coisas são dados estáticos que não mudam, a menos que haja uma atualização do servidor; e esses dados são sempre necessários pelo servidor. Normalmente, você não fará nenhuma consulta, exceto SELECT * ...na inicialização do servidor. Portanto, você realmente não precisa de um banco de dados, e ter essas coisas em um banco de dados tem muitas desvantagens. Por um lado, você não pode colocar um banco de dados sob controle de origem.

Estes são três componentes principais para uma arquitetura de servidor MMO: comunicação em rede, particionamento lógico e acesso ao banco de dados. Toda lógica usando esses três provavelmente é muito dependente do jogo. Talvez eu tenha mais alguns conselhos se você fizer perguntas mais específicas e nos contar mais sobre o jogo.


Gostaria muito de receber mais conselhos de você, mas não consigo encontrar uma maneira de me comunicar diretamente com você (um PM ou algo assim). Só não quero revelar o interior do meu jogo publicamente.
21311 Draiken

Você pode entrar em contato comigo por e-mail e / ou googletalk no cthulhu dot no gmail dot com.
Nevermind

4
Embora eu sugira fortemente que você peça o máximo possível aqui, e não em particular. Dessa forma, beneficiaria mais pessoas e você obteria melhores respostas.
Nevermind

0

Você provavelmente deseja examinar a programação de soquetes. Aqui está uma introdução básica que ajudará você a começar.

Ou simplesmente faça uma pesquisa no Google por soquetes java e você encontrará bastante material.


11
Eu já usei soquetes antes, usei RMI, EJB e outras formas de comunicação, mas o problema não é o básico de usá-lo, é como DEVE ser usado ou por que esse ou aquele modo deve ser usado.
Draiken

Ah ok. Eu interpretei mal sua pergunta então. Desculpa.
bummzack
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.