> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Práticas recomendadas e lista de verificação de lançamento

> Práticas recomendadas e uma lista de verificação de lançamento para o PlayFab Multiplayer Servers, abrangendo desenvolvimento, testes com LocalMultiplayerAgent, escalabilidade e operações ao vivo.

* Faça com que o processo do seu servidor de jogo seja encerrado quando a sessão de jogo terminar, por exemplo, quando a partida acabar ou quando o último jogador conectado sair. Se o seu jogo permitir que os jogadores se reconectem, aguarde primeiro um curto período de carência. O MPS não encerra uma sessão de jogo por você. Um servidor permanece Active até que seu processo seja encerrado. O MPS não remove servidores Active quando o seu build reduz a escala, portanto, um servidor que nunca é encerrado continua usando capacidade pela qual você paga. Quando o processo é encerrado, o MPS o substitui por um novo servidor. Para obter mais informações, consulte [Ciclo de vida de um servidor multijogador](/pt-BR/services/playfab/multiplayer/servers/multiplayer-game-server-lifecycle).

* Inicie um temporizador quando o servidor se tornar Active, por exemplo, quando o método `ReadyForPlayers` do Game Server SDK (GSDK) retornar `true`. Se nenhum jogador se conectar em alguns minutos, encerre o processo. Dessa forma, um servidor em que ninguém ingressa, por qualquer motivo, não permanece Active indefinidamente. Baseie o tempo limite no tempo que seus jogadores costumam levar para se conectar.

