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.