A chave para projetar a arquitetura do jogo é considerar a eficiência desde o início. Concentrar-se em métricas, registros, telemetria e monetização muito cedo pode resultar em inchaço excessivo na arquitetura do jogo. Empacotar tudo isso em seu servidor de jogos em tempo de execução pode, na verdade, reduzir o retorno sobre o investimento (ROI) e aumentar o custo total de propriedade.

Em vez disso, comece com um produto mínimo viável (MVP) o mais cedo possível. Coloque o servidor em execução, o cliente funcionando, seu código de rede e o sistema de matchmaker bloqueados e, em seguida, desenvolva a partir daí. Você também deve considerar a possibilidade de contratar seu provedor de hospedagem com antecedência, pois ele pode oferecer soluções e infraestrutura pré-construídas que podem economizar seu tempo de desenvolvimento.

Quando se trata do design de seu jogo, o que significa simplicidade? A imagem acima mostra um projeto complexo com não apenas uma instância de servidor de jogos, mas muitos processos auxiliares na mesma máquina, incluindo matchmakers, registro e executáveis de métricas.

Essa complexidade não se torna necessariamente aparente até que você comece a fazer testes em escala, que é quando você pode começar a perceber que essas coisas não funcionam bem juntas quando há milhares de jogadores. Além disso, os serviços auxiliares podem não ter nenhuma barreira de recursos, portanto, podem começar a canibalizar os recursos da máquina e afetar o desempenho do jogador. Manter as coisas simples pode ajudar a reduzir esses problemas.

Em termos de design de servidor de jogos, simples é empacotar as coisas em uma única instância de servidor, como um único executável e um matchmaker resiliente (talvez hospedado em um serviço de backend em vez de em uma máquina). Dessa forma, quando um dos servidores de jogo é perdido, ele não leva outros jogadores com ele e a área afetada permanece pequena. Em escala, se você tiver um servidor de jogos com esse design que apresente mau funcionamento, isso não afetará a experiência do jogador.

Para ajudar a minimizar o risco de custo, não mantenha processos auxiliares como depuração, observadores e matchmaking na mesma máquina. Se você tiver uma situação em que um servidor de jogos morre e tiver máquinas em nuvem para as quais ele foi dimensionado, estará deixando os processos auxiliares "zumbificados". Eles ainda estão consumindo recursos, o que custa dinheiro ao seu estúdio, e você não tem como desativá-los.

Em vez disso, considere a possibilidade de fazer com que os processos auxiliares, como a criação de partidas e a depuração, sejam subprocessos do servidor de jogos - mantenha a simplicidade. Então, se você perder o servidor do jogo, ele levará os subprocessos com ele, em vez de deixá-los em execução em segundo plano. Nesse caso, se o servidor parar de funcionar, você poderá ativar outro sem os recursos e custos extras associados aos processos "zumbificados".

Em jogos multijogador com sessões de longa duração, pode haver problemas como vazamentos de memória, uso crescente de RAM e outros, que podem não aparecer até que você esteja executando o jogo em escala.

Aqui estão alguns riscos associados a sessões de jogo de longa duração:

• Ataques DDoS: Como o IP da instância do jogo não muda com um modelo de sessão de jogo persistente, há a possibilidade de ataques DDos.
• Altos custos de nuvem: São necessários muitos recursos caros para manter um jogo que está sempre, ou quase sempre, ativo, mesmo que os jogadores não estejam jogando.
• Interrupções devido à aplicação de patches: Pode ser difícil gerenciar a correção, pois pode haver partidas ativas que precisariam ser encerradas para corrigir o jogo, resultando em uma experiência ruim para o jogador.

Ainda há riscos e considerações sobre a experiência do jogador para sessões de jogos curtos. Mesmo que seu jogo para dois jogadores dure apenas dois minutos, facilitar centenas de milhares (ou mais) dessas partidas simultâneas pode ser caro e apresentar riscos.

Aqui estão algumas considerações para sessões de jogos curtos:

• Alta carga de back-end: As constantes chamadas de API ao seu back-end para facilitar as sessões de jogos curtos podem representar uma carga enorme, portanto, precisam ser resilientes.
• Difícil para a infraestrutura: Quando o servidor é reiniciado entre sessões curtas, você pode ver o pico de CPU e RAM no início do carregamento dos processos, o que pode ser caro.
• Requer um matchmaker robusto: Com sessões curtas, você precisa de um matchmaker eficaz para lidar com os tíquetes de matchmaking para novas sessões, reconexões e muito mais.
• Qualidade de serviço (QOS): Você precisará de um provedor que lhe permita enviar ao cliente do jogo uma lista de endereços IP em tempo real para determinar qual deve ser a região do servidor com base em telemetria e dados reais, em vez de localização física.
• Precisa de métricas e dados de telemetria: Se algo der errado, é mais provável que o jogador saia e inicie outra sessão em vez de relatar um erro. Se você não estiver obtendo métricas e telemetria dessas sessões curtas, poderá perder coisas que estão dando errado no jogo.

