Projetar um conjunto de regras de correspondência grande FlexMatch - Amazônia GameLift

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Projetar um conjunto de regras de correspondência grande FlexMatch

Se o seu conjunto de regras criar correspondências que permitem 41 a 200 jogadores, você precisará fazer alguns ajustes na configuração do conjunto de regras. Esses ajustes otimizam o algoritmo de partida para que ele possa construir partidas grandes viáveis e, ao mesmo tempo, manter os tempos de espera do jogador curtos. Como resultado, conjuntos de regras de correspondência grande substituem regras personalizadas demoradas por soluções padrão otimizadas para prioridades comuns de matchmaking.

Veja como determinar se você precisa otimizar seu conjunto de regras para partidas grandes:

  1. Para cada equipe definida em seu conjunto de regras, obtenha o valor deMaxPlayer,

  2. Adicione todos osMaxPlayerValores. Se o total exceder 40, você tem um conjunto de regras de correspondências grande.

Para otimizar o conjunto de regras para correspondências grandes, faça os ajustes descritos da seguinte forma. Consulte o esquema de um conjunto de regras de correspondências grande emEsquema de conjunto de regras para correspondências grandese exemplos de conjunto de regras emExemplo 7: Crie uma correspondência grande.

Personalize o algoritmo de correspondência para partidas grandes

Adicione um componente de algoritmo para o conjunto de regras, se ainda não existir. Defina as seguintes propriedades.

  • strategy(obrigatório) — Defina ostrategypropriedade para “balanceada”. Essa configuração aciona o FlexMatch para fazer verificações adicionais pós-partida para encontrar o saldo ideal da equipe com base em um atributo de jogador especificado, que é definido nabalancedAttributepropriedade. A estratégia equilibrada substitui a necessidade de regras personalizadas para construir equipes uniformemente combinadas.

  • balancedAttribute(obrigatório) - Identifique um atributo de jogador ser usado ao equilibrar as equipes em uma correspondência. Esse atributo deve ter um tipo de dados numéricos (duplo ou inteiro). Por exemplo, se você optar por equilibrar a habilidade do jogador, o FlexMatch tenta atribuir jogadores para que todas as equipes tenham níveis de habilidade agregados que sejam tão uniformemente correspondidos quanto possível. O atributo de balanceamento deve ser declarado nos atributos de jogador do conjunto de regras.

  • batchingPreference(opcional) — Escolha quanta ênfase você quer dar ao formar as partidas de latência mais baixas possíveis para seus jogadores. Essa configuração afeta a forma como os tickets de correspondência são classificados antes da criação de partidas. Entre as opções estão:

    • População maior. O FlexMatch permite correspondências usando todos os tickets no grupo que têm valores de latência aceitáveis em pelo menos uma região em comum. Como resultado, o potencial pool de tickets tende a ser grande, o que facilita o preenchimento de partidas mais rapidamente. Os jogadores podem ser colocados em jogos com latência aceitável, mas nem sempre ótima. Se obatchingPreferencePropriedade não definida, este é o comportamento padrão quandostrategyestá definido como “equilibrado”.

    • Região mais rápida. O FlexMatch pré-classifica todos os tickets no pool com base em onde eles relatam os valores de latência mais baixos. Como resultado, as correspondências tendem a ser formadas com jogadores que relatam baixa latência nas mesmas regiões. Ao mesmo tempo, o potencial pool de tickets para cada partida é menor, o que pode aumentar o tempo necessário para preencher uma partida. Além disso, como uma prioridade maior é colocada na latência, os jogadores nas correspondências podem variar mais amplamente em relação ao atributo de balanceamento.

O exemplo a seguir configura o algoritmo de correspondência para se comportar da seguinte forma: (1) Pré-classifique o pool de tíquetes para agrupar tickets por Região onde eles têm valores de latência aceitáveis; (2) Formar lotes de tickets classificados para correspondência; (3) Crie partidas com tíquetes em um lote e equilibre as equipes para equilibrar a habilidade média do jogador.

"algorithm": { "strategy": "balanced", "balancedAttribute": "player_skill", "batchingPreference": "largestPopulation" },

Declarar os atributos do jogador

Certifique-se de declarar o atributo de jogador usado como atributo de balanceamento do algoritmo do conjunto de regras. Esse atributo deve ser incluído para cada jogador em uma solicitação de matchmaking. Você pode fornecer um valor padrão para o atributo player, mas o balanceamento de atributos funciona melhor quando valores específicos do jogador são fornecidos.

Definir equipes

O processo de definição do tamanho da equipe e da estrutura é o mesmo que o de pequenas correspondências, mas a maneira como o FlexMatch preenche as equipes é diferente. Isso afeta como as correspondências serão quando estiverem somente parcialmente preenchidas. Você pode ajustar o tamanho mínimo da equipe em resposta.

O FlexMatch usa as seguintes regras ao atribuir um jogador a uma equipe. Primeiro: procura equipes que ainda não alcançaram o requisito mínimo de jogadores. Depois: dessas equipes, procura a que tem mais slots abertos.

