Tutorial Multiplayer 3: pong

1

Index

Tagged

Stats

11,041 visits, 19,241 views

Tools

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 13 Aug, 2015. Last updated 25 Feb, 2019

O restante do grupo Signalling é similar ao exemplo de chat; no entanto ainda existem mais algumas diferenças para vir. Primeiramente como antes, uma vez conectados, ingressamos com nosso nome de usuário.

Para entrar no jogo, uma diferença é que usamos Auto-join room em vez de Join room. Se nós só usamos Join room, então todos acabam no mesmo jogo. 30 jogadores em um jogo que suporta apenas dois jogadores não é muito útil! Ao usar Auto-join room, uma vez que um quarto está cheio, os próximos jogadores a se juntar são enviados para uma nova sala. Neste caso, 30 jogadores agrupados serão designados para 15 jogos de 2 jogadores separados. Bloquear a sala quando cheia, também previne clientes atrasados; isso significa que uma vez que a sala está cheia, mesmo que alguns jogadores saiam, ninguém mais será adicionado ao jogo. Se a sala ficou desbloqueada um cliente recém logado pode ser enviado para a mesma sala, para preenchê-la novamente, mas como isso significa ter que lidar com clientes atrasados, vamos ficar com a simplicidade.

Uma vez dentro, estabelecemos se somos o "host". Fazemos o mesmo que no exemplo de chat: ou o grupo Host ou o Peer é ativado. No entanto, também precisamos lidar com o "paddle" e a bola existentes no layout, dependendo se nos tornamos "host". Se nós somos um cliente (peer), é fácil: nós apenas destruímos os objetos existentes no layout. O objeto "Sync" irá automaticamente criar, mover e destruir quaisquer objetos que estão presentes no host, incluindo o objeto que representa o nosso próprio jogador. O jogo também será iniciado apenas depois de nós nos juntarmos como um cliente, uma vez que o "host" já está lá, portanto, nós imediatamente definiremos o estado do jogo para "getready".

No entanto, quando formos o "host", adotamos o objeto "paddle" existente no layout como o nosso próprio objeto que controlamos. O objeto "paddle" tem uma variável de instância peerid. Esta armazena o ID atribuído ao cliente, e nos permite escolher qualquer instância do "paddle" e saber qual jogador que ela representa. Deve ser uma variável de texto, uma vez que IDs de clientes são curtas sequências de caracteres aleatórios. Nossa própria ID de cliente é atribuída a este objeto para indicar que representa a nós mesmos.

A ação Associate object with peer também é necessária para indicar ao "engine" multiplayer que esta instância representa um jogador na sala. Por padrão Sync object trata objetos como neutros, como objetos de cenário ou inimigos controlados por IA, e simplesmente certifica-se que todos vejam o mesmo número de objetos nos mesmos lugares. Usando Associate object significa que o objeto não é neutro e está associada a um cliente conectado na mesma sala, e lhe permite fazer mais automaticamente (tais como destruir o objeto quando o peer folhas). Neste caso, estamos adotando o objeto já no layout, por isso, associá-lo com a nossa própria identidade.

Os restantes eventos no grupo Signalling cobrem os erros de tratamento da mesma forma que a sala de chat fez. No entanto, há um evento extra que simplesmente exibe algumas estatísticas de conexão, incluindo o número de mensagens enviadas e recebidas enviados por segundo, a largura de banda resultante em kilobytes por segundo e a latência e PDV para o "host" (Estes irão mostrar como 0 para o "host", uma vez que eles não precisam se conectar a eles mesmos!).

  • 0 Comments

Want to leave a comment? Login or Register an account!