O documento descreve uma arquitetura cliente-servidor para jogos, onde: 1) Um servidor hospeda o estado do jogo e se comunica com vários clientes; 2) Cada cliente se comunica apenas com o servidor para enviar ações e receber atualizações de estado; 3) Quanto mais clientes, maior a largura de banda necessária no servidor, mas não nos clientes individualmente.

1. Arquitetura Cliente - Servidor
Prof. Fernando Vieira da Silva, MSc.

2. Arquitetura Cliente - Servidor
● Uma das instâncias do jogo funciona como um servidor
● Cada cliente só se comunica com o servidor
● Para n clientes, haverá n conexões com o servidor
Topologia Cliente - Servidor

3. Largura de Banda
Supondo que:
● cada cliente envia b bytes por segundo
● servidor envia c bytes por segundo
● Banda de Entrada do Servidor: b*n bytes por segundo
● Banda de Saída do Servidor: c*n bytes por segundo
● Banda de Entrada de cada Cliente: c bytes por segundo
● Banda de Saída de cada Cliente: b bytes por segundo

4. Largura de Banda
Ou seja:
● Mais Clientes → Aumentar a largura de banda do servidor
● Mais Clientes → Não afeta largura de banda dos clientes, em
teoria…
MAS, na prática, podem haver mais objetos para replicar
(mais tráfego de rede)

5. Modelo de Servidor Autoritário
● Usado pela maioria dos jogos Cliente – Servidor
● Se o estado do jogo em um cliente discorda com o do
servidor, o que vale é o do servidor
● Pode apresentar “lag”. Exemplo: em um FPS, uma
“requisição” de tiro precisa ser enviada para o servidor, que
processa e então envia o resultado para todos os clientes

6. Modelo de Servidor Dedicado
● Somente executa o estado do jogo e repassa aos clientes
● Headless, ou seja: não possui interface gráfica

7. Modelo de “Listen Server”
● Um dos jogadores também é o servidor
● É diferente da abordagem ponto-a-ponto…
● Vantagem: Pode reduzir custos de infraestrutura
● Desvantagem: Pode dar a oportunidade de “cheats” para o jogador “host” (se for
autoritário)
● Alguns jogos usam Migração de Host caso o jogador servidor caia.

8. Estudo de caso: Robo Cat Action
● Controles:
● Girar o gato (rotacionar) nos sentidos horário e anti-horário
● Mover o gato para frente e para trás
● Atirar uma bola e reduzir a saúde de outro gato (cada gato tem 9 vidas no total)
● Coletar ratos ao passar sobre eles

9. Estudo de caso: Robo Cat Action
● Servidor precisa saber a saúde do gato, para fazer respawn quando atingir 0
● Cliente precisa saber a saúde para exibir na tela
● Cliente e servidor possuem códigos separados

10. Arquitetura Robo Cat Action
● Drop In/ Drop Out: Deve aceitar a entrada de um novo
jogador ou a saída de um jogador a qualquer momento
1) Cliente envia mensagem solicitando entrada no jogo
2) Servidor recebe o pacote, atribui um ID de jogador, e
responde o cliente
3) Quando o cliente recebe seu ID, ele salva e começa a
enviar e receber informação de replicação para o servidor
4) Servidor envia informações de respawning de objetos para
os clientes

11. Arquitetura Robo Cat Action
● Servidor Autoritário
● Há 2 tipos de pacotes que o cliente pode receber: boas
vindas ou estado (aka. Dados de replicação)
● O servidor ignora pacotes vindos de clientes desconhecidos
(se não for de boas vindas)
● O servidor cria um proxy para cada novo jogador (aka.
Objetos que representam o estado de cada cliente)

12. Replicação de objetos
● Replicação pode ser: criação, alteração ou destruição de
objetos do jogo
● Quando há alguma alteração relevante (ex: gato atirando uma
bola), o cliente envia um pacote input para o servidor

13. Exercício
Defina uma arquitetura Cliente-Servidor para o Robo Cat
Action usando Unity LLAPI.
● Quantos canais de comunicação você deve usar?
● Qual QoS você deve usar para cada canal?
● Qual tipo de informação você vai enviar em cada canal?
Dica: tome o modelo do Starsiege: Tribes como
exemplo.

14. Fim!