> ## 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. # Configurando o matchmaking no Partner Center > Configure o matchmaking SmartMatch no Partner Center para títulos do XBOX, incluindo modelos de sessão, regras de hopper e regras de equipe para a combinação de jogadores compatíveis. Este tópico descreve como configurar o Partner Center para selecionar jogadores compatíveis. [Configuração das operações de tempo de execução do matchmaking SmartMatch](#SmartMatch-config) [Definindo regras de equipe durante a configuração do SmartMatch](#SmartMatch-defining) ## Configuração das operações de tempo de execução do matchmaking SmartMatch Toda a configuração do matchmaking SmartMatch ocorre por meio do [Partner Center](https://partner.microsoft.com/dashboard). ### Configuração do modelo de sessão de matchmaking O matchmaking tem dois tipos de sessões relacionadas. * A *sessão de tíquete da partida*, que é a entrada do serviço de matchmaking * A *sessão de destino da partida*, que é a saída Ao configurar modelos de sessão, você deve criar um modelo para cada tipo de sessão. Para uma sessão de tíquete, você pode usar um modelo dedicado. Como alternativa, você pode reutilizar um modelo de uma sessão de lobby ou de outra sessão que não se destina a ser usada para jogabilidade. A sessão de tíquete não deve ter verificações de qualidade de serviço (QoS) habilitadas e não deve ser marcada com a capacidade "gameplay". Para uma sessão de destino, você deve usar um modelo destinado à jogabilidade com matchmaking. Ele deve ter configurações que habilitem verificações de QoS entre pares antes do início da jogabilidade e deve ser marcado com a capacidade "gameplay". Com a interface do usuário de configuração do Partner Center, você pode mapear cada sessão para um ou mais hoppers, cada um contendo regras que determinam como as sessões são combinadas nesse hopper. Para obter mais informações, consulte Configuração básica de hoppers para matchmaking, a seguir. ### Configuração básica de hoppers para matchmaking Esta seção define os campos usados para configurar os campos básicos do hopper. Após essa configuração, você deve configurar as regras do hopper, conforme descrito na seção Configuração das regras do hopper mais adiante neste tópico. A captura de tela a seguir mostra o editor de hoppers. Ele é descrito nas seções a seguir. Captura de tela que mostra o editor de hoppers #### Nome O nome do hopper usado ao enviar uma sessão ao matchmaking. Esse nome deve corresponder ao valor passado como parâmetro para o método [XblMatchmakingCreateMatchTicketAsync](/pt-BR/reference/live/xsapi-c/matchmaking_c/functions/xblmatchmakingcreatematchticketasync) durante a criação do tíquete de partida. #### Tamanho mínimo/máximo do grupo Os tamanhos mínimo e máximo do grupo de jogadores a ser criado a partir das sessões no hopper. O serviço de matchmaking tenta criar um grupo combinado o maior possível, até o tamanho máximo do grupo. No entanto, ele cria um grupo combinado se conseguir reunir jogadores suficientes para atingir o tamanho mínimo do grupo. #### Ciclos de expansão de regras SHOULD Para uma regra SHOULD, se nenhuma partida bem-sucedida for encontrada, o serviço de matchmaking tenta aumentar o espaço de pesquisa e flexibilizar as regras de matchmaking fornecidas ao longo do tempo. Esse processo é realizado em vários ciclos, conforme especificado no campo Should Rule Expansion Cycles. No último ciclo de expansão, as regras SHOULD são descartadas para que não impeçam mais a combinação de tíquetes. No entanto, elas ainda são usadas para determinar a melhor partida se vários tíquetes estiverem disponíveis. Somente os tipos número e QoS são expandidos antes de serem descartados. Para obter mais informações, consulte a seção Configuração das regras do hopper mais adiante neste tópico. Aumentar o valor da configuração Should Rule Expansion Cycles fornece mais ciclos para a expansão das regras SHOULD. No entanto, esse aumento também aumenta a duração do matchmaking. O valor padrão é 3, o que geralmente é suficiente para a maioria das configurações. Os ciclos de expansão ocorrem em intervalos fixos de cinco segundos. No último ciclo de expansão, nenhuma regra SHOULD é mais levada em conta pelo restante da tentativa de matchmaking. #### Hopper classificado Normalmente, o SmartMatch impede que jogadores bloqueados sejam combinados. Se Ranked Hopper estiver selecionado, essa lógica é ignorada para impedir que os jogadores usem esse sistema para evitar jogadores de maior habilidade. ### Configuração das regras do hopper Esta seção define os campos usados para configurar as regras de um hopper. #### Campos comuns das regras Os campos definidos nesta seção são comuns a todas as regras do hopper. * **Rule Name:** o nome amigável exibido para a regra para fins de configuração. * **Rule Type:** o tipo de regra. As opções são MUST e SHOULD. * As regras MUST precisam ser atendidas para que o matchmaking seja bem-sucedido. * As regras SHOULD podem ser flexibilizadas ou removidas para encontrar uma partida bem-sucedida. Para obter mais detalhes sobre esse processo, consulte a seção Ciclos de expansão de regras SHOULD anteriormente neste tópico. * **Data Type:** o tipo de dados do atributo da regra de matchmaking. Os valores possíveis são os seguintes. * **Number:** especifique um valor numérico simples de 32 bits. * **String:** especifique uma cadeia de caracteres Unicode de até 128 caracteres. * **Collection:** especifique uma matriz de cadeias de caracteres. Use esse valor para identificar conteúdo baixável (DLC), associação a esquadrões ou preferência de função dos jogadores. * **Quality of Service:** especifique um tipo de dados personalizado para incluir dados de QoS de latência no matchmaking. Apenas uma regra desse tipo deve ser usada por hopper de matchmaking. > \[!NOTE] > Se esse limite for problemático para o seu título, entre em contato com seu gerente de contas de desenvolvedor (DAM). * **Total Value:** especifique um tipo de dados personalizado que soma os valores de matchmaking enviados. Você pode usar esse valor para garantir que a soma resultante esteja dentro de um intervalo específico ou seja um valor exato. * **Team:** especifique um tipo de dados personalizado para as equipes de jogadores incluídas nas requisições de matchmaking. Você pode usar esse valor para evitar dividir os jogadores de um único tíquete de partida entre várias equipes. #### Campos de regras específicos de tipos de dados Esta seção define os campos usados para definir regras que se aplicam a alguns tipos de dados, mas não a outros. A interface do usuário deve deixar claro quais tipos de dados se aplicam a determinadas regras. * **Allow Wildcards:** um valor que indica se o atributo pode ser omitido no tíquete de partida. Se ele for omitido, o tíquete se tornará compatível com qualquer outro tíquete, independentemente do valor desse atributo. * **Attribute Source:** a origem do valor do tipo de dados. As origens possíveis são as seguintes. * **Title provided:** o valor dos dados é enviado no tíquete de partida. * **User stat instance:** o valor dos dados é recuperado automaticamente do serviço `UserStatistics`. * **Attribute Name:** o nome da origem do valor do atributo. É o nome da propriedade no tíquete de partida ou o nome de uma estatística do usuário. * **Default Value:** o valor padrão do tipo de dados, caso nenhum valor seja especificado ou esteja disponível para a requisição de matchmaking. O valor padrão não é aplicado quando o campo Allow Wildcards está selecionado e nenhum valor é especificado. * **Weight:** a importância da regra. O peso pode ser usado para indicar quais regras são priorizadas durante o matchmaking e a expansão de regras. O valor do peso deve ser um número positivo e o padrão é 1. * **Flatten Method:** somente tipos de dados numéricos. Um valor que indica como vários valores são combinados para satisfazer uma partida. Ele se aplica a vários valores de jogadores diferentes em um único tíquete de partida e entre vários tíquetes. Os valores possíveis são os seguintes. * **Min/Max:** use o valor mínimo ou máximo de vários valores de tíquetes de partida diferentes. * **Average:** use o valor médio de vários valores de tíquetes de partida diferentes. * **Max Diff:** somente tipos de dados numéricos. A diferença numérica máxima aceitável entre dois valores comparados para satisfazer uma regra. Para uma regra SHOULD, esse valor é o ponto de partida para a expansão da regra. * **Set Operation:** somente tipos de dados de coleção. A operação a ser executada na combinação do grupo de valores do conjunto. As opções possíveis são as seguintes. * **Intersection:** combina duas coleções com base na quantidade de interseção entre elas. Essa configuração resulta em valores de coleção semelhantes ou idênticos. * **Difference:** combina duas coleções com base na quantidade de diferença entre elas. * **Role Preference:** combina coleções com base nas preferências de função de um jogador em modos de jogo baseados em funções. * **Target Intersection:** parte da configuração de Set Operation. A interseção mínima ou a diferença máxima entre duas coleções antes que elas sejam combinadas. * **Network Topology:** somente o tipo de dados Quality of Service. A topologia de rede usada para a QoS. Os valores possíveis são Peer to Peer, Peer to Host e Client/Server. * **Maximum Latency/Scaling Maximum:** somente o tipo de dados Quality of Service. A latência máxima para um matchmaking bem-sucedido dentro da topologia de rede especificada. Esse valor é tratado como um valor de escala (em vez de uma latência obrigatória) ao usar uma regra SHOULD de Quality of Service Client/Server. > \[!NOTE] > Além disso, regras de reputação padrão também são aplicadas a um hopper. Essas regras não podem ser removidas e são usadas para garantir o tratamento correto da reputação durante o matchmaking. * **Allow Waiting for Roles:** somente o tipo de dados Collection Role Preferences. Especifica se o serviço de partidas mantém o tíquete de matchmaking para preencher todas as funções disponíveis. #### Delta de expansão O valor que indica quanto flexibilizar a regra enviada a cada geração de expansão. O delta de expansão é aplicado além do valor de Max Diff. Para obter detalhes, consulte o Exemplo 1 (expansão de regras) mais adiante neste tópico. Você também pode usar o delta de expansão para expandir vários valores numéricos em velocidades diferentes. Isso não é possível por meio da configuração do ciclo de expansão, porque ela se aplica a todas as regras. Em vez disso, a abordagem é usar valores de expansão decimais; por exemplo, 0.4. Uma expansão só ocorre quando um novo inteiro é alcançado, o que permite velocidades de expansão diferentes, mesmo para o mesmo número de ciclos de expansão. #### Expansão de QoS (ponto a ponto, par-host) Para a expansão do tipo QoS em jogos entre pares, o delta de expansão não pode ser configurado. Em vez disso, você deve usar uma das estratégias de expansão a seguir. 1. MaxLatency menor que 256 A expansão é realizada em MaxLatency × ciclo de expansão. Por exemplo, se o valor inicial for 200, 200 será usado no primeiro ciclo e 400 no segundo ciclo. 2. MaxLatency maior ou igual a 256 A expansão escala linearmente de 50 até MaxLatency - 256. Por exemplo, se o valor inicial for 556, o valor escala linearmente de 50 a 300 ao longo do número de ciclos. Ou seja, se seis ciclos forem escolhidos, os valores serão 50, 100, 150, 200, 250 e 300. Se cinco ciclos forem escolhidos, os valores serão 50, 112.5, 175, 237.5 e 300. #### Expansão de QoS (cliente/servidor) Ao usar servidores dedicados, a expansão se baseia na preferência relativa. Somente os servidores mais preferidos são considerados nos primeiros ciclos de expansão. Com o tempo, outros servidores menos preferidos são usados. Para garantir a expansão adequada, exigimos um valor semelhante a MaxLatency, chamado *Scaling Maximum*. Ele ainda deve ser definido como o maior tempo de ping aceitável. No entanto, esse valor fornece uma escala relativa para os diferentes tempos de ping de servidor fornecidos por um jogador, em vez de fornecer um requisito absoluto para os tempos de ping. Você pode excluir servidores com tempos de ping inaceitáveis removendo-os da lista na requisição. [Voltar ao início deste tópico.](#top) #### Exemplo 1 (expansão de regras) O nível do jogador é usado para o matchmaking, e os jogadores são combinados de forma flexível, com base na proximidade de seus níveis. Jogadores com a menor diferença entre seus níveis são preferidos. * Regra de nível do jogador * Tipo de regra: SHOULD * Tipo de dados: Number * Max Diff: 1 * Delta de expansão: 2 * Flatten Method: Average Por padrão, a diferença exigida entre os níveis dos jogadores é 1 ou menos. * Se uma partida for encontrada dentro dessa diferença, os jogadores serão combinados. * Se nenhuma partida inicial for encontrada, o valor do nível do jogador será expandido em 2 a cada iteração (por padrão, há três iterações). Esse cenário resulta no comportamento de matchmaking mostrado na tabela a seguir para um jogador no nível 20. \| Etapa | Valor de nível dos possíveis candidatos | Distância de nível efetiva para uma partida bem-sucedida | \|-----| \| Valor inicial enviado | 19-21 | 1 | \| Ciclo de expansão 1 | 17-23 | 3 | \| Ciclo de expansão 2 | 15-25 | 5 | \| Ciclo de expansão 3 | 13-27 | 7 | À medida que os ciclos de expansão continuam, a distância de nível efetiva para uma partida bem-sucedida aumenta sem alterar o valor de Max Diff. Somente o valor do nível do jogador é flexibilizado. #### Exemplo 2 (regra de coleção) O jogo lança três tipos de DLC disponíveis para os jogadores. Essa regra de matchmaking é aplicada ao matchmaking de jogabilidade "somente DLC", e um jogador deve possuir pelo menos um DLC para ser combinado com outros jogadores. * Regra de DLC do jogador * Tipo de regra: MUST * Tipo de dados: Collection * Set Operation: Intersection * Target Intersection: 1 Os jogadores avaliam seus DLCs e enviam em seus tíquetes de partida os valores mostrados na tabela a seguir. Na tabela a seguir, o valor da coleção indica a posse do DLC. Se o DLC estiver disponível para o jogador, o valor será definido como 1. Caso contrário, será definido como 0. | | Jogador | Valor da coleção | Combinado com os jogadores | Observações | | - | - | - | - | | Jogador 1 | { "1", "1", "1"} | 3 | Possui todos os DLCs | | Jogador 2 | { "0", "0", "0"} | Nenhum | Não possui nenhum DLC | | Jogador 3 | { "1", "0", "0"} | 1 | Possui o primeiro DLC | Se a interseção de destino neste exemplo for definida como 2, os jogadores 1 e 3 não serão combinados, porque a interseção entre eles é apenas 1. #### Exemplo 3 (evitar jogadores anteriores) O título prefere evitar um jogo com o jogador com quem jogou mais recentemente. * Tipo de regra: MUST * Tipo de dados: Collection * Set Operation: Difference * Target Intersection: 0 [Voltar ao início deste tópico.](#top) ## Definindo regras de equipe durante a configuração do SmartMatch ### Configurando regras de equipe Para configurar a Team Rule, comece criando uma no Partner Center. Preencha os tamanhos de equipe que seu jogo espera criar a partir dos tíquetes combinados neste hopper. Por exemplo, se o seu jogo espera quatro contra quatro, você deve criar duas entradas, cada uma com tamanho máximo de quatro e um nome diferente. Também há um tamanho mínimo de equipe. Use-o se um jogo puder ser jogado com menos jogadores em uma equipe. Caso contrário, o mínimo e o máximo devem ter o mesmo valor. ### Usando regras de equipe Depois que a Team Rule é configurada, os tíquetes dentro do hopper são impedidos de serem combinados se não houver como encaixar seus grupos em equipes sem causar uma divisão. A regra grava a alocação de equipes resultante na sessão de destino, em *members/constants/custom/matchmakingresult/initialTeam*. Essa é apenas uma alocação sugerida. O título pode descobrir que, ao reorganizar os jogadores, consegue criar um jogo melhor e ainda impedir que os tíquetes sejam divididos em equipes diferentes. Se um tíquete for criado para um jogo em andamento, a Team Rule exigirá informações adicionais. Suponha, por exemplo, que oito jogadores estejam em um jogo de quatro contra quatro quando dois jogadores saem ou são desconectados. O título gostaria de preencher essas vagas vazias, mas não pode reorganizar as equipes enquanto o jogo está sendo jogado. As tentativas de preencher jogos em andamento são representadas por tíquetes com o campo `PreserveSession` definido como `always`. Nesses casos, como as equipes já foram alocadas aos jogadores, o título deve especificar a alocação de equipes atual, para que o Match saiba quantas vagas estão abertas em cada equipe. Para fornecer os nomes das equipes em que cada jogador está, cada jogador grava o nome da sua equipe na sessão de jogo, em *members/me/properties/system/groups*. Esse campo é um `JArray`. Depois que as propriedades mencionadas anteriormente são gravadas na sessão de jogo, um jogador cria um tíquete para a sessão na tentativa de encontrar mais jogadores. Quando o tíquete é atendido, o Match grava novamente a equipe sugerida de todos os jogadores que ingressarem em *members/constants/custom/matchmakingresult/initialTeam*. #### Preferência por equipes equilibradas Além disso, as partidas são formadas primeiro com as maiores equipes. Isso significa que, em um hopper hipotético de quatro contra quatro, os tíquetes de quatro jogadores serão combinados primeiro, até que não restem tíquetes de quatro. Em seguida, continuam os tíquetes de três, puxando jogadores individuais conforme necessário, e assim por diante. Dessa forma, tíquetes de tamanho semelhante geralmente jogarão uns contra os outros, se estiverem presentes e não forem impedidos por outras regras. Isso dá à Team Rule uma precedência bastante forte sobre outras regras. Por exemplo, suponha que você tenha uma população limitada, composta por um tíquete de tamanho 4 com alta habilidade (A), um tíquete de tamanho 4 com baixa habilidade (B) e quatro tíquetes de tamanho 1 com alta habilidade (C-F). A Team Rule fará com que o Match prefira combinar A e B, em vez de A, C, D, E e F. #### Variante SHOULD A regra MUST impede a divisão de tíquetes em todas as gerações e fornece a ordenação com preferência por equipes equilibradas. A regra SHOULD é idêntica até a última geração; nela, os tíquetes podem ser divididos, embora a ordenação com preferência por equipes equilibradas continue ativa. [Voltar ao início deste tópico.](#top) ## Confira também [Modelos de sessão multiplayer](/pt-BR/services/xbox-services/multiplayer/mpsd/concepts/live-session-templates) [Visão geral do Multiplayer Session Directory](/pt-BR/services/xbox-services/multiplayer/mpsd/live-mpsd-overview) ## Related topics - [Configuração do matchmaking no portal](/pt-BR/services/xbox-services/multiplayer/matchmaking/config/live-matchmaking-config-nav.md) - [Visão geral da configuração do portal](/pt-BR/services/xbox-services/fundamentals/portal-config/live-portal-config-overview.md) - [Visão geral do matchmaking](/pt-BR/services/xbox-services/multiplayer/matchmaking/live-matchmaking-overview.md) - [Configuração](/pt-BR/services/xbox-services/multiplayer/matchmaking/config/index.md) - [Configurando privilégios no Partner Center](/pt-BR/services/xbox-services/fundamentals/identity/privileges/config/live-privileges-config.md)