* Registre um retorno de chamada de desligamento do GSDK que faça qualquer limpeza de que seu servidor precise e, em seguida, encerre o processo. O GSDK não encerra o processo por você. O MPS chama seu retorno de chamada quando você chama a API [ShutdownMultiplayerServer](xref:titleid.playfabapi.com.multiplayer.multiplayerserver.shutdownmultiplayerserver). Chame essa API somente em uma emergência, por exemplo, para encerrar servidores de jogo travados. Não a use para encerrar sessões de jogo em circunstâncias normais. Seus servidores de jogo devem ser encerrados por conta própria, conforme descrito anteriormente nesta seção. Se o processo ainda estiver em execução 15 minutos após uma solicitação de desligamento, o MPS o encerrará à força. Para obter mais informações, consulte [Desligando normalmente o servidor de jogo](/pt-BR/services/playfab/multiplayer/servers/integrating-game-servers-with-gsdk#gracefully-shutting-down-your-game-server).

Veja a seguir algumas práticas recomendadas durante as várias etapas do ciclo de vida do jogo para aproveitar ao máximo o PlayFab Multiplayer Servers (MPS):

## Desenvolvimento

* Use o [LocalMultiplayerAgent (LMA)](https://github.com/PlayFab/MpsAgent) para testes iterativos na sua estação de trabalho local. Isso economiza tempo e dinheiro e também simplifica a depuração, já que todos os artefatos são executados localmente. A ferramenta é de código aberto, e contribuições/melhorias são sempre bem-vindas. Mais detalhes sobre como usá-la estão disponíveis [aqui](/pt-BR/services/playfab/multiplayer/servers/locally-debugging-game-servers-and-integration-with-playfab)

* Use [Agendamentos](/pt-BR/services/playfab/multiplayer/servers/scheduled-standby) para configurar agendamentos concretos e economizar nos custos de servidores standingBy. Por exemplo, se todos os testes e validações forem realizados durante o horário comercial, o agendamento poderá ser definido para ter servidores standingBy somente durante o horário comercial. Não há custo extra para configurar agendamentos.

* Use [métricas de VM](/pt-BR/services/playfab/multiplayer/servers/vm-metrics) ou seus próprios [criadores de perfil](/pt-BR/services/playfab/multiplayer/servers/attaching-a-profiler) para decidir quantos servidores de jogo executar em uma VM do tamanho escolhido. Faça testes de carga com todos os servidores da VM Active e cheios de jogadores. Os servidores na mesma VM podem ser alocados e iniciar suas sessões de jogo quase ao mesmo tempo, portanto, inclua esse caso nos seus testes. Deixe uma margem de CPU: em uma VM com a CPU saturada, as alocações podem ser lentas ou falhar.

* Use [Logs do servidor](/pt-BR/services/playfab/multiplayer/servers/archiving-and-retrieving-multiplayer-server-logs) e [Despejos de memória](/pt-BR/services/playfab/multiplayer/servers/crash-dump-collection) para uma análise mais aprofundada.

## Preparação para o lançamento

* Direcione suas solicitações de alocação para [aliases de build](/pt-BR/services/playfab/multiplayer/servers/allocating-with-build-alias). Eles ajudam na migração contínua de clientes de jogo para servidores de jogo mais novos como parte de atualizações de servidor e também podem ajudar a gerenciar problemas de cota (discutidos mais adiante).

* Use os [Beacons de QoS](/pt-BR/services/playfab/multiplayer/servers/using-qos-beacons-to-measure-player-latency-to-azure) para identificar a região mais próxima de um cliente de jogo e usá-la nas alocações. Eles também podem ser combinados com o [PlayFab Matchmaking](/pt-BR/services/playfab/multiplayer/matchmaking) para agrupar clientes com latências semelhantes e alocar um servidor mais próximo deles.

* Use toda a amplitude da cobertura geográfica do PlayFab MPS para garantir que os servidores de jogo estejam sempre localizados perto dos seus jogadores. Considere usar várias regiões em uma área geográfica para permitir maior disponibilidade em caso de falhas regionais. Por exemplo, ter servidores em NorthEurope e WestEurope e especificar as duas regiões na solicitação de alocação (em ordem de prioridade) permite que uma alocação que falhe em uma região tenha êxito na próxima região da lista.

* Ao alocar em um [alias de build](/pt-BR/services/playfab/multiplayer/servers/allocating-with-build-alias), liste em `PreferredRegions`, em ordem de preferência, todas as regiões que oferecem uma experiência aceitável aos seus jogadores. O MPS tenta suas regiões nessa ordem, e os pesos dos builds apenas decidem qual build atende a uma solicitação dentro de uma região. Um build com peso 0 nunca é usado, nem mesmo como fallback. Para obter detalhes, consulte [Fallback para outros builds e regiões](/pt-BR/services/playfab/multiplayer/servers/allocating-with-build-alias#fallback-to-other-builds-and-regions).

* Se [RequestMultiplayerServer](xref:titleid.playfabapi.com.multiplayer.multiplayerserver.requestmultiplayerserver) falhar com o erro `MultiplayerServerTooManyRequests`, nenhum dos builds tinha um servidor StandingBy em nenhuma das regiões solicitadas. Apesar do nome, esse erro não significa que suas solicitações estão sendo limitadas. Para evitá-lo:

  * Liste várias regiões próximas em `PreferredRegions`.
  * Defina seus servidores em espera para o pico esperado.
  * Defina o número máximo de servidores de cada região do build com uma margem acima do pico esperado. O MPS não cria servidores além desse máximo, mesmo quando os servidores em espera se esgotam.

* Solicite [cota](/pt-BR/services/playfab/multiplayer/servers/quota-changes) bem antes do lançamento, para cada família de VM e região que seus builds usam. Quando você implanta um novo build, o build antigo e o novo usam núcleos ao mesmo tempo até que os servidores do build antigo sejam esvaziados, portanto, solicite cota suficiente para ambos. Para distribuir sua capacidade, considere colocar builds que usam famílias de VM diferentes atrás do mesmo alias, para que as alocações possam recorrer a outra família de VM na mesma região.

* Pode haver casos em que o SKU de máquina virtual do seu servidor de jogo não esteja disponível em todas as regiões em que o jogo será lançado. Nesses casos, use aliases para dividir builds por SKUs e regiões ou use substituições de região em um único build para escolher um SKU de máquina virtual diferente apenas para essas regiões.

* Use o [StandingBy dinâmico](/pt-BR/services/playfab/multiplayer/servers/dynamic-standby) para escalar os servidores de jogo verticalmente com base na demanda. Isso, combinado com a configuração padrão de standingBy estático, pode oferecer uma maneira econômica de lidar com alta demanda durante o lançamento.

* Configure o monitoramento dos seus servidores de jogo antes do lançamento. Ative as [métricas de VM](/pt-BR/services/playfab/multiplayer/servers/vm-metrics) para ver métricas de CPU, memória, disco e rede das suas VMs no Game Manager. Para um monitoramento mais avançado, use [VmStartupScript](/pt-BR/services/playfab/multiplayer/servers/vmstartupscript) para instalar suas próprias ferramentas de monitoramento nas VMs. O repositório [VmStartupScriptGallery](https://github.com/PlayFab/VmStartupScriptGallery) tem exemplos que enviam métricas de VM e logs de servidores de jogo para serviços como Azure Monitor, Application Insights e Azure Data Explorer.

## Dia do lançamento

* Acompanhe o lançamento bem-sucedido do seu jogo com os painéis e fluxos de eventos no [PlayFab Game Manager](https://developer.playfab.com/). Reserve um tempo para comemorar, você mereceu!

## Pós-lançamento

* Os jogos costumam entrar em um ritmo de demanda que, novamente, pode ser organizado em [Agendamentos](/pt-BR/services/playfab/multiplayer/servers/scheduled-standby). Use os agendamentos junto com o [StandingBy dinâmico](/pt-BR/services/playfab/multiplayer/servers/dynamic-standby) para uma escalabilidade econômica do jogo após o lançamento.

* Use [aliases de build](/pt-BR/services/playfab/multiplayer/servers/allocating-with-build-alias) para atualizações de servidores de jogo e para direcionar gradualmente o tráfego para a nova experiência de jogo.

* Ao mover um alias para novos builds, defina os servidores em espera dos builds antigos como 0 para que o MPS possa liberar as VMs ociosas deles. Exclua os builds antigos somente depois que seus servidores Active forem esvaziados. Além disso, mantenha as regiões solicitadas pelos seus clientes em sincronia com as regiões em que os builds do alias estão implantados. Se nenhum dos builds do alias estiver implantado em nenhuma das regiões solicitadas, a solicitação falhará com `MultiplayerServerNotFound`.


## Related topics

- [Noções básicas e práticas recomendadas de login](/pt-BR/services/playfab/identity/player-identity/login/login-basics-best-practices.md)
- [Práticas recomendadas e recomendações de experimentos](/pt-BR/services/playfab/live-service-management/game-configuration/experiments/experimentation-keys.md)
- [Lista de verificação de prontidão para publicação de jogos XBOX](/pt-BR/publishing/game-publishing/publishing-processes/managed-creators/publishing-processes-game-publishing-readiness-checklist.md)
- [PAGE · Listas de verificação de acessibilidade de pré-planejamento e pós-evento](/pt-BR/build/game-principles/accessibility/page/page-checklists.md)
- [Práticas recomendadas de atualização de conteúdo](/pt-BR/build/core-features/common/packaging/packaging-updates.md)