Pular para o conteúdo principal
Este tópico descreve como um título confirma que jogadores suficientes ingressaram e conseguem se conectar quando são combinados em uma sessão de destino. Um grupo de jogadores é combinado em uma sessão de destino pelo matchmaking SmartMatch. O título deve tomar medidas para confirmar que jogadores suficientes ingressaram, para que eles consigam se conectar uns aos outros, se necessário. Esse processo é conhecido como inicialização da sessão de destino. Para jogos que usam topologias de rede ponto a ponto, um aspecto importante da inicialização da sessão de destino é a medição e a avaliação da qualidade de serviço (QoS). As operações associadas são as seguintes.
  • A medição da latência e da largura de banda entre consoles XBOX One (ou posteriores) ou entre consoles e servidores
  • A avaliação das medições resultantes para determinar se a conexão de rede entre os nós é boa
O fluxograma a seguir ilustra como implementar a inicialização da sessão de destino e as operações de QoS. Imagem de um fluxograma de QoS de matchmaking que ilustra como implementar a inicialização da sessão de destino e as operações de QoS

​
Inicialização gerenciada

O Multiplayer Session Directory (MPSD) oferece suporte a um recurso chamado inicialização gerenciada, por meio do qual ele coordena o processo de inicialização da sessão de destino entre os clientes envolvidos em uma sessão. O MPSD acompanha automaticamente os estágios de inicialização e os tempos limite associados da sessão. O MPSD também avalia a conectividade entre os clientes, se necessário. A inicialização gerenciada é representada pela enumeração XblMultiplayerInitializationStage.
É altamente recomendável que seu título use o matchmaking SmartMatch para aproveitar o recurso de inicialização gerenciada pelo MPSD.

​
Episódios e estágios da inicialização gerenciada

Uma sessão de destino passa pela inicialização gerenciada sempre que o matchmaking adiciona novos jogadores à sessão. O SmartMatch adiciona membros à sessão com o estado de usuário Reserved, o que significa que cada membro ocupa uma vaga, mas ainda não ingressou na sessão. Cada grupo de novos jogadores dispara um novo episódio de inicialização. Quando a inicialização é concluída, cada jogador é aprovado ou reprovado no processo. Um jogador que conclui a inicialização com êxito pode jogar usando a sessão de destino. Um jogador que falha deve ser reenviado ao matchmaking para ser combinado em outra sessão. Nos casos em que uma sessão é enviada ao matchmaking com o parâmetro preserveSession definido como Always, os membros preexistentes da sessão não passam pela inicialização, porque o MPSD pressupõe que eles estejam configurados corretamente. Cada episódio de inicialização gerenciada consiste nos estágios a seguir.
  • Entrada: os membros da sessão se gravam na sessão para mudar seu estado de usuário de Reserved para Active. Eles podem carregar dados básicos, como um endereço de dispositivo seguro.
  • Medição: em topologias baseadas em pares, os membros da sessão medem a QoS entre si e, em seguida, carregam os resultados na sessão.
  • Avaliação: o MPSD avalia os resultados dos dois últimos estágios e, em seguida, determina se a sessão ou os membros foram inicializados com êxito.
O código do título opera na sessão para avançar cada jogador (e, portanto, a sessão) pelas fases de entrada e medição. Em seguida, o título pode começar a jogar ou voltar ao matchmaking depois que o estágio de avaliação tiver sido bem-sucedido ou falhado.

​
Configurando a sessão de destino para a inicialização

O título pode configurar o processo de inicialização gerenciada usando constantes na sessão de destino que está sendo inicializada. Essas constantes são definidas em /constants/system no modelo de sessão com a versão 107. Recomendamos essa versão de modelo. Você pode fazer os dois tipos de definições de configuração a seguir.
  • Definições que configuram o processo de inicialização gerenciada como um todo
  • Definições que configuram os requisitos de QoS
Para obter exemplos de modelos de sessão para cenários comuns de títulos, consulte Modelos de sessão multiplayer e Visão geral do Multiplayer Session Directory.
Se os requisitos de QoS não estiverem definidos na configuração de inicialização da sessão de destino, o estágio de medição durante a inicialização será ignorado.

​
Configurando a inicialização gerenciada como um todo

Para controlar a inicialização gerenciada de forma geral, defina os campos a seguir. Os campos a serem definidos para controlar a inicialização gerenciada fazem parte do objeto /constants/system/memberInitialization.
  • joinTimeout: especifica quanto tempo o MPSD aguarda a entrada de cada membro depois que o episódio de inicialização começa. O padrão é 10 segundos.
  • measurementTimeout: especifica quanto tempo o MPSD aguarda que cada membro carregue os resultados da medição de QoS depois que o estágio de medição começa. O padrão é 30.000 segundos.
  • membersNeededToStart: especifica o número de membros que devem concluir a inicialização com êxito para que o primeiro episódio de inicialização seja bem-sucedido. O padrão é 1.
Se esse limite não for atingido, todos os membros falharão na inicialização.

​
Configurando os requisitos de QoS

A QoS só é necessária durante a inicialização se o título usar uma topologia ponto a ponto ou par-host. Cada topologia corresponde a uma constante específica da topologia em /constants/system/.

​
Configurando os requisitos de QoS para a topologia ponto a ponto

É raro que os títulos definam requisitos de QoS para a topologia ponto a ponto. Essas definições são muito restritivas e causam problemas para jogadores que têm conversões de endereços de rede (NATs) estritas.
Você pode definir os requisitos de QoS da topologia ponto a ponto no objeto peerToPeerRequirements. Cada cliente deve conseguir se conectar a todos os outros clientes. O objeto peerToPeerRequirements tem os campos pertinentes a seguir.
  • latencyMaximum: especifica a latência máxima entre dois clientes quaisquer
  • bandwidthMinimum: especifica a largura de banda mínima entre dois clientes quaisquer

​
Configurando os requisitos de QoS para a topologia par-host

Você pode definir os requisitos de QoS da topologia par-host no objeto peerToHostRequirements. Cada cliente deve conseguir se conectar a um único host comum. Se esse objeto estiver configurado e a inicialização for bem-sucedida, o MPSD criará uma lista inicial de clientes que são possíveis hosts, conhecidos como candidatos a host. Defina os campos a seguir.
  • latencyMaximum: especifica a latência máxima entre cada par e o host
  • bandwidthDownMinimum: especifica a largura de banda mínima de download entre cada par e o host
  • bandwidthUpMinimum: especifica a largura de banda mínima de upload entre cada par e o host
  • hostSelectionMetric: especifica a métrica usada para selecionar o host

​
Confira também

Modelos de sessão multiplayer Visão geral do Multiplayer Session Directory
Última modificação em 8 de outubro de 2026