A arquitetura desenvolvida por nós baseia-se em algumas camadas:

• Camada dos Clientes: Onde estão os usuários do jogo.
• Rede de Clientes: Podendo ser a mesma, como a Internet ou outra, desde que suporte o protocolo UDP e TCP/IP de comunicação.
• Camada de Slave Servers: Servidores cuja função é diminuir a carga do sistema na hora de atualizar os clientes.
• Rede de Servidores: Em geral rápida, funcionando como meio de comunicação entre os Slave Servers e o Master Server.
• Master Server: Servidor único responsável pela simulação do jogo e pelo controle de carga no sistema. É através dele que os clientes se conectam, sendo redirecionados para os slaves. Também pode ativar um novo slave server se a carga do sistema estiver alta.

Como vemos no diagrama, a conexão ocorre da seguinte maneira:

1. Cliente requisita para o Master Server sua entrada no jogo. O Master Server computa essa entrada no seu modelo de jogo (simulação) e
2. Redireciona o cliente para o Slave Server menos carregado. Caso o sistema esteja chegando perto de sua capacidade máxima, o Master pode ativar um novo Slave Server para atender as requisições que (provavelmente) virão subsequentemente
3. A conexão é estabelecida entre o Cliente e o Slave Server.

A aplicação cliente, usada pelo usuário para jogar o jogo, tem uma estrutura simples:

• A parte principal é o objeto Jogo, que é responsável por armazenar informações referentes aos outros jogadores - representados pelos objetos Nave - e também por receber as informações vindas do servidor por ConexãoInput e repassar ao servidor os comandos que o usuário efetuou no seu dispositivo de entrada (Input) através da ConexãoOutput.

• A situação do jogo é desenhada na tela do usuário pela GUI, que consulta o Jogo quando precisar redesenhar a tela.

• O MasterServer recebe mensagens dos SlaveServers através da ConexãoInput e envia através da ConexãoOutput.
• As mensagens, antes de chegarem ao Simulador, podem ficar no Pool até que o Simulador possa recebê-las.
• O Simulador é responsável por simular o jogo, calculando, por exemplo, a posição dos torpedos (por causa da inércia) ou mesmo colisões entre Naves, Torpedos e Asteróides, que são todos objetos que implementam uma mesma interface, a Simulável.
• O Timer diz ao MasterServer quando ele deve consultar o Simulador para pegar o estado do jogo e repassá-lo aos usuários.

Comprometimento do jogo devido à latência da rede MultiBatt foi projetado para funcionar sobre redes de baixa latência. Por latência, se entende o tempo que um pacote leva para atravessar a rede (atingir o destino e voltar). Assim, devido ao mecanismo síncrono de atualização de tela, o jogo fica vulnerável à travamentos periódicos.
Podemos analisar o quanto a latência influi no desempenho do jogo através de uma fatia de tempo denominada "sensibilidade do usuário" (t[su]). Essa sensibilidade reflete o tempo máximo que a tela deve ser "redesenhada" de modo que o usuário não perceba um travamento. Portanto:

O tempo total (T) é dado pela soma dos tempos acima, ou seja, T = t[e] + t[s] + t[r].
O termo t[s] em geral é pequeno devido ao elevado poder de processamento geralmente encontrado nos servidores dedicados. Assim, os termos t[e] e t[r] são os mais significativos e refletem diretamente no tempo de sensibilidade:
    Se T > t[su] então teremos um travamento pontual no jogo e o usuário perceberá uma partida mais lenta e com menor rapidez de resposta aos comandos de teclado.
    Se T < t[su] então teremos um jogo dentro dos padrões aceitáveis de funcionamento.

Experimentalmente, o olho humano capta 30 quadros a cada segundo, ou seja, uma atualização de tela a cada 33,3 milissegundos. Assim, chegamos a um valor inicial para t[su], que seria da ordem de 30 milissegundos. Portanto uma rede que tenha latência próxima ou maior do que esse valor calculado impede um funcionamento correto do jogo.