Aqui estão os prós e os contras dos jogos baseados em sessões curtas:.

Prós:

• Não há necessidade de estabilização para longos períodos de execução
• Permite a aplicação mais rápida de patches
• Facilidade de redução de escala
• Sem estado ocioso
• Os arquivos de registro de cada sessão facilitam a solução de problemas

Contras:

• Mais retornos de chamada, o que significa mais carga em escala
• O custo de computação em nuvem para reinicializações não é trivial em escala
• Condições da corrida
• Picos de MEM/CPU na inicialização
• Mais complexidades para o matchmaking
• Os problemas de desempenho da máquina podem estar ocultos

Em jogos multijogador persistentes (como MMOs), pode haver certos problemas e riscos. Por exemplo, o suporte a situações como migrações de jogadores entre servidores significa que você precisa de um sistema de back-end mais robusto, incluindo servidores caros e discos rígidos potentes.

Aqui estão algumas considerações para projetos de sessões de jogos persistentes:

• O orçamento pode ser uma preocupação: São necessários sistemas de back-end mais robustos para fazer com que as sessões persistentes funcionem, portanto, você precisará calcular quanto serão os custos de manutenção com base nos usuários para entender se esse é o design de sessão certo para você.
• A nuvem pode não ser viável: Devido às altas demandas de uma sessão de jogo persistente, a nuvem pode ser muito cara para o seu projeto.
• A qualidade da rede é extremamente importante: A latência e o gerenciamento da latência farão com que a sessão de jogo persistente seja decisiva para os jogadores, portanto, testar sua rede antecipadamente e com rigor é essencial para uma boa experiência do jogador.
• A aplicação de patches é difícil e arriscada: O tempo de inatividade relacionado à manutenção nunca é uma ótima experiência para os jogadores, mesmo que seja necessário para melhorar a experiência geral. A comunicação com sua comunidade sobre o tempo de manutenção é fundamental. Você também pode considerar a possibilidade de ter várias versões do jogo em execução ao mesmo tempo e fazer patches com o passar do tempo.

Aqui estão os prós e os contras dos jogos persistentes baseados em sessões:

Prós:

• Os servidores estão sempre ativos e em funcionamento
• Possibilidade de loop de jogo mais curto
• Menos carga em seu back-end

Contras:

• Mais difícil de projetar
• Instabilidade ao longo do tempo
• Limpeza das sessões
• Projeto de estado ocioso necessário
• Precisa ter consciência de que é um casamenteiro
• A aplicação de patches A/B pode demorar mais

É uma boa ideia se preparar para possíveis problemas de experiência do jogador em escala. O lançamento, a execução e a atualização de um jogo multijogador podem ser caóticos, por isso é importante fazer testes situacionais de "resiliência ao caos" e garantir que o back-end do seu jogo esteja configurado para lidar com esse caos.

Por exemplo, o que acontece se todos saírem do jogo e tentarem voltar ao mesmo tempo para a criação de partidas? Descobrir a resposta do back-end a essa situação e configurá-lo para lidar com esse problema pode evitar dores de cabeça (e ajudar a proteger sua reputação) a longo prazo.

É provável que você tenha que corrigir seu jogo durante o lançamento. Por isso, é importante criar sua infraestrutura com a capacidade de aplicar patches durante a produção e o lançamento. Isso pode ajudar a tornar o caos do dia do lançamento e a aplicação de patches em tempo real muito mais rápidos e suaves, e o impacto sobre os jogadores pode ser limitado.

Uma maneira de abordar isso é executar várias versões do seu jogo simultaneamente. No entanto, você também terá que se certificar de que sua infraestrutura possa lidar com várias versões. Além disso, você precisará ter uma área restrita com todas as diferentes versões.

Se você já tiver incorporado a capacidade de executar várias versões simultaneamente, não haverá tempo de inatividade nem interrupção para os jogadores quando você fizer a correção.

Testes frequentes de escala são essenciais, portanto, encontrar um provedor que possa ajudá-lo com isso deve ser uma consideração importante ao selecionar seus serviços.

Um aspecto importante a ser testado em escala é o tesselamento e a desfragmentação do servidor. O tesselamento do servidor é uma importante consideração de custo. Essencialmente, você deseja usar primeiro máquinas de metal baratas para hospedagem. À medida que sua base de jogadores flutua, você também desejará remover rapidamente as máquinas de nuvem mais caras, o que é mais econômico.

O Game Server Hosting (Multiplay) evita a alocação em máquinas mais caras, o que nos permite removê-las mais rapidamente quando o número de jogadores estiver diminuindo.

A capacidade do nosso sistema de fazer isso depende da vida útil de sua correspondência. As durações mais curtas das partidas nos permitem encerrar mais rapidamente as alocações em máquinas caras. Partidas mais longas significam que não podemos desligar as máquinas até o final da partida.