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á.
# Construir um conjunto de regras do FlexMatch
Cada marcador de jogos do FlexMatch. deve ter um conjunto de regras. O conjunto de regras determina os dois elementos principais de uma correspondência, a estrutura e o tamanho da equipe, e como agrupar jogadores para a melhor correspondência de jogo possível
Por exemplo, um conjunto de regras pode descrever uma correspondência como esta: crie uma correspondência com duas equipes de cinco jogadores cada, uma equipe é dos defensores e a outra equipe é dos invasores. Uma equipe pode ter jogadores iniciantes e especialistas, mas a habilidade média das duas equipes deve estar entre 10 pontos de cada uma. Se nenhuma correspondência for encontrada após 30 segundos, diminua gradualmente as exigências de habilidade.
Os tópicos nesta seção descrevem como projetar e criar um conjunto de regras de criação de partidas. Ao criar um conjunto de regras, use o console do Amazon GameLift Servers ou a AWS CLI.
**Topics**
+ [Criar um conjunto de regras do FlexMatch](match-design-ruleset.md)
+ [Criar uma conjunto de regras de correspondência grande do FlexMatch](match-design-rulesets-large.md)
+ [Tutorial: criar um conjunto de regras de criação de partidas](match-create-ruleset.md)
+ [Exemplos de configuração de regras do FlexMatch](match-examples.md)
# Criar um conjunto de regras do FlexMatch
Este tópico aborda a estrutura básica de um conjunto de regras e como usá-las para compilar um conjunto de regras para jogos pequenos de até 40 jogadores. Um conjunto de regras de criação de partidas faz duas coisas: define um tamanho e uma estrutura para a equipe do jogo e diz ao matchmaker como escolher os jogadores e formar o melhor jogo possível.
Mas seu conjunto de regras de criação de partidas pode fazer mais. Por exemplo, você pode:
+ Otimize o algoritmo de criação de partidas para o seu jogo.
+ Configure os requisitos mínimos de latência do jogador para proteger a qualidade da jogabilidade.
+ Relaxe gradualmente os requisitos da equipe e as regras do jogo ao longo do tempo para que todos os jogadores ativos possam encontrar um jogo aceitável quando quiserem.
+ Defina o tratamento de solicitações de criação de partidas em grupo usando agregação de grupos.
+ Processe grandes jogos de 40 jogadores ou mais. Para obter mais informações sobre a criação de partidas grandes, consulte [Criar uma conjunto de regras de correspondência grande do FlexMatch](match-design-rulesets-large.md).
Ao criar um conjunto de regras de criação de partidas, considere as seguintes tarefas opcionais e obrigatórias:
+ [Descreva o conjunto de regras (obrigatório)](match-rulesets-components-set.md)
+ [Personalize o algoritmo de correspondência](match-rulesets-components-algorithm.md)
+ [Declarar os atributos do jogador](match-rulesets-components-attributes.md)
+ [Defina as equipes do jogo](match-rulesets-components-teams.md)
+ [Definir regras de correspondência de jogadores](match-rulesets-components-rules.md)
+ [Permita que os requisitos diminuam com o tempo](match-rulesets-components-expansion.md)
É possível criar seu conjunto de regras usando o console do Amazon GameLift Servers ou a operação `[CreateMatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateMatchmakingRuleSet.html)`.
# Descreva o conjunto de regras (obrigatório)
Forneça os detalhes do conjunto de regras.
+ *nome* (opcional): um rótulo descritivo para seu próprio uso. Esse valor não está associado ao nome do conjunto de regras que você especifica ao criar o conjunto de regras com o Amazon GameLift Servers.
+ *ruleLanguageVersion*— A versão da linguagem de expressão de propriedade usada para criar FlexMatch regras. O valor deve ser `1.0`.
# Personalize o algoritmo de correspondência
O FlexMatch otimiza o algoritmo padrão para a maioria dos jogos para levar os jogadores a jogos aceitáveis com tempo de espera mínimo. É possível personalizar o algoritmo e ajustar o criação de partidas para o seu jogo.
A seguir está o algoritmo de criação de partidas padrão do FlexMatch:
1. O FlexMatch coloca todos os tickets de criação de partidas abertos e os tickets preenchidos em um pool de tickets.
1. O FlexMatch agrupa aleatoriamente os tickets no pool em um ou mais lotes. À medida que o pool de tickets aumenta, o FlexMatch forma lotes adicionais para manter o tamanho ideal do lote.
1. O FlexMatch classifica os tickets por idade, dentro de cada lote.
1. O FlexMatch cria uma combinação com base no ticket mais antigo de cada lote.
Para personalizar o algoritmo de correspondência, adicione um componente `algorithm` ao esquema do conjunto de regras. Consulte [Esquema de conjunto de regras do FlexMatch](match-ruleset-schema.md) para obter informações completas de referência.
Use as seguintes personalizações opcionais para impactar diferentes estágios do seu processo de criação de partidas.
+ [Adicionar classificação pré-lote](#match-rulesets-components-algorithm-presort)
+ [Forme lotes com base nos atributos batchDistance](https://docs.aws.amazon.com//gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html#match-rules-reference-ruletype-batchdistance)
+ [Priorize os tickets de preenchimento](#match-rulesets-components-algorithm-backfill)
+ [Favoreça tickets mais antigos com expansões](#match-rulesets-components-algorithm-expansion)
## Adicionar classificação pré-lote
É possível classificar o pool de tickets antes de formar lotes. Esse tipo de personalização é mais eficaz em jogos com grandes pools de tickets. A classificação pré-lote pode ajudar a acelerar o processo de criação de partidas e aumentar a uniformidade dos jogadores nas características definidas.
Defina métodos de classificação pré-lote usando a propriedade do algoritmo `batchingPreference`. A configuração padrão é `random`.
As opções para personalizar a classificação pré-lote incluem:
+ **Classifique por atributos do jogador.** Forneça uma lista dos atributos do jogador para pré-classificar o pool de tickets.
Para classificar por atributos do jogador, defina `batchingPreference` como `sorted` e defina sua lista de atributos do jogador em `sortByAttributes`. Para usar um atributo, primeiro declare o atributo no componente `playerAttributes` do conjunto de regras.
No exemplo a seguir, o FlexMatch classifica o pool de tickets com base no mapa de jogo preferido dos jogadores e, em seguida, pela habilidade do jogador. É mais provável que os lotes resultantes contenham jogadores com habilidades semelhantes que desejam usar o mesmo mapa.
```
"algorithm": {
"batchingPreference": "sorted",
"sortByAttributes": ["map", "player_skill"],
"strategy": "exhaustiveSearch"
},
```
+ **Classifique por latência.** Crie jogos com a menor latência disponível ou crie rapidamente jogos com latência aceitável. Essa personalização é útil para conjuntos de regras que formam grandes jogos de mais de 40 jogadores.
Defina a propriedade do algoritmo `strategy` como `balanced`. A estratégia balanceada limita os tipos disponíveis de declarações de regras. Para obter mais informações, consulte [Criar uma conjunto de regras de correspondência grande do FlexMatch](match-design-rulesets-large.md).
O FlexMatch classifica os tickets com base nos dados de latência relatados pelos jogadores de uma das seguintes maneiras:
+ *Locais de menor latência.* O pool de tickets é pré-classificado pelos locais em que os jogadores relatam seus valores de latência mais baixos. O FlexMatchem seguida, agrupa os tickets com baixa latência nos mesmos locais, criando uma melhor experiência de jogo. Também reduz o número de tickets em cada lote, então o criação de partidas pode demorar mais. Para usar essa personalização, defina `batchingPreference` como `fastestRegion`, conforme mostrado no exemplo a seguir.
```
"algorithm": {
"batchingPreference": "fastestRegion",
"strategy": "balanced"
},
```
+ *A latência aceitável corresponde rapidamente.* O pool de tickets é pré-classificado por locais onde os jogadores relatam um valor de latência aceitável. Isso forma menos lotes contendo mais tickets. Com mais tickets em cada lote, encontrar combinações aceitáveis é mais rápido. Para usar essa personalização, defina a propriedade `batchingPreference` como ` largestPopulation`, conforme mostrado no exemplo a seguir.
```
"algorithm": {
"batchingPreference": "largestPopulation",
"strategy": "balanced"
},
```
**nota**
O valor padrão para a estratégia balanceada é `largestPopulation`.
## Priorize os tickets de preenchimento
Se o seu jogo implementa preenchimento automático ou preenchimento manual, você pode personalizar como o FlexMatch processa os tickets de criação de partidas com base no tipo de solicitação. O tipo de solicitação pode ser uma nova solicitação de jogo ou preenchimento. Por padrão, o FlexMatch trata os dois tipos de solicitações da mesma forma.
A priorização do preenchimento afeta a forma como o FlexMatch processa os tickets depois de agrupá-los em lotes. A priorização do preenchimento exige conjuntos de regras para usar a estratégia de pesquisa exaustiva.
O FlexMatch não combina vários tickets de preenchimento.
Para alterar a priorização dos tickets de preenchimento, defina a propriedade `backfillPriority`.
+ **Combine os tickets de preenchimento primeiro.** Essa opção tenta combinar os tickets preenchidos antes de criar novos jogos. Isso significa que os novos jogadores têm uma chance maior de entrar em um jogo existente.
É melhor usar isso se seu jogo usa preenchimento automático. O preenchimento automático é frequentemente usado em jogos com sessões curtas e alta rotatividade de jogadores. O preenchimento automático ajuda esses jogos a formar jogos mínimos viáveis e a iniciá-los, enquanto o FlexMatch procura mais jogadores para preencher as vagas abertas.
Defina `backfillPriority` como `high` .
```
"algorithm": {
"backfillPriority": "high",
"strategy": "exhaustiveSearch"
},
```
+ **Os tickets de preenchimento do jogo duram.** Essa opção ignora os tickets de preenchimento até avaliar todos os outros tickets. Isso significa que o FlexMatch preenche os novos jogadores em jogos existentes quando não consegue combiná-los com novos jogos.
Essa opção é útil quando você deseja usar o preenchimento como uma opção de última chance para colocar jogadores em um jogo, como quando não há jogadores suficientes para formar uma novo jogo.
Defina `backfillPriority` como `low`.
```
"algorithm": {
"backfillPriority": "low",
"strategy": "exhaustiveSearch"
},
```
## Favoreça tickets mais antigos com expansões
As regras de expansão relaxam os critérios de jogos quando os jogos são difíceis de concluir. O Amazon GameLift Servers aplica regras de expansão quando os tickets de um jogo parcialmente concluído atingem uma certa idade. Os carimbos de data e hora de criação dos tickets determinam quando o Amazon GameLift Servers aplica as regras; por padrão, o FlexMatch rastreia o carimbo de data e hora do ticket combinado mais recentemente.
Para alterar quando o FlexMatch aplica as regras de expansão, defina a propriedade `expansionAgeSelection` da seguinte forma:
+ **Expanda com base nos tickets mais novos.** Essa opção aplica regras de expansão com base no ticket mais novo adicionado à possível jogo. Cada vez que o FlexMatch combina um novo ticket, o relógio de ponto é zerado. Com essa opção, os jogos resultantes tendem a ser de melhor qualidade, mas demoram mais para serem correspondidos; as solicitações de jogos podem expirar antes de serem concluídas se demorarem muito para serem correspondidas. Defina `expansionAgeSelection` como `newest`. `newest` é padrão.
+ **Expanda com base nos tickets mais antigos.** Essa opção aplica regras de expansão com base no ticket mais antigo do jogo potencial. Com essa opção, o FlexMatch aplica expansões mais rapidamente, o que melhora o tempo de espera dos primeiros jogadores combinados, mas diminui a qualidade do jogo para todos os jogadores. Defina `expansionAgeSelection` como `oldest`.
```
"algorithm": {
"expansionAgeSelection": "oldest",
"strategy": "exhaustiveSearch"
},
```
# Declarar os atributos do jogador
Nesta seção, liste os atributos individuais do jogador a serem incluídos nas solicitações de criação de partidas. Há duas razões pelas quais você pode declarar os atributos do jogador em um conjunto de regras:
+ Quando o conjunto de regras contém regras que dependem dos atributos do jogador.
+ Quando você quiser passar um atributo de jogador para a sessão do jogo por meio da solicitação de jogo. Por exemplo, talvez você queira passar as escolhas do personagem do jogador para a sessão do jogo antes que cada jogador se conecte.
Ao declarar um atributo de jogador, inclua as seguintes informações:
+ *nome* (obrigatório): este valor deve ser exclusivo para o conjunto de regras.
+ *tipo* (obrigatório): este é o tipo de dados do valor do atributo. Os tipos de dados válidos são número, string, lista de strings ou mapa de strings.
+ *padrão* (opcional): insira um valor padrão a ser usado se uma solicitação de criação de partidas não fornecer um valor de atributo. Se nenhum padrão for declarado e uma solicitação não incluir um valor, o FlexMatch não poderá atender à solicitação.
# Defina as equipes do jogo
Descreva a estrutura e o tamanho das equipes de um jogo. Cada jogo deve ter pelo menos uma equipe, e você pode definir quantas equipes quiser. Suas equipes podem ter o mesmo número de jogadores ou ser assimétricas. Por exemplo, você pode definir um time de monstros de jogadores únicos e uma equipe de caçadores com 10 jogadores.
O FlexMatch processa as solicitações de correspondência pequenas e grandes com base na definição do conjunto de regras sobre o tamanhos das equipes. Os jogos em potencial de até 40 jogadores são pequenos, enquanto os com mais de 40 são grandes. Para determinar um conjunto de regras do jogo em potencial, adicione as configurações *maxPlayer* para todas as equipes definidas no conjunto de regras.
+ *name* (obrigatório): atribua um nome exclusivo à cada equipe. Você usa esse nome em regras e expansões, e referências FlexMatch para os dados de criação de partidas em uma sessão de jogo.
+ *maxPlayers* (obrigatório): especifique o número máximo de jogadores que podem ser atribuídos ao grupo.
+ *minPlayers* (obrigatório): especifique o número mínimo de jogadores que podem ser atribuídos ao grupo.
+ *quantidade* (opcional): especifique o número de equipes a serem formadas com essa definição. Quando o FlexMatch cria um jogo, ele dá a essas equipes o nome fornecido com um número anexado. Por exemplo `Red-Team1`, `Red-Team2` e `Red-Team3`.
O FlexMatch tenta preencher as equipes até o tamanho máximo de jogadores, mas cria equipes com menos jogadores. Se você deseja que todas as equipes do jogo sejam do mesmo tamanho, crie uma regra para isso. Consulte o tópico [Exemplos de configuração de regras do FlexMatch](match-examples.md) para obter um exemplo de uma regra `EqualTeamSizes`.
# Definir regras de correspondência de jogadores
Crie um conjunto de instruções de regras que avaliam os jogadores para aceitação em um jogo. As regras podem definir os requisitos que se aplicam a jogadores individuais, a equipes ou a um jogo inteiro. Quando o Amazon GameLift Servers processa uma solicitação de correspondência, ele começa com o jogador mais antigo na seleção de jogadores disponíveis e cria uma correspondência para cada jogador. Para obter ajuda detalhada sobre a criação de regras do FlexMatch, consulte [Tipos de regra do FlexMatch](match-rules-reference-ruletype.md).
+ *name* (obrigatório): este é um nome significativo que identifica exclusivamente a regra dentro de um conjunto de regras. Os nomes de regra também são referenciados em logs de eventos e métricas que controlam as atividades relacionadas a essa regra.
+ *descrição* (opcional): use este elemento para anexar uma descrição de texto livre.
+ *tipo* (obrigatório): o elemento tipo identifica uma operação ser usada ao processar a regra. Cada tipo de regra exige um conjunto de propriedades adicionais. Veja uma lista dos tipos de regra válidos e as propriedades em [Idioma de regras do FlexMatch](match-rules-reference.md).
+ Propriedade do tipo de regra (pode ser necessária): dependendo do tipo de regra que está definido, pode ser preciso definir determinadas propriedades. Saiba mais sobre as propriedades e como usar a linguagem de expressão de propriedade do FlexMatch em [Idioma de regras do FlexMatch](match-rules-reference.md).
# Permita que os requisitos diminuam com o tempo
As expansões permitem que você relaxe os critérios das regras ao longo do tempo, quando o FlexMatch não consegue encontrar um jogo. Esse recurso garante que o FlexMatch disponibilize o melhor quando não consegue fazer uma combinação perfeita. Ao relaxar as regras com uma expansão, você está expandindo gradualmente o pool de jogadores que são uma correspondência aceitável.
As expansões começam quando a idade do ticket mais novo no jogo incompleto coincide com o tempo de espera da expansão. Quando o FlexMatch adiciona um novo ticket ao jogo, o tempo de espera da expansão pode ser redefinido. É possível personalizar como as expansões começam na seção `algorithm` do conjunto de regras.
Aqui está um exemplo de uma expansão que aumenta gradualmente o nível mínimo de habilidade necessário para o jogo. O conjunto de regras usa uma declaração de regra de distância, nomeada *SkillDelta*para exigir que todos os jogadores em uma partida estejam dentro de 5 níveis de habilidade um do outro. Se nenhum novo jogo for feito por quinze segundos, essa expansão busca uma diferença de nível de habilidade de 10 e, dez segundos depois, uma diferença de 20.
```
"expansions": [{
"target": "rules[SkillDelta].maxDistance",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 25,
"value": 20
}]
}]
```
Com rmatchmakers que tenham o preenchimento automático ativado, não diminua os requisitos de contagem de jogadores muito rapidamente. Leva alguns segundos para a nova sessão de jogo iniciar e começar o preenchimento automático. Uma abordagem melhor é definir a expansão depois que as tendências de alocação iniciarem para seus jogos. O tempo de expansão varia de acordo com a composição da sua equipe, então faça testes para encontrar a melhor estratégia de expansão para seu jogo.
# Criar uma conjunto de regras de correspondência grande do FlexMatch
Se o conjunto de regras criar jogos que permitam 41 a 200 jogadores, é necessário fazer alguns ajustes na configuração do conjunto de regras. Esses ajustes otimizam o algoritmo de jogo para que ele possa criar grandes jogos viáveis e, ao mesmo tempo, manter os tempos de espera dos jogadores curtos. Como resultado, grandes conjuntos de regras de jogo substituem regras personalizadas demoradas por soluções padrão que são otimizadas para prioridades comuns de criação de partidas.
Veja como determinar se você precisa otimizar seu conjunto de regras para jogos grandes:
1. Para cada equipe definida em seu conjunto de regras, obtenha o valor de *maxPlayer*,
1. Some todos os valores de *maxPlayer*. Se o total exceder 40, você tem um conjunto de regras de jogo grande.
Para otimizar seu conjunto de regras para jogos grandes, faça os ajustes descritos a seguir. Consulte o esquema para ver um conjunto de regras de jogo grande em [Esquema de conjunto de regras para jogos grandes](match-ruleset-schema-large.md) e exemplos de conjuntos de regras em [Exemplo: crie uma correspondência grande](match-examples-7.md).
# Personalize o algoritmo de correspondência para jogos grandes
Adicione um componente de algoritmo ao conjunto de regras, caso ainda não exista. Defina as seguintes propriedades.
+ `strategy` (obrigatório): defina a propriedade `strategy` como “balanceada”. Essa configuração faz com que o FlexMatch faça verificações adicionais após o jogo para encontrar o equilíbrio ideal da equipe com base em um atributo de jogador especificado, definido na propriedade `balancedAttribute`. A estratégia equilibrada substitui a necessidade de regras personalizadas para criar equipes uniformemente compatíveis.
+ `balancedAttribute` (obrigatório): identifique um atributo do jogador a ser usado ao equilibrar as equipes em um jogo. Esse atributo deve ter um tipo de dado numérico (duplo ou inteiro). Por exemplo, se optar por equilibrar a habilidade do jogador, o FlexMatch você tentará atribuir jogadores para que todas as equipes tenham níveis de habilidade agregados que sejam tão uniformes quanto possível. Certifique-se de declarar o atributo no balanceamento de atributos de jogador no conjunto de regras.
+ `batchingPreference` (opcional): escolha quanta ênfase você deseja colocar na formação dos jogos de menor latência possível para seus jogadores. Essa configuração afeta a forma como os tickets para jogos são classificados antes da criação de partidas. Entre as opções estão:
+ Maior população. O FlexMatch permite jogos usando todos os tickets no pool que tenham valores de latência aceitáveis em pelo menos um local em comum. Como resultado, o pool de tickets potenciais tende a ser grande, o que torna mais fácil preencher os jogos mais rapidamente. Os jogadores podem ser colocados em jogos com latência aceitável, mas nem sempre ideal. Se a propriedade `batchingPreference` não estiver definida, esse é o comportamento padrão quando `strategy` é definida como “balanceada”.
+ Localizaçã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, os jogos tendem a ser formados com jogadores que relatam baixa latência nos mesmos locais. Ao mesmo tempo, o potencial de tickets para cada jogo é menor, o que pode aumentar o tempo necessário para preencher um jogo. Além disso, como a maior prioridade é dada à latência, os jogadores nos jogos podem variar mais amplamente em relação ao atributo de balanceamento.
O exemplo a seguir configura o algoritmo de jogo para se comportar da seguinte maneira: (1) pré-classifique o pool de tickets para agrupar os tickets por local onde eles tenham valores de latência aceitáveis; (2) forme lotes de tickets classificados para combinar; (3) crie jogos com tickets 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
No mínimo, você deve declarar o atributo de jogador usado como atributo de balanceamento de algoritmo do conjunto de regras. Esse atributo deve ser incluído para cada jogador em uma solicitação de criação de partidas. Você pode fornecer um valor padrão para o atributo do jogador, 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 os jogos 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ários jogos que definem o mesmo tamanho, os jogadores são adicionados sequencialmente para cada equipe até encher. Como resultado, as equipes em um jogo sempre têm um número quase igual de jogadores, mesmo quando o jogo não está cheio. Atualmente, não há como forçar o mesmo tamanho em jogos grandes. Para jogos com equipes de tamanho assimétrico, o processo é um pouco mais complexo. Nesse cenário, os jogadores são inicialmente atribuídos às equipes maiores que têm a maioria dos slots abertos. Conforme número de slots abertos se torna mais uniformemente distribuído em todas as equipes, os jogadores são inscritos em equipes menores.
Por exemplo, digamos que você tem uma regra definida com três equipes. As equipes vermelha e azul são definidas como `maxPlayers`=10, `minPlayers`=5. A equipe verde está configurada para `maxPlayers` =3, `minPlayers` =2. Aqui está a sequência de preenchimento:
1. Nenhuma equipe chegou `minPlayers`. 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 atingiram `minPlayers`.
1. A equipe verde ainda não atingiu `minPlayers`. Os próximos dois jogadores são atribuídos à equipe verde. A equipe verde já atingiu `minPlayers`.
1. Com todas as equipes em `minPlayers`, jogadores adicionais agora são atribuídos com base no número de vagas abertas. As equipes vermelha e azul têm cinco slots abertos cada, enquanto a verde tem um. Os 8 próximo jogadores são atribuídos (4 cada) para as equipes vermelha e azul. Todas as equipes agora têm uma vaga aberta.
1. As vagas restantes para três jogadores são atribuídas (uma cada) às equipes em nenhuma ordem específica.
# Estabeleça regras para jogos grandes
O criação de partidas para jogos grandes depende principalmente da estratégia de balanceamento e das otimizações de latência em lotes. A maioria das regras personalizadas não está disponível. No entanto, é possível incorporar os seguintes tipos de regras:
+ Regra que define um limite rígido na latência do jogador. Use o tipo de regra `latency` com a propriedade `maxLatency`. Consulte a referência de [Regra de latência](match-rules-reference-ruletype.md#match-rules-reference-ruletype-latency). 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 agrupar jogadores com base na proximidade de um atributo de jogador especificado. Isso é diferente de definir um atributo de balanceamento como parte do algoritmo de jogos grandes, que se concentra em criar equipes uniformemente combinadas. Essa regra agrupa os tickets de criação de partidas com base na semelhança nos valores dos atributos especificados, como habilidade de iniciante ou especialista, o que tende a levar a jogos de jogadores que estão estreitamente alinhados com o atributo especificado. Use o tipo de regra `batchDistance`, identifique um atributo com base numérica e especifique o intervalo mais amplo a ser permitido. Consulte a referência de [Regra de distância em lote](match-rules-reference-ruletype.md#match-rules-reference-ruletype-batchdistance). Aqui está um exemplo que exige que os jogadores de um jogo estejam dentro de um nível de habilidade um do outro:
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# Diminuir os requisitos de correspondências grandes
Assim como ocorre com as jogos pequenas, você pode usar as expansões para diminuir os requisitos de jogos ao longo do tempo, quando não há jogos válidos 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, principalmente 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 jogos grandes, 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
}]
}]
```
# Tutorial: criar um conjunto de regras de criação de partidas
Antes de criar um conjunto de regras de criação de partidas para o criador de partidas do Amazon GameLift Servers FlexMatch, recomendamos verificar a [sintaxe do conjunto de regras](match-rules-reference.md). Depois de criar um conjunto de regras usando o console do Amazon GameLift Servers ou a AWS Command Line Interface (AWS CLI), não será possível alterá-lo.
Observe que há um [service quota](https://console.aws.amazon.com/servicequotas/home/services/gamelift/quotas/) para o número máximo de conjuntos de regras que você pode ter em uma região da AWS e, portanto, é uma boa ideia excluir conjuntos de regras não utilizados.
**Topics**
------
#### [ Console ]
**Criar um conjunto de regras**
1. Abra o console Amazon GameLift Servers do em [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/).
1. Alterne para a região da AWS onde deseja colocar o conjunto de regras. Defina conjuntos de regras na mesma região que a configuração da criação de partidas que os usa.
1. No painel de navegação, escolha **FlexMatch**, **Conjuntos de regras de criação de partidas**.
1. Na página **Conjuntos de regras de criação de partidas**, escolha **Criar conjunto de regras**.
1. Na página **Criar um conjunto de regras de criação de partidas**, faça o seguinte:
1. Em **Configurações do conjunto de regras**, para **Nome**, insira um nome descritivo exclusivo que você possa usar para identificá-lo em uma lista ou em tabelas de eventos e métricas.
1. Para **Conjunto de regras**, insira o conjunto de regras em JSON. Para obter informações sobre como criar um conjunto de regras, consulte [Criar um conjunto de regras do FlexMatch](match-design-ruleset.md). Também é possível usar um dos exemplos de conjuntos de regras de [Exemplos de configuração de regras do FlexMatch](match-examples.md).
1. Clique em **Validar** para verificar se a sintaxe do conjunto de regras está correta. Não é possível editar conjuntos de regras depois que eles são criados, por isso é uma boa ideia validá-los primeiro.
1. (Opcional) Em **Tags**, adicione tags para ajudar você a gerenciar e monitorar seus recursos da AWS.
1. Escolha **Criar**. Se a criação for bem-sucedida, será possível usar o conjunto de regras como um matchmaker.
------
#### [ AWS CLI ]
**Criar um conjunto de regras**
Abra uma janela de linha de comando e use o comando [create-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-rule-set.html).
Este exemplo cria um conjunto de regras de criação de partidas simples que define uma única equipe. Certifique-se de criar o conjunto de regras na mesma região da AWS que as configurações de criação de partidas que farão referência a ele.
```
aws gamelift create-matchmaking-rule-set \
--name "SampleRuleSet123" \
--rule-set-body '{"name": "aliens_vs_cowboys", "ruleLanguageVersion": "1.0", "teams": [{"name": "cowboys", "maxPlayers": 8, "minPlayers": 4}]}'
```
Se a solicitação de criação for bem-sucedida, o Amazon GameLift Servers retornará um objeto [MatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html) que inclui as configurações que você especificou. Agora um matchmaker pode usar um novo conjunto de regras.
------
------
#### [ Console ]
**Excluir um conjunto de regras**
1. Abra o console Amazon GameLift Servers do em [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/).
1. Alterne para a região na qual você criou o conjunto de regras.
1. No painel de navegação, escolha **FlexMatch**, **Conjuntos de regras de criação de partidas**.
1. Na página **Conjuntos de regras de criação de partidas**, selecione o conjunto de regras que deseja excluir e, em seguida, escolha **Excluir**.
1. Na caixa de diálogo **Excluir conjunto de regras**, escolha **Excluir** para confirmar a exclusão.
**nota**
Se uma configuração de criação de partidas estiver usando o conjunto de regras, o Amazon GameLift Servers exibirá uma mensagem de erro (**Não é possível excluir o conjunto de regras**). Se isso ocorrer, altere a configuração de criação de partidas para usar um conjunto de regras diferente e tente novamente. Para descobrir quais configurações de criação de partidas estão usando um conjunto de regras, escolha o nome de um conjunto de regras para visualizar sua página de detalhes.
------
#### [ AWS CLI ]
**Excluir um conjunto de regras**
Abra uma janela de linha de comando e use o comando [delete-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-matchmaking-rule-set.html) para excluir um conjunto de regras de criação de partidas.
Se uma configuração de criação de partidas estiver usando o conjunto de regras, o Amazon GameLift Servers retornará uma mensagem de erro. Se isso ocorrer, altere a configuração de criação de partidas para usar um conjunto de regras diferente e tente novamente. Para obter uma lista das configurações de criação de partidas que estão usando um conjunto de regras atualmente, use o comando [describe-matchmaking-configurations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-matchmaking-configurations.html) e especifique o nome do conjunto de regras.
Essas verificações de comandos de exemplo do uso do conjunto de regras de criação de partidas e, depois, exclui o conjunto de regras.
```
aws gamelift describe-matchmaking-rule-sets \
--rule-set-name "SampleRuleSet123" \
--limit 10
aws gamelift delete-matchmaking-rule-set \
--name "SampleRuleSet123"
```
------
# Exemplos de configuração de regras do FlexMatch
FlexMatchOs conjuntos de regras do cobrem uma variedade de cenários de criação de partidas. Os exemplos a seguir estão em conformidade com a estrutura de configuração do FlexMatch e o idioma de expressão de propriedade. Copie esses conjuntos de regras em sua totalidade ou escolha componentes, se necessário.
Para obter mais informações sobre o uso das regras e dos conjuntos de regras do FlexMatch, consulte os tópicos a seguir:
**nota**
Ao avaliar um tíquete de criação de partidas que inclui vários jogadores, todos na solicitação precisam atender às exigências da correspondência.
**Topics**
+ [Exemplo: crie duas equipes com jogadores uniformemente correspondentes](match-examples-1.md)
+ [Exemplo: crie equipes irregulares (caçadores x monstro)](match-examples-2.md)
+ [Exemplo: defina exigências no nível da equipe e limites de latência](match-examples-3.md)
+ [Exemplo: use uma classificação explícita para encontrar as melhores correspondências](match-examples-4.md)
+ [Exemplo: encontre interseções em vários atributos de jogador](match-examples-5.md)
+ [Exemplo: compare atributos em todos os jogadores](match-examples-6.md)
+ [Exemplo: crie uma correspondência grande](match-examples-7.md)
+ [Exemplo: crie uma correspondência grande de várias equipes](match-examples-8.md)
+ [Exemplo: crie um jogo grande com jogadores com atributos semelhantes](match-examples-9.md)
+ [Exemplo: use uma regra composta para criar um jogo com jogadores com atributos ou seleções semelhantes](match-examples-10.md)
+ [Exemplo: crie uma regra que use a lista de bloqueios de um jogador](match-examples-11.md)
# Exemplo: crie duas equipes com jogadores uniformemente correspondentes
Este exemplo ilustra como configurar duas equipes com correspondência igual de jogadores com as instruções a seguir.
+ Crie duas equipes de jogadores.
+ Inclua entre quatro e oito jogadores em cada equipe.
+ As equipes finais devem ter o mesmo número de jogadores.
+ Inclua um nível de habilidade do jogador (se não for fornecido, o padrão é 10).
+ Escolha jogadores baseado em se o nível de habilidade deles é semelhante a outros jogadores. Verifique se ambas as equipes têm um nível de habilidade médio por jogador de 10 pontos entre si.
+ Se a correspondência não for preenchida rapidamente, atenue a exigência de habilidade do jogador para concluir uma correspondência em tempo razoável.
+ Depois de 5 segundos, expanda a pesquisa para permitir equipes com habilidades de jogador médias de 50 pontos.
+ Depois de 15 segundos, expanda a pesquisa para permitir equipes com habilidades de jogador médias de 100 pontos.
Observações sobre como usar o conjunto de regras:
+ Este exemplo permite equipes de qualquer tamanho entre quatro e oito jogadores (embora elas precisem ser do mesmo tamanho). Para equipes com uma faixa de tamanhos válida, o marcador de jogos faz uma tentativa de melhor esforço para corresponder ao número máximo de jogadores permitidos.
+ A regra `FairTeamSkill` garante que as equipes sejam uniformemente correlacionadas com base na habilidade do jogador. Para avaliar essa regra para cada novo jogador em potencial, o FlexMatch adiciona o jogador a uma equipe provisoriamente e calcula as médias. Se a regra falhar, o jogador em potencial não será adicionado à correspondência.
+ Como ambas as equipes têm estruturas idênticas, você pode optar por criar apenas uma definição de equipe e definir a quantidade da equipe como "2". Nesse cenário, se você nomeou a equipe como "aliens", suas equipes recebem os nomes "aliens\$11" e "aliens\$12".
```
{
"name": "aliens_vs_cowboys",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
}],
"teams": [{
"name": "cowboys",
"maxPlayers": 8,
"minPlayers": 4
}, {
"name": "aliens",
"maxPlayers": 8,
"minPlayers": 4
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of all players in the match",
"type": "distance",
// get skill values for players in each team and average separately to produce list of two numbers
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get skill values for players in each team, flatten into a single list, and average to produce an overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "EqualTeamSizes",
"description": "Only launch a game when the number of players in each team matches, e.g. 4v4, 5v5, 6v6, 7v7, 8v8",
"type": "comparison",
"measurements": [ "count(teams[cowboys].players)" ],
"referenceValue": "count(teams[aliens].players)",
"operation": "=" // other operations: !=, <, <=, >, >=
}],
"expansions": [{
"target": "rules[FairTeamSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 5,
"value": 50
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# Exemplo: crie equipes irregulares (caçadores x monstro)
Este exemplo descreve um modo de jogo em que um grupo de jogadores caça um único monstro. As pessoas escolhem a função de um caçador ou de um monstro. Os caçadores especificam o nível de habilidade mínimo para o monstro que eles querem enfrentar. O tamanho mínimo da equipe do caçador pode ser atenuado ao longo do tempo para concluir a correspondência. Este cenário define as instruções a seguir:
+ Crie uma equipe de exatamente cinco caçadores.
+ Crie uma equipe separada de exatamente um monstro.
+ Inclua os atributos de jogador a seguir:
+ O nível de habilidade de um jogador (se não for fornecido, o padrão é 10).
+ O nível de habilidade preferido do monstro de um jogador (se não for fornecido, o padrão é 10).
+ Se o jogador deseja ser o monstro (se não for fornecido, o padrão é 0 ou falso).
+ Escolha um jogador para ser o monstro com base nos seguintes critérios:
+ O jogador deve solicitar a função do monstro.
+ O jogador deve atender ou exceder o nível mais alto de habilidade preferido pelos jogadores que já foram adicionados à equipe do caçador.
+ Escolha jogadores para a equipe do caçador com base nos seguintes critérios:
+ Os jogadores que solicitam a função do monstro não podem entrar na equipe do caçador.
+ Se a função do monstro já tiver sido preenchida, o jogador poderá querer um nível de habilidade de monstro que seja inferior à habilidade do monstro proposto.
+ Se uma correspondência não for preenchida rapidamente, atenue o tamanho mínimo da equipe do caçador da seguinte forma:
+ Após 30 segundos, permita que um jogo inicie com apenas quatro jogadores na equipe do caçador.
+ Após 60 segundos, permita que um jogo inicie com apenas três pessoas na equipe do caçador.
Observações sobre como usar o conjunto de regras:
+ Usando duas equipes separadas para caçadores e monstro, você pode avaliar a associação com base em conjuntos diferentes de critérios.
```
{
"name": "players_vs_monster_5_vs_1",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "desiredSkillOfMonster",
"type": "number",
"default": 10
},{
"name": "wantsToBeMonster",
"type": "number",
"default": 0
}],
"teams": [{
"name": "players",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "monster",
"maxPlayers": 1,
"minPlayers": 1
}],
"rules": [{
"name": "MonsterSelection",
"description": "Only users that request playing as monster are assigned to the monster team",
"type": "comparison",
"measurements": ["teams[monster].players.attributes[wantsToBeMonster]"],
"referenceValue": 1,
"operation": "="
},{
"name": "PlayerSelection",
"description": "Do not place people who want to be monsters in the players team",
"type": "comparison",
"measurements": ["teams[players].players.attributes[wantsToBeMonster]"],
"referenceValue": 0,
"operation": "="
},{
"name": "MonsterSkill",
"description": "Monsters must meet the skill requested by all players",
"type": "comparison",
"measurements": ["avg(teams[monster].players.attributes[skill])"],
"referenceValue": "max(teams[players].players.attributes[desiredSkillOfMonster])",
"operation": ">="
}],
"expansions": [{
"target": "teams[players].minPlayers",
"steps": [{
"waitTimeSeconds": 30,
"value": 4
},{
"waitTimeSeconds": 60,
"value": 3
}]
}]
}
```
# Exemplo: defina exigências no nível da equipe e limites de latência
Este exemplo ilustra como configurar as equipes de jogadores e aplicar um conjunto de regras a cada equipe em vez de cada jogador individual. Ele usa uma única definição para criar três equipes correspondentes iguais. Ele também estabelece uma latência máxima para todos os jogadores. Os máximos de latência podem ser atenuados ao longo do tempo para concluir a correspondência. Este exemplo define as instruções a seguir:
+ Crie três equipes de jogadores.
+ Inclua entre três e cinco jogadores em cada equipe.
+ As equipes finais devem conter aproximadamente ou o mesmo número de jogadores (em uma equipe).
+ Inclua os atributos de jogador a seguir:
+ O nível de habilidade de um jogador (se não for fornecido, o padrão é 10).
+ A função do personagem de um jogador (se não for fornecida, o padrão é "camponês").
+ Escolha jogadores com base em se o nível de habilidade deles é semelhante a outros jogadores na correspondência.
+ Verifique se cada equipe tem uma habilidade de jogador média de 10 pontos entre si.
+ Limite as equipes ao número seguinte de personagens “médicos”:
+ Uma correspondência inteira pode ter um máximo de cinco médicos.
+ Somente faz a correspondência de jogadores que mostram latência de até 50 milissegundos.
+ Se uma correspondência não for preenchida rapidamente, atenue a exigência de latência de jogador, da seguinte forma:
+ Após 10 segundos, permita valores de latência de jogador de até 100 ms.
+ Após 20 segundos, permita valores de latência de jogador de até 150 ms.
Observações sobre como usar o conjunto de regras:
+ O conjunto de regras garante que as equipes sejam uniformemente correspondidas com base na habilidade do jogador. Para avaliar a regra `FairTeamSkill`, o FlexMatch timidamente adiciona o jogador em potencial a uma equipe e calcula a habilidade média dos jogadores na equipe. Depois, ele compara com a habilidade média nas duas equipes. Se a regra falhar, o jogador em potencial não será adicionado à correspondência.
+ As exigências de nível de correspondência e da equipe (número total de médicos) são atendidas por meio de uma regra de coleção. Esse tipo de regra usa uma lista de atributos de personagem para todos os jogadores e verifica em relação às contagens máximas. Use `flatten` para criar uma lista de todos os jogadores em todas as equipes.
+ Ao avaliar com base na latência, observe o seguinte:
+ Os dados de latência são fornecidos na solicitação de criação de partidas como parte do objeto Player. Não se trata de um atributo de jogador; portanto, não é preciso ser listado como tal. Para obter medições precisas de latência, use os sinalizadores de ping UDP do Amazon GameLift Servers. Esses endpoints permitem medir a latência real da rede UDP entre dispositivos de jogadores e cada um dos possíveis locais de hospedagem, resultando em decisões de posicionamento mais precisas do que o uso de pings ICMP. Para obter mais informações sobre o uso de sinalizadores de ping UDP para medir a latência, consulte [sinalizadores de ping UDP](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html).
+ O marcador de jogos avalia a latência de acordo com a região. Qualquer região com uma latência mais alta do que o máximo é ignorada. Para ser aceito para uma correspondência, um jogador deve ter pelo menos uma região com uma latência abaixo do máximo.
+ Se uma solicitação de criação de partidas omitir dados de latência de um ou mais jogadores, ela será rejeitada em todas as partidas.
```
{
"name": "three_team_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "character",
"type": "string_list",
"default": [ "peasant" ]
}],
"teams": [{
"name": "trio",
"minPlayers": 3,
"maxPlayers": 5,
"quantity": 3
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of players in the match",
"type": "distance",
// get players for each team, and average separately to produce list of 3
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get players for each team, flatten into a single list, and average to produce overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "CloseTeamSizes",
"description": "Only launch a game when the team sizes are within 1 of each other. e.g. 3 v 3 v 4 is okay, but not 3 v 5 v 5",
"type": "distance",
"measurements": [ "max(count(teams[*].players))"],
"referenceValue": "min(count(teams[*].players))",
"maxDistance": 1
}, {
"name": "OverallMedicLimit",
"description": "Don't allow more than 5 medics in the game",
"type": "collection",
// This is similar to above, but the flatten flattens everything into a single
// list of characters in the game.
"measurements": [ "flatten(teams[*].players.attributes[character])"],
"operation": "contains",
"referenceValue": "medic",
"maxCount": 5
}, {
"name": "FastConnection",
"description": "Prefer matches with fast player connections first",
"type": "latency",
"maxLatency": 50
}],
"expansions": [{
"target": "rules[FastConnection].maxLatency",
"steps": [{
"waitTimeSeconds": 10,
"value": 100
}, {
"waitTimeSeconds": 20,
"value": 150
}]
}]
}
```
# Exemplo: use uma classificação explícita para encontrar as melhores correspondências
Este exemplo configura uma correspondência simples com duas equipes de três jogadores. Ele ilustra como usar as regras de classificação explícitas para ajudar a encontrar as melhores correspondências o mais rápido possível. Essas regras classificam todos os tíquetes de criação de partidas ativos para criar as melhores correspondências com base em determinadas exigências principais. Este exemplo é implementado com as seguintes instruções:
+ Crie duas equipes de jogadores.
+ Inclua exatamente três jogadores em cada equipe.
+ Inclua os atributos de jogador a seguir:
+ Nível de experiência (se não for fornecido, o padrão é 50).
+ Modos de jogo preferidos (pode listar vários valores) (se não forem fornecidos, os padrões são “cooperação” e “combate mortal”).
+ Mapas de jogo preferidos, incluindo o nome do mapa e ponderação preferida (se não for fornecido, o padrão é `"defaultMap"` com um peso 100).
+ Configurar pré-classificação:
+ Classifique os jogadores com base na preferência pelo mesmo mapa de jogo que o jogador âncora. Os jogadores podem ter vários mapas de jogo favoritos, portanto, este exemplo usa um valor preferencial.
+ Classifique os jogadores com base na proximidade do nível de experiência deles com a do jogador âncora. Com essa classificação, todos os jogadores em todas as equipes terão níveis de experiência o mais próximos possíveis.
+ Todos os jogadores em todas as equipes precisam ter selecionado pelo menos um modo de jogo em comum.
+ Todos os jogadores em todas as equipes precisam ter selecionado pelo menos um mapa de jogo em comum.
Observações sobre como usar o conjunto de regras:
+ A classificação do mapa de jogo usa uma classificação absoluta que compara o valor do atributo mapPreference. Como é o primeiro no conjunto de regras, esse tipo é realizado primeiro.
+ A classificação da experiência usa uma classificação de distância para comparar um nível de habilidade do jogador em potencial com a habilidade do jogador âncora.
+ As classificações são feitas na ordem que são listadas em um conjunto de regras. Neste cenário, os jogadores são classificados pela preferência de mapa de jogo e depois pelo nível de experiência.
```
{
"name": "multi_map_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "experience",
"type": "number",
"default": 50
}, {
"name": "gameMode",
"type": "string_list",
"default": [ "deathmatch", "coop" ]
}, {
"name": "mapPreference",
"type": "string_number_map",
"default": { "defaultMap": 100 }
}, {
"name": "acceptableMaps",
"type": "string_list",
"default": [ "defaultMap" ]
}],
"teams": [{
"name": "red",
"maxPlayers": 3,
"minPlayers": 3
}, {
"name": "blue",
"maxPlayers": 3,
"minPlayers": 3
}],
"rules": [{
// We placed this rule first since we want to prioritize players preferring the same map
"name": "MapPreference",
"description": "Favor grouping players that have the highest map preference aligned with the anchor's favorite",
// This rule is just for sorting potential matches. We sort by the absolute value of a field.
"type": "absoluteSort",
// Highest values go first
"sortDirection": "descending",
// Sort is based on the mapPreference attribute.
"sortAttribute": "mapPreference",
// We find the key in the anchor's mapPreference attribute that has the highest value.
// That's the key that we use for all players when sorting.
"mapKey": "maxValue"
}, {
// This rule is second because any tie-breakers should be ordered by similar experience values
"name": "ExperienceAffinity",
"description": "Favor players with similar experience",
// This rule is just for sorting potential matches. We sort by the distance from the anchor.
"type": "distanceSort",
// Lowest distance goes first
"sortDirection": "ascending",
"sortAttribute": "experience"
}, {
"name": "SharedMode",
"description": "The players must have at least one game mode in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[gameMode])"],
"minCount": 1
}, {
"name": "MapOverlap",
"description": "The players must have at least one map in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[acceptableMaps])"],
"minCount": 1
}]
}
```
# Exemplo: encontre interseções em vários atributos de jogador
Este exemplo ilustra como usar uma regra de coleta para encontrar interseções em dois ou mais atributos do jogador. Ao trabalhar com coleções, você pode usar a operação `intersection` para um único atributo e a operação `reference_intersection_count` para vários atributos.
Para ilustrar essa abordagem, o exemplo avalia os jogadores em uma partida com base nas preferências dos seus personagens. O jogo de exemplo é um estilo free-for-all "" no qual todos os jogadores de uma partida são adversários. Cada jogador deve (1) escolher um personagem para si e (2) escolher os personagens adversários. Precisamos de uma regra que garanta que todos os jogadores em uma partida estejam usando um personagem na lista de oponentes preferidos de todos os outros jogadores.
O conjunto de regras de exemplo descreve uma correspondência com as seguintes características:
+ Estrutura da equipe: uma equipe com cinco jogadores
+ Atributos do jogador:
+ *myCharacter*: o personagem escolhido pelo jogador.
+ *preferredOpponents*: lista de personagens contra os quais o jogador quer jogar.
+ Regras de correspondência: uma correspondência potencial é aceitável se cada personagem em uso estiver na lista de oponentes preferidos de todos os jogadores.
Para implementar a regra de correspondência, este exemplo usa uma regra de coleta com os seguintes valores de propriedade:
+ Operação: usa a operação `reference_intersection_count` para avaliar como cada lista de strings no valor de medição intercepta a lista de strings no valor de referência.
+ Medição: usa a expressão de propriedade `flatten` para criar listas de strings, cada uma delas contendo o valor do atributo de um jogador *myCharacter*.
+ Valor de referência: usa a expressão de propriedade `set_intersection` para criar uma lista de strings de todos os valores de atributo *preferredOpponents* comuns a todos os jogadores no jogo.
+ Restrições: `minCount` é definido como 1 para garantir que o personagem escolhido de cada jogador (uma lista strings na medição) corresponda a pelo menos um dos oponentes preferidos comuns a todos os jogadores (uma string no valor de referência).
+ Expansão: Se uma correspondência não for feita em 15 segundos, ajuste o requisito mínimo de interseção.
O fluxo do processo para esta regra é o seguinte:
1. Um jogador é adicionado ao jogo em potencial. O valor de referência (uma lista de strings) é recalculado para incluir interseções com a lista de oponentes preferidos do novo jogador. O valor de medição (uma lista das listas de strings) é recalculado para adicionar o caractere escolhido do novo jogador como uma nova lista de strings.
1. O Amazon GameLift Servers verifica se cada lista de strings no valor de medição (caracteres escolhidos pelos jogadores) faz intersecção com pelo menos uma string no valor de referência (oponentes preferidos dos jogadores). Neste exemplo, como cada lista de strings na medição contém apenas um valor, a interseção é 0 ou 1.
1. Se alguma lista de strings na medição não fizer interseção com a lista de strings dos valores de referência, a regra falhará e o novo jogador será removido da correspondência em potencial.
1. Se uma partida não for preenchida em 15 segundos, elimine o requisito de correspondência do oponente para preencher os slots restantes do jogador na partida.
```
{
"name": "preferred_characters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "myCharacter",
"type": "string_list"
}, {
"name": "preferredOpponents",
"type": "string_list"
}],
"teams": [{
"name": "red",
"minPlayers": 5,
"maxPlayers": 5
}],
"rules": [{
"description": "Make sure that all players in the match are using a character that is on all other players' preferred opponents list.",
"name": "OpponentMatch",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": ["flatten(teams[*].players.attributes[myCharacter])"],
"referenceValue": "set_intersection(flatten(teams[*].players.attributes[preferredOpponents]))",
"minCount":1
}],
"expansions": [{
"target": "rules[OpponentMatch].minCount",
"steps": [{
"waitTimeSeconds": 15,
"value": 0
}]
}]
}
```
# Exemplo: compare atributos em todos os jogadores
Este exemplo ilustra como comparar os atributos do jogador em um grupo de jogadores.
O conjunto de regras de exemplo descreve uma correspondência com as seguintes características:
+ Estrutura da equipe: duas equipes de jogadores únicos
+ Atributos do jogador:
+ *gameMode*: tipo de jogo escolhido pelo jogador (se não for fornecido, o valor padrão será "turn-based").
+ *gameMap*: mundo do jogo escolhido pelo jogador (se não for fornecido, o valor padrão será 1).
+ *character*: o personagem escolhido pelo jogador (se não houver nenhum valor padrão, significa que os jogadores precisarão especificar um personagem).
+ Regras de jogo: os jogadores correspondentes precisam atender aos seguintes requisitos:
+ Os jogadores devem escolher o mesmo modo de jogo.
+ Os jogadores devem escolher o mesmo mapa de jogo.
+ Os jogadores precisam escolher personagens diferentes.
Observações sobre como usar o conjunto de regras:
+ Para implementar a regra de correspondência, este exemplo usa regras de comparação de modo a verificar os valores de atributos de todos os jogadores. Para modo de jogo e mapa, a regra verifica se os valores são os mesmos. Para caractere, a regra verifica se os valores são diferentes.
+ Este exemplo usa uma definição de jogador com uma propriedade de quantidade para criar as duas equipes de jogadores. Eles recebem os nomes: "jogador\$11" e "jogador\$12".
```
{
"name": "",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "gameMode",
"type": "string",
"default": "turn-based"
}, {
"name": "gameMap",
"type": "number",
"default": 1
}, {
"name": "character",
"type": "number"
}],
"teams": [{
"name": "player",
"minPlayers": 1,
"maxPlayers": 1,
"quantity": 2
}],
"rules": [{
"name": "SameGameMode",
"description": "Only match players when they choose the same game type",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMode])"]
}, {
"name": "SameGameMap",
"description": "Only match players when they're in the same map",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMap])"]
}, {
"name": "DifferentCharacter",
"description": "Only match players when they're using different characters",
"type": "comparison",
"operation": "!=",
"measurements": ["flatten(teams[*].players.attributes[character])"]
}]
}
```
# Exemplo: crie uma correspondência grande
Este exemplo ilustra como configurar um conjunto de regras para correspondências que podem exceder 40 jogadores. Quando um conjunto de regras descreve as equipes com uma contagem total de maxPlayer maior que 40, ele é processado como uma correspondência grande. Saiba mais em [Criar uma conjunto de regras de correspondência grande do FlexMatch](match-design-rulesets-large.md).
O exemplo cria um conjunto de regras de correspondências usando as seguintes instruções:
+ Crie uma equipe com até 200 jogadores, com um requisito mínimo de 175 jogadores.
+ Critérios de balanceamento: selecione jogadores com base no nível de habilidade semelhantes. Todos os jogadores devem informar o nível de habilidade deles para a correspondência ser feita.
+ Preferência de agrupamento: faça grupos de jogadores por critérios de balanceamento semelhantes ao criar correspondências.
+ Regras de latência: defina a latência máxima aceitável do jogador como 150 milissegundos.
+ Se a correspondência não for preenchida rapidamente, atenue a exigência para concluir uma correspondência em tempo razoável.
+ Após 10 segundos, aceite uma equipe com 150 jogadores.
+ Após 12 segundos, eleve a latência aceitável para 200 milissegundos.
+ Depois de 15 segundos, aceite uma equipe com 100 jogadores.
Observações sobre como usar o conjunto de regras:
+ Como o algoritmo usa a preferência de processamento em grupos "maior população" primeiro, os jogadores são classificados com base nos critérios de balanceamento. Como resultado, as correspondências tendem a ser mais completas e conter jogadores mais semelhantes em relação à habilidade. Todos os jogadores atendem aos requisitos de latência aceitáveis, mas podem não ter a melhor latência possível para sua localização.
+ A estratégia de algoritmo usada neste conjunto de regras, "maior população", é a configuração padrão. Para usar o padrão, você pode optar por omitir a configuração.
+ Se você tiver habilitado a alocação de correspondência, não diminua os requisitos de contagem de jogadores muito rapidamente, ou você pode acabar com muitas sessões de jogos parcialmente preenchidas. Saiba mais em [Diminuir os requisitos de correspondências grandes](match-design-rulesets-large-relax.md).
```
{
"name": "free-for-all",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number"
}],
"algorithm": {
"balancedAttribute": "skill",
"strategy": "balanced",
"batchingPreference": "largestPopulation"
},
"teams": [{
"name": "Marauders",
"maxPlayers": 200,
"minPlayers": 175
}],
"rules": [{
"name": "low-latency",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "rules[low-latency].maxLatency",
"steps": [{
"waitTimeSeconds": 12,
"value": 200
}],
}, {
"target": "teams[Marauders].minPlayers",
"steps": [{
"waitTimeSeconds": 10,
"value": 150
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# Exemplo: crie uma correspondência grande de várias equipes
Este exemplo ilustra como configurar um conjunto de regras para correspondências de várias equipes que podem exceder 40 jogadores. Este exemplo ilustra como criar várias equipes idênticas com uma definição e como as equipes de tamanho assimétrico são preenchidas durante a criação de correspondência.
O exemplo cria um conjunto de regras de correspondências usando as seguintes instruções:
+ Crie dez idênticas equipes idênticas de "caçadores" com até 15 jogadores, e uma equipe de "monstros" com exatamente 5 jogadores.
+ Critérios de balanceamento: selecione os jogadores com base no número de mortes de monstros. Se os jogadores não relatarem a contagem de mortes, use um valor padrão de 5.
+ Preferência de agrupamento: agrupe os jogadores com base nas regiões em que mostram a latência mais rápida.
+ Regra de latência: defina um máximo aceitável de latência de 200 milissegundos para o jogador.
+ Se a correspondência não for preenchida rapidamente, atenue a exigência para concluir uma correspondência em tempo razoável.
+ Depois de 15 segundos, aceite equipes com 10 jogadores.
+ Após 20 segundos, aceite equipes com 8 jogadores.
Observações sobre como usar o conjunto de regras:
+ Esse conjunto de regras define equipes que podem ter até 155 jogadores, o que faz a correspondência ser grande. (10 x 15 caçadores \$1 5 monstros = 155)
+ Como o algoritmo usa a preferência de agrupamento por "região mais rápida", os jogadores tendem a ser colocados em regiões onde mostram latência mais rápida e não em regiões de latência mas alta (mas é aceitável). Ao mesmo tempo, as correspondências podem ter um número menor de jogadores, e os critérios de balanceamento de monstros (número de habilidades) pode variar mais.
+ Quando uma expansão é definida para uma definição de várias equipes (quantidade > 1), ela se aplica a todas as equipes criadas com essa definição. Portanto, diminuir o tamanho mínimo da equipe de caçadores faz com que todas as dez equipes de caçadores sejam impactadas igualmente.
+ Como esse conjunto de regras é otimizado para minimizar a latência do jogador, a latência atua como uma regra genérica para excluir os jogadores que não têm opções de conexão aceitáveis. Não precisamos diminuir essa exigência.
+ Veja como o FlexMatch preenche as correspondências para esse conjunto de regras antes de qualquer expansão entrar em vigor:
+ Nenhuma equipe atingiu a contagem minPlayers até agora. As equipes de caçadores têm 15 slots abertos, enquanto a equipe de monstros tem 5 slots abertos.
+ Os primeiros 100 jogadores são atribuídos (10 cada) às 10 equipes de caçadores.
+ Os próximos 22 jogadores são atribuídos sequencialmente (2 para cada) às equipes de caçadores e à equipe de monstros.
+ As equipes de caçadores atingiram a contagem minPlayers de 12 jogadores cada. A equipe de monstros tem dois jogadores e não atingiu a contagem minPlayers.
+ Os próximos três jogadores são atribuídos à equipe de monstros.
+ Todas as equipes atingiram a contagem minPlayers. As equipes de caçadores têm três slots abertos cada uma. A equipe de monstros está cheia.
+ Os últimos 30 jogadores são atribuídos sequencialmente às equipes de caçadores, garantindo que todas as equipes têm praticamente o mesmo tamanho (um jogador a mais ou a menos).
+ Se você tiver habilitado a alocação para correspondências criadas dentro desse conjunto de regras, não diminua os requisitos de contagem de jogadores muito rapidamente, ou você pode acabar com muitas sessões de jogos parcialmente preenchidas. Saiba mais em [Diminuir os requisitos de correspondências grandes](match-design-rulesets-large-relax.md).
```
{
"name": "monster-hunters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "monster-kills",
"type": "number",
"default": 5
}],
"algorithm": {
"balancedAttribute": "monster-kills",
"strategy": "balanced",
"batchingPreference": "fastestRegion"
},
"teams": [{
"name": "Monsters",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "Hunters",
"maxPlayers": 15,
"minPlayers": 12,
"quantity": 10
}],
"rules": [{
"name": "latency-catchall",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "teams[Hunters].minPlayers",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 20,
"value": 8
}]
}]
}
```
# Exemplo: crie um jogo grande com jogadores com atributos semelhantes
Este exemplo ilustra como configurar um conjunto de regras para jogos com duas equipes usando `batchDistance`. No exemplo:
+ A regra `SimilarLeague` garante que todos os jogadores em uma partida tenham `league` em 2 dos outros jogadores.
+ A regra `SimilarSkill` garante que todos os jogadores em uma partida tenham `skill` em 10 dos outros jogadores. Se um jogador estiver esperando 10 segundos, a distância será expandida para 20. Se um jogador estiver esperando 20 segundos, a distância será expandida para 40.
+ A regra `SameMap` garante que todos os jogadores de um jogo tenham solicitado o mesmo `map`.
+ A regra `SameMode` garante que todos os jogadores de um jogo tenham solicitado o mesmo `mode`.
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 100,
"maxPlayers": 100
}, {
"name": "blue",
"minPlayers": 100,
"maxPlayers": 100
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeague",
"type": "batchDistance",
"batchAttribute": "league",
"maxDistance": 2
}, {
"name": "SimilarSkill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 10
}, {
"name": "SameMap",
"type": "batchDistance",
"batchAttribute": "map"
}, {
"name": "SameMode",
"type": "batchDistance",
"batchAttribute": "mode"
}],
"expansions": [{
"target": "rules[SimilarSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# Exemplo: use uma regra composta para criar um jogo com jogadores com atributos ou seleções semelhantes
Este exemplo ilustra como configurar um conjunto de regras para jogos com duas equipes usando `compound`. No exemplo:
+ A regra `SimilarLeagueDistance` garante que todos os jogadores em uma partida tenham `league` em 2 dos outros jogadores.
+ A regra `SimilarSkillDistance` garante que todos os jogadores em uma partida tenham `skill` em 10 dos outros jogadores. Se um jogador estiver esperando 10 segundos, a distância será expandida para 20. Se um jogador estiver esperando 20 segundos, a distância será expandida para 40.
+ A regra `SameMapComparison` garante que todos os jogadores de um jogo tenham solicitado o mesmo `map`.
+ A regra `SameModeComparison` garante que todos os jogadores de um jogo tenham solicitado o mesmo `mode`.
+ A regra `CompoundRuleMatchmaker` garante uma correspondência se pelo menos uma das seguintes condições for true:
+ Os jogadores de um jogo solicitaram o mesmo `map` e o mesmo `mode`.
+ Os jogadores de um jogo têm `skill` atributos `league` e atributos comparáveis.
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 10,
"maxPlayers": 20
}, {
"name": "blue",
"minPlayers": 10,
"maxPlayers": 20
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeagueDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[league]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[league]))",
"maxDistance": 2
}, {
"name": "SimilarSkillDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[skill]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10
}, {
"name": "SameMapComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[map])"]
}, {
"name": "SameModeComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[mode])"]
}, {
"name": "CompoundRuleMatchmaker",
"type": "compound",
"statement": "or(and(SameMapComparison, SameModeComparison), and(SimilarSkillDistance, SimilarLeagueDistance))"
}],
"expansions": [{
"target": "rules[SimilarSkillDistance].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# Exemplo: crie uma regra que use a lista de bloqueios de um jogador
Este exemplo ilustra um conjunto de regras que permite que os jogadores evitem ser pareados com outros jogadores. Os jogadores podem criar uma lista de bloqueios, que o matchmaker avalia durante a seleção de jogadores para um jogo. Para obter mais orientações sobre como adicionar uma lista de bloqueios ou o atributo de evitar listas, consulte [AWS para blog de jogos](https://aws.amazon.com/blogs/gametech/category/game-development/amazon-gamelift/).
Este exemplo define as instruções a seguir:
+ Crie duas equipes de exatamente cinco jogadores.
+ Passe a lista de bloqueio de um jogador, que é uma lista de jogadores IDs (até 100).
+ Compare todos os jogadores com a lista de bloqueios de cada jogador e rejeite uma partida proposta se algum jogador bloqueado IDs for encontrado.
Observações sobre como usar o conjunto de regras:
+ Ao avaliar um novo jogador para adicionar a um jogo proposto (ou preencher uma vaga em um jogo existente), o jogador pode ser rejeitado por um dos seguintes motivos:
+ Se o novo jogador estiver na lista de bloqueio de qualquer jogador que já tenha sido selecionado para o jogo.
+ Se qualquer jogador que já tenha sido selecionado para o jogo estiver na nova lista de bloqueio de jogadores.
+ Conforme mostrado, esse conjunto de regras impede combinar um jogador com qualquer jogador em sua lista de bloqueio. Você pode alterar esse requisito para uma preferência (também chamada de lista de “evitar”) adicionando uma expansão de regra e aumentando o valor `maxCount`.
```
{
"name": "Player Block List",
"ruleLanguageVersion": "1.0",
"teams": [{
"maxPlayers": 5,
"minPlayers": 5,
"name": "red"
}, {
"maxPlayers": 5,
"minPlayers": 5,
"name": "blue"
}],
"playerAttributes": [{
"name": "BlockList",
"type": "string_list",
"default": []
}],
"rules": [{
"name": "PlayerIdNotInBlockList",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": "flatten(teams[*].players.attributes[BlockList])",
"referenceValue": "flatten(teams[*].players[playerId])",
"maxCount": 0
}]
}
```