Para várias correspondências que definem o mesmo tamanho, os jogadores são adicionados sequencialmente para cada equipe até encher. Como resultado, as equipes em uma correspondência sempre têm um número quase igual de jogadores, mesmo quando a correspondência não está cheia. Atualmente, não há como forçar o mesmo tamanho em correspondências grandes. Para correspondências com equipes de tamanho assimétrico, o processo é um pouco mais complexo. Nesse cenário, os jogadores são atribuídos inicialmente às equipes maiores que têm a maioria dos slots abertos. Como o número de slots abertos se tornam mais uniformemente distribuído em todas as equipes, os jogadores são colocados nas equipes menores.

Por exemplo, digamos que você tenha um conjunto de regras com três equipes. As equipes vermelha e azul estão definidas comomaxPlayers=10,minPlayers=5. A equipe verde está definida comomaxPlayers=3,minPlayers=2. Aqui está a sequência de preenchimento:

  1. Nenhuma equipe atingiuminPlayers. As equipes vermelha e azul têm 10 slots abertos, enquanto a verde tem 3. Os primeiros 10 jogadores são atribuídos (5 cada) para as equipes vermelha e azul. Ambas as equipes atingiramminPlayers.

  2. A equipe verde ainda não atingiuminPlayers. Os próximos dois jogadores são atribuídos à equipe verde. A equipe Green chegou agoraminPlayers.

  3. Com todas as equipes emminPlayersAgora, jogadores adicionais são atribuídos com base no número de slots abertos. As equipes Vermelho e Azul têm 5 vagas abertas, enquanto a equipe Verde tem 1. Os próximos 8 jogadores são atribuídos (4 cada) para as equipes vermelha e azul. Todas as equipes agora têm 1 slot aberto.

  4. Os três slots de jogador restantes são atribuídos (1 cada) para equipes sem uma ordem específica.

Definir regras para partidas grandes

O pareamento para partidas grandes depende principalmente da estratégia de balanceamento e otimizações de lotes de latência. A maioria das regras personalizadas não estão disponíveis. No entanto, você pode incorporar os seguintes tipos de regras:

  • Regra que define um limite rígido na latência do jogador. Usar alatencytipo de regra com a propriedademaxLatency. ConsulteRegra de latênciareferência. Aqui está um exemplo que define a latência de jogador máximo de 200 milissegundos:

    "rules": [{ "name": "player-latency", "type": "latency", "maxLatency": 200 }],
  • Regra para jogadores em lote com base na proximidade em um atributo de jogador especificado. Isso é diferente de definir um atributo de balanceamento como parte do algoritmo de correspondência grande, que se concentra na construção de equipes uniformemente combinadas. Esta regra agrupa os tickets de matchmaking com base na semelhança nos valores de atributo especificados, como habilidade iniciante ou especialista, que tende a levar a partidas jogadores que estão estreitamente alinhados no atributo especificado. Usar abatchDistancetipo de regra, identifique um atributo baseado em número e especifique o intervalo mais amplo a ser permitido. ConsulteRegra de distância dareferência. Aqui está um exemplo que exige que os jogadores de uma partida estejam dentro de um nível de habilidade um do outro:

    "rules": [{ "name": "batch-skill", "type": "batchDistance", "batchAttribute": "skill", "maxDistance": 1

Relaxe requisitos de correspondência grande

Assim como ocorre com as pequenas correspondências, você pode usar as expansões para diminuir os requisitos de correspondência ao longo do tempo, quando não há correspondências válidas possíveis. Nas correspondências grandes, você tem a opção de diminuir as regras de latência do jogador ou as contagens.

Se você estiver usando alocação de correspondência automática para correspondências grandes, evite diminuir a contagem muito rapidamente. O FlexMatch começa a gerar as solicitações de alocação somente depois que uma sessão de jogo é iniciada, o que não pode acontecer por vários segundos após uma correspondência ser criada. Durante esse tempo, o FlexMatch pode criar várias novas sessões de jogos preenchidas, especialmente quando as regras de contagem são diminuídas. Como resultado, você obtém mais sessões de jogos do que precisa e jogadores em todas elas. A prática recomendada é permitir mais tempo para a primeira contagem de jogadores, suficiente para a sessão ser iniciada. Uma vez que as solicitações de alocação de prioridade mais alta são fornecidas com grandes correspondências, os jogadores recebidos serão inscritos em jogos existentes antes de novo jogo iniciar. Talvez você precise experimentar para localizar o tempo de espera ideal para seu jogo.

Aqui está um exemplo que gradualmente reduz a contagem de jogadores da equipe amarela, com um tempo de espera inicial mais longo. Lembre-se de que os tempos de nas expansões do conjunto de regras são absolutos, e não compostos. Portanto, a primeira expansão ocorre em cinco segundos, e a segunda ocorre cinco segundos mais tarde, em dez segundos.

"expansions": [{ "target": "teams[Yellow].minPlayers", "steps": [{ "waitTimeSeconds": 5, "value": 8 }, { "waitTimeSeconds": 10, "value": 5 }] }]