Pular para o conteúdo principal
Você pode implantar servidores multijogador do PlayFab em mais de uma dúzia de regiões do Azure. Há dois motivos para fazer isso:
  1. Regiões adicionais oferecem redundância. Se uma única região do Azure falhar, os jogadores poderão acessar servidores em outras regiões.
  2. Regiões adicionais permitem que os jogadores acessem servidores “próximos” e oferecem conectividade de baixa latência.
Ao chamar RequestMultiplayerServer, você especifica uma lista classificada de regiões do Azure que o PlayFab usa para atender à solicitação. O PlayFab tentará atender à solicitação usando a região classificada em primeiro lugar, mas, se não houver servidores em espera nessa região ou se a região tiver alguma outra falha, uma região menos ideal mais abaixo na lista será tentada. Sempre que possível, você deve usar os dados de latência dos jogadores para orientar a classificação das regiões do Azure usadas ao solicitar um servidor multijogador. O PlayFab fornece serviços e ferramentas para ajudar nessa tarefa.

Beacons de qualidade de serviço

O PlayFab opera beacons em todas as regiões do Azure usadas pelos servidores multijogador do PlayFab. Esses beacons refletem o tráfego UDP e podem ser usados para medir a latência com o transporte UDP. O uso do UDP é importante, porque a maioria dos jogos multijogador usa o transporte UDP para o tráfego de jogo mais crítico para o desempenho. Os provedores de serviços de Internet e outros elementos do ecossistema da Internet podem oferecer desempenho diferenciado para fluxos UDP, TCP e ICMP. Este é o fluxo típico para usar esses beacons no contexto de um dispositivo do jogador:
  1. Conecte o jogador ao PlayFab. Normalmente, isso é feito com LoginWithCustomID ou outra API de logon.
  2. Chame ListQoSServersForTitle. Isso fornece os nomes de host dos beacons de QoS do PlayFab. Uma implementação típica pode executar esse procedimento na página Menu Multijogador do jogo.
  3. Crie um soquete UDP.
  4. Envie um único datagrama UDP para a porta 3075 do servidor de QoS. O conteúdo da mensagem deve começar com 0xFFFF (1111 1111 1111 1111).
  5. O servidor responderá com um único datagrama, com os 2 primeiros bytes do conteúdo da mensagem “invertidos” para 0x0000 (0000 0000 0000 0000). O restante do conteúdo do datagrama será copiado do ping inicial.
  6. Meça o tempo entre o envio da mensagem UDP e o recebimento de uma resposta.

Usando o SDK de qualidade de serviço

O SDK C# e o SDK multiplataforma (CPP) do PlayFab fornecem uma implementação do código de ping de QoS. Você pode criar um SDK e usá-lo como biblioteca auxiliar nos seus jogos para PC, referenciar o pacote NuGet do C# ou usar o código como exemplo para outras plataformas. Cada API retorna um QosResult que contém uma lista classificada de regiões junto com o tempo médio de ping para cada região.

C#

Há APIs de QoS disponíveis no SDK C#. Uma implementação de exemplo, WindowsRunnerCSharpClient, está disponível no repositório gsdkSamples. O código está localizado em PlayFabQosApi.cs. Parâmetros:
  • timeoutMs: o tempo limite (em milissegundos) aplicado a cada tentativa de ping (padrão: 250 ms).
  • pingsPerRegion: o número de tentativas de ping a serem feitas em cada região (padrão: 10). Aumentar esse número aumentará o tempo de execução, mas reduzirá a chance de resultados imprecisos.
  • degreeOfParallelism: o número máximo de pings a serem feitos em paralelo (padrão: 4). Aumentar esse número reduzirá o tempo de execução, mas a contenção de rede pode causar resultados imprecisos se esse número for muito grande.

C++

Há duas APIs de QoS disponíveis no SDK multiplataforma (CPP) do PlayFab. O código está localizado em PlayFabQosApi.cpp. Parâmetros:
  • numThreads: o número máximo de pings a serem feitos em paralelo. Aumentar esse número reduzirá o tempo de execução, mas a contenção de rede pode causar resultados imprecisos se esse número for muito grande.
  • timeoutMs: o tempo limite (em milissegundos) aplicado a cada tentativa de ping (padrão: 250 ms).
Última modificação em 30 de outubro de 2026