Tutorial Multiplayer 3: pong

1

Index

Taggé

Statistiques

10,882 visites, 18,993 vues

Outils

Partager

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

Grupo Signalling

Este grupo é semelhante ao exemplo de chat anterior, em que se trata da conexão ao servidor de sinalização, login, ingresso em uma sala e determinar se é o "host". No entanto, existem algumas diferenças fundamentais, agora que estamos lidando com objetos e sincronização em tempo real.

Primeiro de tudo, em On start of layout devemos configurar os objetos e dados que vão ser transmitidos. A primeira ação configura as entradas que os clientes enviam para o anfitrião. Para evitar fraudes (cheat), os clientes só enviam suas entradas para o host, que realiza os testes de colisão reais com os "paddles" e a bola. A única entrada que o cliente tem é a posição vertical (Y) do seu "paddle".

As entradas que os clientes enviam para o host são chamadas client input values. Neste caso, usamos uma entrada que nós nomeamos "y", para a posição Y do "paddle". Ele usa um inteiro de 16 bits, uma vez que só usa dois bytes e posições sub-pixels não importam. O valor de entrada também utiliza interpolação Linear. Isso significa que mesmo que as atualizações estejam vindo para o "host" com pouca frequência, o motor multiplayer pressupõe um valor intermediário assumindo que o "paddle" está se movendo de forma linear. Isso garante que o movimento da raquete seja suave. Se nós escolhermos None para a interpolação, o movimento de remo poderia muitas vezes parecer agitado.

A próxima parte do evento configura quais objetos e quais de suas variáveis de instância são sincronizados.

A primeira ação usa o objeto Multiplayer Sync object. Esta é a ação chave para indicar quais objetos devem ser enviados através da rede. Sincronizar um objeto é Uma Via de Mão Única: isso significa que o Host Informa aos Clientes quantos desses objetos existem e onde eles estão. Clientes só recebem esses dados e quaisquer alterações que os clientes fazem a estes objetos será ignorada e substituído! Os valores de entrada do cliente são as únicas maneiras que os clientes têm de afetar o jogo, e os únicos dados do jogo são os enviados a partir dos clientes para o host.

O "host" tem a versão oficial do jogo, e os clientes estão fazendo o seu melhor para mostrar o que o "host" tem. O "host" é o único responsável por criar, mover e destruir estes objetos; assim que ele faça isso, Sync object também fará com que os objetos sejam criados, movidos e destruídos pelos clientes conectados. Tudo isso acontece internamente no motor multiplayer, como conseqUência dessa ação.

Uma vez que Sync object moverá os objetos por si só, e somente o "host" está "realmente" executando o jogo, os clientes também desativam todos os comportamentos nos objetos. Por exemplo, a esfera tem o comportamento de bala (Bullet behavior). Apenas o "host" deve ter o comportamento habilitado. O comportamento da bala deve ser desativado quando atua como um cliente, uma vez que Sync object já estará movendo-o como ele se move no "host", e ter o comportamento ativado no cliente poderia fazer com que o comportamento entre em conflito com o que Sync object estiver tentando fazer. Neste exemplo, o comportamento de bala inicialmente está desativado, e ele estará habilitado nos eventos quando atuando na qualidade de "host".

"Sync object" pode atualizar a posição ou ângulo do objeto, ambos, ou nenhum. Neste caso, estamos interessados apenas na posição, uma vez que o ângulo do objeto não é importante para a jogabilidade e seria um desperdício de largura de banda enviar dados sobre ângulos de objetos. O parâmetro "Bandwidth" (largura de banda) permite que a taxa máxima de atualização do "host" possa ser reduzida. Isto normalmente não é necessário - consulte o manual para saber mais sobre a opção.

"Sync object", por padrão, não transmite quaisquer outros dados, e variáveis de instância não são atualizadas. Seria um desperdício atualizar automaticamente cada variável de instância, uma vez que algumas delas só podem ser usadas localmente. Após o uso de Sync object, nós podemos, opcionalmente, usar qualquer número de ações Sync instance variable para adicionar variáveis de instância para o "host" enviar também a seus clientes (e assim como "Sync Object", as variáveis de instância são atualizados automaticamente). É importante notar que Sync instance variable só pode ser usada depois de Sync Object. Por si só ele não faz nada; a ação significa "sincronize também esta variável para os objetos já sincronizados".

A única variável que sincronizar neste caso é points, variável do objeto "Paddle". Esta é uma maneira simples para que todos saibam pontuação de cada jogador.

A tag com o valor do cliente é usada se a variável de instância também corresponde a um valor de entrada do cliente. Isso não é necessário neste exemplo, mas é tratado no próximo tutorial.

O objeto bola também deve ser sincronizado, de modo que o jogador possa ver onde ela está! No entanto, não há necessidade de sincronizar outra coisa senão a sua posição.

Agora que todas as entradas do cliente e objetos sincronizados foram ajustados, a última ação em On start of layout é conectar-se ao servidor de sinalização.

  • 0 Comments

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