Tente manter isso o mais simples possível e as interfaces bem definidas e documentadas. Manter e depurar um sistema complexo na produção se transforma facilmente em um inferno. Portanto, se houver uma abordagem simples e complexa, pense duas vezes antes de prosseguir com a complexa.
Definindo Serviços
Acho que o primeiro passo é identificar os serviços e suas dependências : Conteúdo estático, autenticação, bate-papo local, canais globais de bate-papo, canais regionais de bate-papo, lista de amigos, guildas, bolsa / inventário, casa de leilões, mapa global, mundo, ...
Em seguida, para cada um desses serviços, decidiu se o cliente pode falar com eles diretamente. Por exemplo, é muito fácil deixar o cliente falar diretamente com os servidores responsáveis pelos Canais de bate-papo globais. Os servidores mundiais não precisam se envolver em mensagens de bate-papo. O bate-papo regional pode ser implementado da mesma maneira, mas os servidores mundiais precisam informar aos servidores de bate-papo quando os jogadores mudam de região. Novamente, eles não precisam se preocupar com as mensagens.
O terceiro passo é pensar no balanceamento de carga dentro de um serviço . Por exemplo, canais de bate-papo globais e regionais podem ser divididos em vários servidores com base em seus nomes. Provavelmente, é uma boa idéia não codificar essa divisão no cliente, mas fornecer um serviço de pesquisa.
Servidores mundiais
A parte mais difícil são geralmente os servidores mundiais , então estou começando com uma abordagem simples. Provavelmente, é uma boa idéia deixar o cliente falar diretamente com o servidor responsável pela região em que ele está. Portanto, ao fazer o login ou a região que cruza, o cliente deve ser informado a qual servidor se conectar.
A abordagem simples é dividir o mundo em regiões independentes . Com regiões independentes, quero dizer que um jogador não pode olhar de uma parte para outra e monstros não podem cruzar partes. Essas regiões são diferentes das regiões que o jogador vê com base na paisagem e na história do mundo exterior. Geralmente, a maioria dos monstros está nas masmorras e os jogadores tendem a aceitar que precisam atravessar um portal para entrar em uma masmorra. Especialmente se essas masmorras forem instanciadas por grupo de jogadores. Outros exemplos no mundo exterior são diferentes continentes e vales cercados por altas montanhas.
Uma abordagem contínua do mundo se torna complexa muito rapidamente, por isso faz sentido planejá-la bem: de quais informações o cliente precisa? Quais informações os servidores precisam compartilhar? O jogador irá interagir principalmente apenas com os objetos (incluindo monstros e NPCs) na mesma região. Você pode trapacear colocando objetos fora do intervalo de cliques da borda da zona. Isso significa que o cliente está interessado principalmente em informações somente leitura para zonas vizinhas. Nesses casos, os servidores da zona não precisam coordenar nada, exceto pela permissão de verificar se o player está perto o suficiente para conectar-se a uma zona vizinha.
Isso deixa apenas um número muito pequeno de casos difíceis nos quais objetos ou ações precisam atravessar uma borda do servidor. O que é bom, porque esses casos, como flechas e feitiços, são críticos para o desempenho. Pode ser uma boa idéia dividir o combate em ataque e defesa. Portanto, o servidor de um lançador de feitiços definirá os parâmetros de ataque, incluindo a posição do lançador. O servidor do defensor receberá a mensagem sobre o ataque e calculará o impacto. O servidor do invasor não precisa saber sobre o impacto; o cliente aprenderá sobre isso usando sua conexão somente leitura.
Dependendo da complexidade do modelo do seu player, pode levar alguns segundos para transferi-lo para outro servidor (o Second Life tem um grande problema com isso). O problema pode ser atenuado, preparando a transferência com antecedência quando o jogador se aproximar de uma borda virtual. Para que a maioria dos dados do player já esteja em cache no servidor de destino quando a transferência real acontecer.
Sumário
Divida o problema definindo serviços diferentes que podem ser divididos entre servidores com poucas dependências. Como próximo passo, veja como fazer o equilíbrio de carga nos serviços críticos. Delegue o trabalho de balanceamento ao cliente, instruindo-o a conectar-se diretamente aos servidores relevantes (obviamente, os servidores precisam verificar as permissões). Mantenha o mais simples possível, documente bem as responsabilidades dos vários serviços e servidores, forneça a opção para ativar a saída de depuração.
PS: Algumas dessas técnicas podem ser usadas para melhorar a confiabilidade. E lembre-se disso, porque o uso de muitos servidores implica um risco muito maior de que as coisas quebrem; não apenas no software, mas também no nível do hardware.