Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Costruisci un FlexMatch set di regole
Ogni FlexMatch il matchmaker deve avere un set di regole. Il set di regole determina i due elementi chiave di un abbinamento: la struttura e le dimensioni dei team del tuo gioco e la modalità di raggruppamento dei giocatori per il migliore abbinamento possibile.
Ad esempio, un set di regole potrebbe descrivere una corrispondenza come questa: crea una corrispondenza con due squadre di cinque giocatori ciascuna, una costituita da difensori e un'altra da invasori. Una squadra può avere giocatori alle prime armi ed esperti, ma l'abilità media delle due squadre deve essere entro 10 punti l'una dall'altra. Se non viene effettuato alcun abbinamento dopo 30 secondi, rendi gradualmente più flessibili i requisiti di abilità.
Gli argomenti in questa sezione descrivono come progettare e creare un set di regole di abbinamento. Quando si crea un set di regole, è possibile utilizzare uno dei Amazon GameLift Servers console o AWS CLI.
**Topics**
+ [Progetta un set di FlexMatch regole](match-design-ruleset.md)
+ [Progetta un set di regole per FlexMatch partite di grandi dimensioni](match-design-rulesets-large.md)
+ [Tutorial: Crea un set di regole di matchmaking](match-create-ruleset.md)
+ [FlexMatchesempi di set di regole](match-examples.md)
# Progetta un set di FlexMatch regole
Questo argomento tratta la struttura di base di un set di regole e come creare un set di regole per piccole partite fino a 40 giocatori. Un set di regole di matchmaking fa due cose: definisce la struttura e le dimensioni della squadra di una partita e indica al matchmaker come scegliere i giocatori per formare la migliore partita possibile.
Ma il tuo set di regole di matchmaking può fare di più. Ad esempio, puoi:
+ Ottimizza l'algoritmo di matchmaking per il tuo gioco.
+ Imposta i requisiti minimi di latenza dei giocatori per proteggere la qualità del gioco.
+ Riduci gradualmente i requisiti di squadra e le regole delle partite nel tempo, in modo che tutti i giocatori attivi possano trovare una partita accettabile quando ne vogliono una.
+ Definisci la gestione delle richieste di matchmaking di gruppo utilizzando l'aggregazione dei gruppi.
+ Elabora partite di grandi dimensioni con 40 o più giocatori. Per ulteriori informazioni sulla creazione di partite di grandi dimensioni, vedi[Progetta un set di regole per FlexMatch partite di grandi dimensioni](match-design-rulesets-large.md).
Quando crei un set di regole di matchmaking, considera le seguenti attività facoltative e obbligatorie:
+ [Descrivi il set di regole (obbligatorio)](match-rulesets-components-set.md)
+ [Personalizza l'algoritmo di corrispondenza](match-rulesets-components-algorithm.md)
+ [Dichiara gli attributi del giocatore](match-rulesets-components-attributes.md)
+ [Definisci le squadre di gioco](match-rulesets-components-teams.md)
+ [Stabilisci le regole per l'abbinamento dei giocatori](match-rulesets-components-rules.md)
+ [Consenti ai requisiti di attenuarsi nel tempo](match-rulesets-components-expansion.md)
Puoi creare il tuo set di regole utilizzando la Amazon GameLift Servers console o l'`[CreateMatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateMatchmakingRuleSet.html)`operazione.
# Descrivi il set di regole (obbligatorio)
Fornisci i dettagli per il set di regole.
+ *nome* (opzionale) — Un'etichetta descrittiva per uso personale. Questo valore non è associato al nome del set di regole specificato durante la creazione del set di regole conAmazon GameLift Servers.
+ *ruleLanguageVersion*— La versione del linguaggio delle espressioni di proprietà utilizzato per creare FlexMatch le regole. Il valore deve essere `1.0`.
# Personalizza l'algoritmo di corrispondenza
FlexMatchottimizza l'algoritmo predefinito per la maggior parte dei giochi per far sì che i giocatori accedano a partite accettabili con tempi di attesa minimi. Puoi personalizzare l'algoritmo e adattare il matchmaking al tuo gioco.
Quello che segue è l'algoritmo di FlexMatch matchmaking predefinito:
1. FlexMatchinserisce tutti i ticket di matchmaking aperti e riempie i ticket in un pool di biglietti.
1. FlexMatchraggruppa casualmente i biglietti del pool in uno o più lotti. Man mano che il pool di ticket si ingrandisce, FlexMatch forma lotti aggiuntivi per mantenere una dimensione ottimale dei batch.
1. FlexMatchordina i biglietti per età, all'interno di ogni batch.
1. FlexMatchcrea una partita sulla base del ticket più vecchio di ogni lotto.
Per personalizzare l'algoritmo di corrispondenza, aggiungi un `algorithm` componente allo schema del set di regole. Vedi [FlexMatch schema del set di regole](match-ruleset-schema.md) per le informazioni di riferimento complete.
Utilizza le seguenti personalizzazioni opzionali per influire sulle diverse fasi del processo di matchmaking.
+ [Aggiungi l'ordinamento pre-batch](#match-rulesets-components-algorithm-presort)
+ [Batch di moduli basati sugli attributi BatchDistance](https://docs.aws.amazon.com//gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html#match-rules-reference-ruletype-batchdistance)
+ [Dai priorità ai ticket di riempimento](#match-rulesets-components-algorithm-backfill)
+ [Preferisci i biglietti più vecchi con le espansioni](#match-rulesets-components-algorithm-expansion)
## Aggiungi l'ordinamento pre-batch
Puoi ordinare il pool di biglietti prima di formare i batch. Questo tipo di personalizzazione è più efficace con giochi con grandi pool di biglietti. L'ordinamento pre-batch può aiutare ad accelerare il processo di matchmaking e ad aumentare l'uniformità dei giocatori nelle caratteristiche definite.
Definisci i metodi di ordinamento pre-batch utilizzando la proprietà algorithm. `batchingPreference` L'impostazione predefinita è `random`.
Le opzioni per personalizzare l'ordinamento pre-batch includono:
+ **Ordina per attributi del giocatore.** Fornisci un elenco di attributi del giocatore per preordinare il pool di biglietti.
Per ordinare in base agli attributi del giocatore, imposta `batchingPreference` e definisci l'elenco degli attributi del giocatore in`sortByAttributes`. `sorted` Per usare un attributo, devi prima dichiararlo nel `playerAttributes` componente del set di regole.
Nell'esempio seguente, FlexMatch ordina il pool di biglietti in base alla mappa di gioco preferita dai giocatori e quindi in base alle abilità del giocatore. È più probabile che i batch risultanti contengano giocatori con abilità simili che desiderano utilizzare la stessa mappa.
```
"algorithm": {
"batchingPreference": "sorted",
"sortByAttributes": ["map", "player_skill"],
"strategy": "exhaustiveSearch"
},
```
+ **Ordina per latenza.** Crea corrispondenze con la latenza più bassa disponibile o crea rapidamente corrispondenze con una latenza accettabile. Questa personalizzazione è utile per i set di regole che formano partite di grandi dimensioni con più di 40 giocatori.
Imposta la proprietà dell'algoritmo `strategy` su`balanced`. La strategia bilanciata limita i tipi disponibili di istruzioni delle regole. Per ulteriori informazioni, consulta [Progetta un set di regole per FlexMatch partite di grandi dimensioni](match-design-rulesets-large.md).
FlexMatchordina i ticket in base ai dati di latenza riportati dai giocatori in uno dei seguenti modi:
+ *posizioni con la latenza più bassa.* Il pool di biglietti è preordinato in base alle località in cui i giocatori segnalano i valori di latenza più bassi. FlexMatchquindi raggruppa i ticket a bassa latenza nelle stesse posizioni, creando un'esperienza di gioco migliore. Riduce anche il numero di ticket in ogni lotto, quindi il matchmaking può richiedere più tempo. Per utilizzare questa personalizzazione, imposta `batchingPreference` su`fastestRegion`, come mostrato nell'esempio seguente.
```
"algorithm": {
"batchingPreference": "fastestRegion",
"strategy": "balanced"
},
```
+ *La latenza accettabile corrisponde rapidamente.* Il pool di biglietti è preordinato in base alle località in cui i giocatori segnalano un valore di latenza accettabile. Ciò forma un minor numero di lotti contenenti più biglietti. Con più biglietti in ogni lotto, trovare partite accettabili è più veloce. Per utilizzare questa personalizzazione, impostate la proprietà `batchingPreference` su` largestPopulation`, come illustrato nell'esempio seguente.
```
"algorithm": {
"batchingPreference": "largestPopulation",
"strategy": "balanced"
},
```
**Nota**
Il valore predefinito per la strategia bilanciata è`largestPopulation`.
## Dai priorità ai ticket di riempimento
Se il tuo gioco implementa il backfill automatico o il riempimento manuale, puoi personalizzare il modo in cui FlexMatch elabora i ticket di matchmaking in base al tipo di richiesta. Il tipo di richiesta può essere una nuova richiesta di match o di backfill. Per impostazione predefinita, FlexMatch tratta entrambi i tipi di richieste allo stesso modo.
La prioritizzazione di Backfill influisce sul modo in cui vengono FlexMatch gestiti i ticket dopo averli raggruppati. La prioritizzazione dei backfill richiede set di regole per utilizzare la strategia di ricerca esaustiva.
FlexMatchnon abbina più ticket di backfill insieme.
Per modificare la priorità per i ticket di riempimento, imposta la proprietà. `backfillPriority`
+ **Abbina prima i biglietti di backfill.** Questa opzione cerca di abbinare i ticket di riserva prima di creare nuove partite. Ciò significa che i giocatori entranti hanno maggiori possibilità di partecipare a una partita esistente.
È preferibile utilizzarlo se il gioco utilizza il backfill automatico. Il riempimento automatico viene spesso utilizzato nei giochi con sessioni di gioco brevi e tempi di risposta elevati. Il backfill automatico aiuta questi giochi a creare un numero minimo di partite possibili e a farle iniziare mentre FlexMatch cercano altri giocatori per riempire gli slot aperti.
Imposta `backfillPriority` su `high`.
```
"algorithm": {
"backfillPriority": "high",
"strategy": "exhaustiveSearch"
},
```
+ **I biglietti Match Backfill durano.** Questa opzione ignora i ticket di backfill finché non valuta tutti gli altri ticket. Ciò significa che FlexMatch inserisce i giocatori entranti nelle partite esistenti quando non riesce ad abbinarli a nuove partite.
Questa opzione è utile quando desideri utilizzare il backfill come ultima possibilità per coinvolgere i giocatori in una partita, ad esempio quando non ci sono abbastanza giocatori per formare una nuova partita.
Imposta `backfillPriority` su `low`.
```
"algorithm": {
"backfillPriority": "low",
"strategy": "exhaustiveSearch"
},
```
## Preferisci i biglietti più vecchi con le espansioni
Le regole di espansione allentano i criteri di abbinamento quando le partite sono difficili da completare. Amazon GameLift Serversapplica le regole di espansione quando i biglietti di una partita parzialmente completata raggiungono una certa età. I timestamp di creazione dei ticket determinano quando Amazon GameLift Servers applicare le regole; per impostazione predefinita, FlexMatch tiene traccia del timestamp del ticket abbinato più di recente.
Per modificare quando vengono FlexMatch applicate le regole di espansione, impostate la proprietà come segue: `expansionAgeSelection`
+ **Espandi in base ai biglietti più recenti.** Questa opzione applica le regole di espansione in base al ticket più recente aggiunto alla potenziale partita. Ogni volta che viene FlexMatch abbinato un nuovo ticket, l'orologio viene azzerato. Con questa opzione, le corrispondenze risultanti tendono ad essere di qualità superiore, ma richiedono più tempo per essere abbinate; le richieste di abbinamento potrebbero scadere prima di essere completate se impiegano troppo tempo a corrispondere. Impostato `expansionAgeSelection` su`newest`. `newest`è l'impostazione predefinita.
+ **Espandi in base ai ticket più vecchi.** Questa opzione applica regole di espansione basate sul ticket più vecchio della potenziale partita. Con questa opzione, FlexMatch applica le espansioni più velocemente, il che migliora i tempi di attesa per i primi giocatori abbinati, ma riduce la qualità della partita per tutti i giocatori. Imposta `expansionAgeSelection` su `oldest`.
```
"algorithm": {
"expansionAgeSelection": "oldest",
"strategy": "exhaustiveSearch"
},
```
# Dichiara gli attributi del giocatore
In questa sezione, elenca gli attributi dei singoli giocatori da includere nelle richieste di matchmaking. Esistono due motivi per cui potresti dichiarare gli attributi dei giocatori in un set di regole:
+ Quando il set di regole contiene regole che si basano sugli attributi del giocatore.
+ Quando vuoi passare un attributo del giocatore alla sessione di gioco tramite la richiesta della partita. Ad esempio, potresti voler passare le scelte dei personaggi dei giocatori alla sessione di gioco prima che ogni giocatore si connetta.
Nella dichiarazione di un attributo di un giocatore, includere le informazioni riportate di seguito:
+ *name* (obbligatorio): questo valore deve essere univoco per il set di regole.
+ *type* (obbligatorio) — Il tipo di dati del valore dell'attributo. I tipi di dati validi sono numero, stringa, elenco di stringhe o mappa di stringhe.
+ *default* (opzionale): immetti un valore predefinito da utilizzare se una richiesta di matchmaking non fornisce un valore di attributo. Se non viene dichiarato alcun valore predefinito e una richiesta non include un valore, non FlexMatch può soddisfare la richiesta.
# Definisci le squadre di gioco
Descrivi la struttura e le dimensioni dei team per un abbinamento. Ogni abbinamento deve avere almeno un team e puoi definire tutti i team che desideri. I tuoi team possono avere lo stesso numero di giocatori o essere asimmetrici. Ad esempio, potresti definire un team di mostri con un giocatore singolo e un team di cacciatori con 10 giocatori.
FlexMatch elabora le richieste di abbinamento come abbinamento piccolo o grande, in base a come il set di regole definisce le dimensioni del team. Le partite potenziali con un massimo di 40 giocatori sono partite piccole, le partite con più di 40 giocatori sono partite grandi. Per determinare la dimensione dell'abbinamento potenziale di un set di regole, aggiungi le impostazioni *maxPlayer* per tutti i team definiti nel set di regole.
+ *nome* (obbligatorio): assegna a ogni squadra un nome univoco. Utilizzi questo nome nelle regole, nelle espansioni e nei FlexMatch riferimenti per i dati di matchmaking in una sessione di gioco.
+ *MaxPlayers* (obbligatorio): specifica il numero massimo di giocatori da assegnare alla squadra.
+ *MinPlayers* (obbligatorio): specifica il numero minimo di giocatori da assegnare alla squadra.
+ *quantità* (opzionale): specifica il numero di squadre da formare con questa definizione. Quando FlexMatch crea una partita, assegna a queste squadre il nome fornito con un numero aggiunto. Ad esempio `Red-Team1``Red-Team2`, e`Red-Team3`.
FlexMatchtenta di riempire le squadre fino al numero massimo di giocatori, ma crea squadre con meno giocatori. Se vuoi che tutti i team dell'abbinamento abbiano le stesse dimensioni, puoi creare una regola apposita. Vedi l'[FlexMatchesempi di set di regole](match-examples.md)argomento per un esempio di `EqualTeamSizes` regola.
# Stabilisci le regole per l'abbinamento dei giocatori
Crea una serie di regole che valutino l'accettazione dei giocatori in una partita. Le regole possono stabilire i requisiti che si applicano a singoli giocatori, team o un intero abbinamento. Quando Amazon GameLift Servers elabora una richiesta di abbinamento, inizia con il giocatore meno recente nel pool di giocatori disponibili e crea un abbinamento per quel giocatore. Per informazioni dettagliate sulla creazione di FlexMatch regole, consulta[FlexMatchtipi di regole](match-rules-reference-ruletype.md).
+ *name* (obbligatorio): un nome significativo che identifica in modo univoco la regola all'interno di un set di regole. I nomi delle regole sono anche presenti nei log di eventi e parametri in grado di monitorare le attività correlate a questa regola.
+ *descrizione* (opzionale) — Utilizzate questo elemento per allegare una descrizione testuale in formato libero.
+ *type* (obbligatorio) — L'elemento type identifica l'operazione da utilizzare durante l'elaborazione della regola. Ogni tipo di regola richiede un set di proprietà aggiuntive. Consulta l'elenco delle proprietà e dei tipi di regole validi disponibile in [FlexMatch linguaggio delle regole](match-rules-reference.md).
+ Proprietà del tipo di regola (potrebbe essere obbligatoria): a seconda del tipo di regola definita, potrebbe essere necessario impostare determinate proprietà della regola. Ulteriori informazioni sulle proprietà e su come utilizzare il linguaggio di espressione delle proprietà FlexMatch sono disponibili in [FlexMatch linguaggio delle regole](match-rules-reference.md).
# Consenti ai requisiti di attenuarsi nel tempo
Le espansioni ti consentono di allentare i criteri delle regole nel tempo quando non FlexMatch riesci a trovare una corrispondenza. Questa funzionalità FlexMatch assicura che il miglior risultato sia disponibile quando non riesce a creare un abbinamento perfetto. Allentando le regole con un'espansione, si amplia gradualmente il numero di giocatori che rappresentano una partita accettabile.
Le espansioni iniziano quando l'età del biglietto più recente nella partita incompleta corrisponde al tempo di attesa per l'espansione. Quando si FlexMatch aggiunge un nuovo ticket alla partita, l'orologio del tempo di attesa per l'espansione potrebbe essere azzerato. Puoi personalizzare l'inizio delle espansioni nella `algorithm` sezione del set di regole.
Ecco un esempio di espansione che aumenta gradualmente il livello minimo di abilità richiesto per la partita. Il set di regole utilizza una regola sulla distanza, denominata in *SkillDelta*modo da richiedere che tutti i giocatori di una partita si trovino a meno di 5 livelli di abilità l'uno dall'altro. Se non vengono create nuove partite per quindici secondi, questa espansione rileva una differenza di livello di abilità di 10, quindi dieci secondi dopo una differenza di 20.
```
"expansions": [{
"target": "rules[SkillDelta].maxDistance",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 25,
"value": 20
}]
}]
```
Con i matchmaker che hanno abilitato il riempimento automatico, non limitarti troppo rapidamente ai requisiti di conteggio dei giocatori. Sono necessari alcuni secondi per l'avvio della nuova sessione di gioco e l'avvio del backfill. Un approccio migliore consiste nell'avviare l'espansione dopo che il riempimento automatico tende a entrare in gioco nei giochi. I tempi di espansione variano a seconda della composizione della squadra, quindi fai dei test per trovare la strategia di espansione migliore per il tuo gioco.
# Progetta un set di regole per FlexMatch partite di grandi dimensioni
Se il tuo set di regole crea partite che ammettono da 41 a 200 giocatori, devi apportare alcune modifiche alla configurazione del set di regole. Queste modifiche ottimizzano l'algoritmo delle partite in modo che possa creare partite di grandi dimensioni e allo stesso tempo ridurre i tempi di attesa dei giocatori. Di conseguenza, set di regole per partite di grandi dimensioni sostituiscono le lunghe regole personalizzate con soluzioni standard ottimizzate per le priorità di matchmaking comuni.
Ecco come determinare se è necessario ottimizzare il set di regole per partite di grandi dimensioni:
1. Per ogni squadra definita nel tuo set di regole, ottieni il valore di *MaxPlayer*,
1. Somma tutti i valori di *MaxPlayer*. Se il totale supera i 40, hai un ampio set di regole per le partite.
Per ottimizzare il set di regole per partite di grandi dimensioni, apporta le modifiche descritte di seguito. Vedi lo schema per un set di regole per partite di grandi dimensioni [Schema del set di regole per partite di grandi dimensioni](match-ruleset-schema-large.md) ed esempi di set di regole in[Esempio: crea una partita di grandi dimensioni](match-examples-7.md).
# Personalizza l'algoritmo di corrispondenza per corrispondenze di grandi dimensioni
Aggiungi un componente dell'algoritmo al set di regole, se non ne esiste già uno. Imposta le seguenti proprietà.
+ `strategy`(obbligatorio) — Imposta la `strategy` proprietà su «bilanciata». Questa impostazione consente di FlexMatch eseguire ulteriori controlli post-partita per trovare l'equilibrio ottimale della squadra in base a un attributo del giocatore specificato, definito nella `balancedAttribute` proprietà. La strategia bilanciata sostituisce la necessità di regole personalizzate per creare squadre equamente abbinate.
+ `balancedAttribute`(obbligatorio): identifica un attributo del giocatore da utilizzare per bilanciare le squadre in una partita. Questo attributo deve avere un tipo di dati numerico (doppio o intero). Ad esempio, se scegli di bilanciare le abilità dei giocatori, FlexMatch prova ad assegnare i giocatori in modo che tutte le squadre abbiano livelli di abilità aggregati il più possibile uguali. L'attributo di bilanciamento deve essere dichiarato negli attributi del giocatore del set di regole.
+ `batchingPreference`(opzionale): scegli quanta enfasi vuoi dare alla creazione di partite con la latenza più bassa possibile per i tuoi giocatori. Questa impostazione influisce sul modo in cui i biglietti delle partite vengono ordinati prima di creare le partite. Le opzioni includono:
+ Popolazione più numerosa. FlexMatchconsente le partite utilizzando tutti i ticket del pool che hanno valori di latenza accettabili in almeno una località in comune. Di conseguenza, il potenziale pool di ticket tende ad essere ampio, il che rende più facile riempire le partite più rapidamente. I giocatori potrebbero essere inseriti in partite con una latenza accettabile, ma non sempre ottimale. Se la `batchingPreference` proprietà non è impostata, questo è il comportamento predefinito quando `strategy` è impostata su «bilanciato».
+ Posizione più veloce. FlexMatchpreordina tutti i ticket del pool in base a dove riportano i valori di latenza più bassi. Di conseguenza, le partite tendono a essere organizzate con giocatori che segnalano una bassa latenza nelle stesse località. Allo stesso tempo, il potenziale pool di biglietti per ogni partita è inferiore, il che può aumentare il tempo necessario per riempire una partita. Inoltre, poiché viene data maggiore priorità alla latenza, i giocatori nelle partite possono variare maggiormente per quanto riguarda l'attributo di bilanciamento.
L'esempio seguente configura l'algoritmo della partita in modo che si comporti come segue: (1) Preordina il pool di ticket per raggruppare i ticket in base alla località in cui hanno valori di latenza accettabili; (2) Forma lotti di ticket ordinati per l'abbinamento; (3) Crea partite con biglietti in batch e bilancia le squadre per uniformare l'abilità media del giocatore.
```
"algorithm": {
"strategy": "balanced",
"balancedAttribute": "player_skill",
"batchingPreference": "largestPopulation"
},
```
# Dichiara gli attributi del giocatore
Assicurati di dichiarare l'attributo player utilizzato come attributo di bilanciamento nell'algoritmo del set di regole. Questo attributo deve essere incluso per ogni giocatore in una richiesta di matchmaking. Puoi fornire un valore predefinito per l'attributo player, ma il bilanciamento degli attributi funziona meglio quando vengono forniti valori specifici per il giocatore.
# Definisci le squadre
Il processo di definizione delle dimensioni e della struttura del team è lo stesso degli abbinamenti piccoli, ma il modo in cui FlexMatch completa i team è diverso. Ciò influisce sul modo in cui è probabile che le partite siano riempite solo parzialmente. In risposta, potresti voler modificare le dimensioni minime della tua squadra.
FlexMatch utilizza le seguenti regole quando si assegna un giocatore a un team. In primo luogo: cerca i team che non hanno ancora raggiunto il loro requisito minimo di giocatori. In secondo luogo: di quei team, individua quello con il maggior numero di slot aperti.
Per gli abbinamenti che definiscono più team di uguali dimensioni, i giocatori vengono aggiunti in sequenza a ciascun team fino al completamento. Di conseguenza, le squadre in una partita hanno sempre un numero di giocatori quasi uguale, anche quando la partita non è completa. Non è attualmente possibile forzare team di uguali dimensioni in abbinamenti grandi. Per gli abbinamenti con team di dimensioni asimmetriche, il processo è un po' più complesso. In questo scenario, i giocatori vengono inizialmente assegnati alle squadre più grandi con il maggior numero di slot disponibili. Man mano che il numero di slot aperti diventa più equamente distribuito tra tutte le squadre, i giocatori vengono inseriti nelle squadre più piccole.
Ad esempio, supponiamo che tu abbia un set di regole con tre squadre. Le squadre rosse e blu sono entrambe impostate su `maxPlayers` =10, `minPlayers` =5. La squadra verde è impostata su `maxPlayers` =3, =2. `minPlayers` Ecco la sequenza di riempimento:
1. Nessuna squadra è arrivata`minPlayers`. I team rosso e blu hanno 10 slot aperti, mentre il verde ne ha 3. I primi 10 giocatori vengono assegnati (5 ciascuno) ai team rosso e blu. Entrambe le squadre sono ora arrivate`minPlayers`.
1. La squadra verde non è ancora arrivata`minPlayers`. I successivi 2 giocatori vengono assegnati al team verde. La squadra dei Verdi è ora arrivata`minPlayers`.
1. Con tutte le squadre presenti`minPlayers`, ora vengono assegnati giocatori aggiuntivi in base al numero di slot disponibili. Le squadre rosse e blu hanno ciascuna 5 slot aperte, mentre la squadra verde ne ha 1. I successivi 8 giocatori vengono assegnati (4 ciascuno) alle squadre rosse e blu. Tutte le squadre ora hanno 1 posto libero.
1. I restanti 3 posti per giocatori vengono assegnati (1 ciascuno) alle squadre senza un ordine particolare.
# Stabilisci delle regole per partite di grandi dimensioni
Il matchmaking per partite di grandi dimensioni si basa principalmente sulla strategia di bilanciamento e sulle ottimizzazioni del batch di latenza. La maggior parte delle regole personalizzate non sono disponibili. Tuttavia, puoi incorporare i seguenti tipi di regole:
+ Regola che stabilisce un limite rigido alla latenza dei giocatori. Usa il tipo di `latency` regola con la proprietà`maxLatency`. Vedi [Latency rule (Regola di latenza)](match-rules-reference-ruletype.md#match-rules-reference-ruletype-latency) riferimento. Ecco un esempio che imposta la latenza giocatore massima su 200 millisecondi:
```
"rules": [{
"name": "player-latency",
"type": "latency",
"maxLatency": 200
}],
```
+ Regola per raggruppare i giocatori in base alla vicinanza in uno specifico attributo del giocatore. Questo è diverso dalla definizione di un attributo di bilanciamento come parte dell'algoritmo per partite di grandi dimensioni, che si concentra sulla creazione di squadre con partite uguali. Questa regola raggruppa i ticket di matchmaking in base alla somiglianza dei valori degli attributi specificati, come l'abilità principiante o esperto, il che tende a far sì che i giocatori delle partite siano strettamente allineati sull'attributo specificato. Usa il tipo di `batchDistance` regola, identifica un attributo basato su numeri e specifica l'intervallo più ampio da consentire. Vedi riferimento. [Regola della distanza in batch](match-rules-reference-ruletype.md#match-rules-reference-ruletype-batchdistance) Ecco un esempio che richiede che i giocatori di una partita si trovino all'interno di un livello di abilità l'uno dall'altro:
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# Allenta i requisiti delle partite di grandi dimensioni
Come per gli abbinamenti piccoli, puoi utilizzare le espansioni per rendere più flessibili i requisiti degli abbinamenti nel tempo, quando non è possibile effettuare abbinamenti validi. Nelle partite di grandi dimensioni, hai la possibilità di allentare le regole di latenza o il numero di giocatori di squadra.
Se usi il backfill automatico per i grandi abbinamenti, evita di rendere più flessibile il numero di giocatori del team troppo rapidamente. FlexMatch inizia a generare richieste di backfill solo dopo l'avvio di una sessione di gioco, il che potrebbe non verificarsi per diversi secondi dopo la creazione di un abbinamento. Durante tale periodo, FlexMatch può creare più nuove sessioni di gioco parzialmente completate, specialmente quando le regole del numero dei giocatori vengono abbassate. Di conseguenza, ti ritrovi con più sessioni di gioco di quelle che ti servono e i giocatori si diffondono troppo raramente. Si consiglia di concedere al primo passaggio dell'espansione del numero dei giocatori un tempo di attesa più lungo, abbastanza lungo da consentire l'avvio della sessione di gioco. Dal momento che le richieste di backfill hanno la priorità più alta con gli abbinamenti grandi, i giocatori in arrivo verranno inseriti nei giochi esistenti prima di iniziare un nuovo gioco. Potrebbe essere necessario effettuare delle prove per trovare il tempo di attesa ideale per il tuo gioco.
Ecco un esempio che riduce gradualmente il numero dei giocatori del team giallo, con un tempo di attesa iniziale più lungo. Tieni presente che i tempi di attesa nelle espansioni del set di regole sono assoluti, non composti. Quindi la prima espansione avviene a cinque secondi e la seconda espansione avviene cinque secondi dopo, a dieci secondi.
```
"expansions": [{
"target": "teams[Yellow].minPlayers",
"steps": [{
"waitTimeSeconds": 5,
"value": 8
}, {
"waitTimeSeconds": 10,
"value": 5
}]
}]
```
# Tutorial: Crea un set di regole di matchmaking
Prima di creare un set di regole di matchmaking per il tuo Amazon GameLift Servers FlexMatch matchmaker, ti consigliamo di controllare la sintassi del set di [regole](match-rules-reference.md). Dopo aver creato un set di regole utilizzando la Amazon GameLift Servers console o il AWS Command Line Interface (AWS CLI), non puoi cambiarlo.
Tieni presente che esiste una [quota di servizio](https://console.aws.amazon.com/servicequotas/home/services/gamelift/quotas/) per il numero massimo di set di regole che puoi avere in una AWS regione, quindi è una buona idea eliminare i set di regole non utilizzati.
**Topics**
------
#### [ Console ]
**Crea un set di regole**
1. Apri la console Amazon GameLift Servers all'indirizzo [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/).
1. Passa alla AWS regione in cui desideri creare il set di regole. Definisci i set di regole nella stessa regione della configurazione di matchmaking che li utilizza.
1. Nel riquadro di navigazione, scegli **FlexMatch**, Set di **regole di matchmaking**.
1. Nella pagina **Set di regole di matchmaking, scegli Crea set** **di regole**.
1. Nella pagina **Crea set di regole di matchmaking**, procedi come segue:
1. In **Impostazioni del set di regole**, in **Nome**, inserisci un nome descrittivo univoco che puoi utilizzare per identificarlo in un elenco o nelle tabelle degli eventi e delle metriche.
1. Per **Set di regole**, inserisci il set di regole in JSON. Per informazioni sulla progettazione di un set di regole, consulta[Progetta un set di FlexMatch regole](match-design-ruleset.md). È inoltre possibile utilizzare uno dei set di regole di esempio di[FlexMatchesempi di set di regole](match-examples.md).
1. Scegli **Convalida** per verificare che la sintassi del set di regole sia corretta. Non puoi modificare i set di regole dopo averli creati, quindi è una buona idea convalidarli prima.
1. (Facoltativo) In **Tag**, aggiungi tag per aiutarti a gestire e monitorare AWS le tue risorse.
1. Scegli **Create** (Crea). Se la creazione ha esito positivo, puoi utilizzare la regola impostata con un matchmaker.
------
#### [ AWS CLI ]
**Crea un set di regole**
Aprire una finestra della riga di comando e utilizzare il comando [create-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-rule-set.html).
Questo comando di esempio crea un semplice set di regole di matchmaking che configura una singola squadra. Assicurati di creare il set di regole nella stessa AWS regione delle configurazioni di matchmaking che lo utilizzano.
```
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 la richiesta di creazione ha esito positivo, Amazon GameLift Servers restituisce un [MatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html)oggetto che include le impostazioni specificate. Un matchmaker può ora utilizzare il nuovo set di regole.
------
------
#### [ Console ]
**Eliminazione di un set di regole**
1. Apri la console Amazon GameLift Servers all'indirizzo [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/).
1. Passa alla regione in cui hai creato il set di regole.
1. Nel riquadro di navigazione, scegli **FlexMatch**, **Set di regole di matchmaking**.
1. **Nella pagina **Set di regole di matchmaking**, seleziona il set di regole che desideri eliminare, quindi scegli Elimina.**
1. Nella finestra di dialogo **Elimina set di regole**, scegli **Elimina** per confermare l'eliminazione.
**Nota**
Se una configurazione di matchmaking utilizza il set di regole, Amazon GameLift Servers visualizza un messaggio di errore (**Impossibile eliminare il set di regole**). In tal caso, modifica la configurazione del matchmaking per utilizzare un set di regole diverso, quindi riprova. Per scoprire quali configurazioni di matchmaking utilizzano un set di regole, scegli il nome di un set di regole per visualizzarne la pagina dei dettagli.
------
#### [ AWS CLI ]
**Eliminare un set di regole**
Apri una finestra della riga di comando e usa il comando [delete-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-matchmaking-rule-set.html)per eliminare un set di regole di matchmaking.
Se una configurazione di matchmaking utilizza il set di regole, Amazon GameLift Servers restituisce un messaggio di errore. In tal caso, modifica la configurazione del matchmaking per utilizzare un set di regole diverso, quindi riprova. Per ottenere un elenco delle configurazioni di matchmaking che utilizzano un set di regole, usa il comando [describe-matchmaking-configurations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-matchmaking-configurations.html)e specifica il nome del set di regole.
Questo comando di esempio verifica l'utilizzo del set di regole di matchmaking e quindi elimina il set di regole.
```
aws gamelift describe-matchmaking-rule-sets \
--rule-set-name "SampleRuleSet123" \
--limit 10
aws gamelift delete-matchmaking-rule-set \
--name "SampleRuleSet123"
```
------
# FlexMatchesempi di set di regole
I set di regole FlexMatch possono coprire un'ampia gamma di scenari di abbinamento. I seguenti esempi sono conformi alla struttura di configurazione e al linguaggio di espressione delle proprietà di FlexMatch. Copiare questi set di regole interamente o scegliere i componenti in base alle esigenze.
Per ulteriori informazioni sull'uso di regole e set di regole FlexMatch, consulta i seguenti argomenti:
**Nota**
Durante la valutazione di un ticket di abbinamento che include più giocatori, tutti i giocatori nella richiesta devono soddisfare i requisiti di corrispondenza.
**Topics**
+ [Esempio: crea due squadre con giocatori uguali](match-examples-1.md)
+ [Esempio: crea squadre irregolari (Hunters vs Monster)](match-examples-2.md)
+ [Esempio: imposta i requisiti a livello di team e i limiti di latenza](match-examples-3.md)
+ [Esempio: utilizza l'ordinamento esplicito per trovare le migliori corrispondenze](match-examples-4.md)
+ [Esempio: trova le intersezioni tra gli attributi di più giocatori](match-examples-5.md)
+ [Esempio: confronta gli attributi di tutti i giocatori](match-examples-6.md)
+ [Esempio: crea una partita di grandi dimensioni](match-examples-7.md)
+ [Esempio: crea una grande partita a più squadre](match-examples-8.md)
+ [Esempio: crea una partita di grandi dimensioni con giocatori con caratteristiche simili](match-examples-9.md)
+ [Esempio: usa una regola composta per creare una partita con giocatori con attributi simili o selezioni simili](match-examples-10.md)
+ [Esempio: crea una regola che utilizza la lista dei blocchi di un giocatore](match-examples-11.md)
# Esempio: crea due squadre con giocatori uguali
Questo esempio illustra come impostare due squadre ugualmente abbinate di giocatori con le seguenti istruzioni.
+ Creare due squadre di giocatori.
+ Includere da quattro a otto giocatori in ciascuna squadra.
+ Le squadre finali devono avere lo stesso numero di giocatori.
+ Includere il livello di competenza dei giocatori (se non viene fornito, l'impostazione predefinita è su 10).
+ Scegliere i giocatori se il loro livello di competenza è analogo ad altri giocatori. Verificare che entrambe le squadre dispongano di una competenza media dei giocatori entro i 10 punti.
+ Se la corrispondenza non viene completata in modo rapido, rendere più flessibili i requisiti in termini di competenze dei giocatori per completare una corrispondenza in tempi ragionevoli.
+ Dopo 5 secondi, espandere la ricerca per accettare le squadre con competenze medie dei giocatori entro i 50 punti.
+ Dopo 15 secondi, espandere la ricerca per accettare le squadre con competenze medie dei giocatori entro i 100 punti.
Note sull'utilizzo di questo set di regole:
+ Questo esempio consente alle squadre di avere qualsiasi dimensione compresa tra quattro e otto giocatori (anche se devono avere le stesse dimensioni). Per le squadre con un'ampia gamma di dimensioni valide, il matchmaker tenta tutte le soluzioni possibili per abbinare il numero massimo di giocatori consentiti.
+ La regola `FairTeamSkill` garantisce che le squadre vengano abbinate in modo uniforme in base alle competenze dei giocatori. Per valutare questa regola per ogni nuovo potenziale giocatore, FlexMatch aggiunge provvisoriamente il giocatore a una squadra e calcola le medie. Se la regola ha esito negativo, il giocatore potenziale non viene aggiunto alla corrispondenza.
+ Poiché entrambi i team hanno strutture identiche, è possibile scegliere di creare una sola definizione di team e impostare la quantità dei team su "2". In questo scenario, se hai denominato il team "aliens", ai team verranno assegnati i nomi "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
}]
}]
}
```
# Esempio: crea squadre irregolari (Hunters vs Monster)
Questo esempio descrive una modalità di gioco in cui un gruppo di giocatori caccia un singolo mostro. Le persone scelgono il ruolo di cacciatore o di mostro. I cacciatori specificano il livello minimo di competenza per il mostro che desiderano affrontare. La dimensione minima della squadra del cacciatore può diventare più flessibile nel corso del tempo per completare la corrispondenza. Questo scenario delinea le seguenti istruzioni:
+ Creazione di una squadra di esattamente cinque cacciatori.
+ Creazione di una squadra di esattamente un mostro.
+ Includere i seguente attributi giocatore:
+ Il livello di competenza di un giocatore (se non viene fornito, l'impostazione predefinita è su 10).
+ Il livello di competenza del mostro preferito del giocatore (se non viene fornito, l'impostazione predefinita è su 10).
+ Se il giocatore vuole essere il mostro (se non viene fornita questa informazione, l'impostazione predefinita è su 0 o falso).
+ Scegliere un giocatore come mostro in base ai seguenti criteri:
+ Il giocatore deve richiedere il ruolo di mostro.
+ Il giocatore deve soddisfare o superare il livello massimo di competenza preferito dai giocatori che sono già parte della squadra di cacciatori.
+ Scegliere i giocatori per la squadra dei cacciatori in base ai seguenti criteri:
+ I giocatori che richiedono il ruolo di mostro non possono partecipare alla squadra dei cacciatori.
+ Se il ruolo di mostro è già stato ricoperto, il giocatore deve cercare un livello di abilità per il mostro inferiore alla capacità del mostro proposto.
+ Se una corrispondenza non viene completata in modo rapido, rendere la dimensione minima della squadra dei cacciatori più flessibile come segue:
+ Dopo 30 secondi, consentire al gioco di iniziare con solo quattro giocatori nella squadra cacciatori.
+ Dopo 60 secondi, consentire al gioco di iniziare con solo tre giocatori nella squadra cacciatori.
Note sull'utilizzo di questo set di regole:
+ Utilizzando due squadre separate per cacciatori e mostro, è possibile valutare l'iscrizione in base a diversi set di criteri.
```
{
"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
}]
}]
}
```
# Esempio: imposta i requisiti a livello di team e i limiti di latenza
Questo esempio illustra come impostare team di giocatori e applicare un set di regole a ciascun team anziché a ciascun singolo giocatore. Utilizza una singola definizione per creare tre team ugualmente abbinati. Inoltre, stabilisce una latenza massima per tutti i giocatori. I massimi della latenza possono diventare più flessibili nel corso del tempo per completare la corrispondenza. Questo esempio riporta le seguenti istruzioni:
+ Creare tre squadre di giocatori.
+ Includere da tre a cinque giocatori in ciascuna squadra.
+ le squadre finali devono contenere lo stesso o quasi lo stesso numero di giocatori (all'interno di una stessa squadra).
+ Includere i seguente attributi giocatore:
+ Il livello di competenza di un giocatore (se non viene fornito, l'impostazione predefinita è su 10).
+ Il ruolo del carattere del giocatore (se non viene fornito, l'impostazione predefinita è su "peasant").
+ Scegliere i giocatori se il loro livello di competenza è analogo ad altri giocatori presenti nella corrispondenza.
+ Verificare che ogni squadra disponga di una competenza media dei giocatori entro i 10 punti.
+ Limitare le squadre al seguente numero di caratteri "medic":
+ Una corrispondenza intera può avere al massimo cinque medic.
+ Vengono abbinati solo i giocatori che segnalano una latenza massima di 50 millisecondi.
+ Se una corrispondenza non viene completata in modo rapido, rendere il requisito relativo alla latenza dei giocatori più flessibile come segue:
+ Dopo 10 secondi, consentire valori per la latenza giocatori fino a 100 ms.
+ Dopo 20 secondi, consentire valori per la latenza giocatori fino a 150 ms.
Note sull'utilizzo di questo set di regole:
+ Il set di regole garantisce che le squadre vengano abbinate in modo uniforme in base alle competenze dei giocatori. Per valutare la regola `FairTeamSkill`, FlexMatch aggiunge provvisoriamente il potenziale giocatore a un team e calcola l'abilità media dei giocatori nel team. Quindi la confronta con l'abilità media dei giocatori in entrambi i team. Se la regola ha esito negativo, il giocatore potenziale non viene aggiunto alla corrispondenza.
+ La squadra e i requisiti in termini di livello di corrispondenza (numero totale di medic) vengono archiviati attraverso una regola di raccolta. Questo tipo di regola richiede un elenco di attributi di caratteri per tutti i giocatori e controlli rispetto ai conteggi massimi. Utilizzare `flatten` per creare un elenco di tutti i giocatori in tutte le squadre.
+ Durante la valutazione in base alla latenza, annotare quanto segue:
+ I dati di latenza vengono forniti nella richiesta di abbinamento come parte dell'oggetto Player. Non è un attributo del giocatore, perciò non deve essere elencato come uno. Per ottenere misurazioni accurate della latenza, utilizzate i Amazon GameLift Servers beacon ping UDP. Questi endpoint consentono di misurare l'effettiva latenza della rete UDP tra i dispositivi dei giocatori e ciascuna delle potenziali sedi di hosting, con conseguenti decisioni di posizionamento più accurate rispetto all'utilizzo dei ping ICMP. [Per ulteriori informazioni sull'utilizzo dei beacon ping UDP per misurare la latenza, consulta i beacon ping UDP.](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)
+ Il matchmaker valuta la latenza per regione. Qualsiasi regione con una latenza più elevata rispetto al massimo viene ignorata. Per essere accettato per una corrispondenza, un giocatore deve avere almeno una regione con una latenza inferiore al massimo.
+ Se una richiesta di abbinamento omette i dati di latenza di uno o più giocatori, la richiesta viene respinta per tutte le corrispondenze.
```
{
"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
}]
}]
}
```
# Esempio: utilizza l'ordinamento esplicito per trovare le migliori corrispondenze
Questo esempio imposta una corrispondenza semplice con due squadre di tre giocatori. Illustra come utilizzare regole di ordinamento esplicite per trovare le migliori corrispondenze possibili, il più rapidamente possibile. Queste regole ordinano tutti i ticket di matchmaking attivi per creare le migliori partite in base a determinati requisiti chiave. Questo esempio è implementato con le seguenti istruzioni:
+ Creare due squadre di giocatori.
+ Includere esattamente tre giocatori in ciascuna squadra.
+ Includere i seguente attributi giocatore:
+ Livello di esperienza (se non fornito, il livello predefinito è impostato su 50).
+ Modalità di gioco preferite (possono essere presenti più valori) (se non forniti, l'impostazione predefinita è su "coop" e "deathmatch").
+ Le mappe di gioco preferite, incluso il nome della mappa e il peso delle preferenze (se non specificato, l'impostazione predefinita è su `"defaultMap"` con un peso di 100).
+ Configurare l'ordinamento preventivo:
+ Ordinare i giocatori in base alle loro preferenze per la stessa mappa di gioco del giocatore ancoraggio. I giocatori possono avere più mappe di gioco preferite, perciò questo esempio utilizza un valore preferenza.
+ Ordinare giocatori in base a quanto il loro livello di esperienza corrisponda al giocatore di ancoraggio. Con questo ordinamento, tutti i giocatori in tutte le squadre avranno livelli di esperienza più vicini possibile.
+ Tutti i giocatori in tutte le squadre devono aver selezionato almeno una modalità di gioco in comune.
+ Tutti i giocatori in tutte le squadre devono aver selezionato almeno una mappa di gioco in comune.
Note sull'utilizzo di questo set di regole:
+ L'ordinamento della mappa di gioco usa un ordinamento assoluto che confronta il valore dell'attributo mapPreference. Poiché è il primo nel set di regole, questo ordinamento viene eseguito per primo.
+ L'esperienza utilizza un ordinamento a distanza per confrontare il livello di abilità di un potenziale giocatore con l'abilità del giocatore di ancoraggio.
+ Gli ordinamenti vengono eseguiti nell'ordine in cui sono elencati in un set di regole. In questo scenario, i giocatori sono ordinati in base alle preferenze della mappa di gioco, quindi in base al livello di esperienza.
```
{
"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
}]
}
```
# Esempio: trova le intersezioni tra gli attributi di più giocatori
Questo esempio illustra come utilizzare una regola di raccolta per trovare intersezioni in due o più attributi giocatore. Quando si utilizzano le raccolte, è possibile utilizzare l'operazione `intersection` per un singolo attributo e l'operazione `reference_intersection_count` per più attributi.
Per illustrare questo approccio, questo esempio valuta i giocatori in una corrispondenza in base alle loro preferenze di caratteri. Il gioco di esempio è uno stile "free-for-all" in cui tutti i giocatori di una partita sono avversari. A ogni giocatore viene chiesto di (1) scegliere un carattere per se stessi e (2) scegliere i caratteri contro cui desiderano giocare. Abbiamo bisogno di una regola che garantisca che ogni giocatore in una corrispondenza utilizzi un carattere che sia nell'elenco degli avversari preferiti di tutti gli altri giocatori.
Il set di regole di esempio descrive una corrispondenza con le seguenti caratteristiche:
+ Struttura della squadra: una squadra di cinque giocatori
+ Attributi dei giocatori:
+ *myCharacter*: il carattere scelto dal giocatore.
+ *preferredOpponents*: elenco di caratteri contro cui il giocatore vuole giocare.
+ Regole corrispondenza: una corrispondenza potenziale è accettabile se ogni carattere in uso è nell'elenco di avversari preferiti di ogni giocatore.
Per implementare la regola di corrispondenza, questo esempio utilizza una regola di raccolta con i seguenti valori di proprietà:
+ Operazione: utilizza `reference_intersection_count` l'operazione per valutare come ogni elenco di stringhe nel valore di misurazione si interseca con l'elenco di stringhe nel valore di riferimento.
+ Misurazione: utilizza l'espressione della `flatten` proprietà per creare un elenco di elenchi di stringhe, con ogni elenco di stringhe contenente il valore dell'attributo *myCharacter* di un giocatore.
+ Valore di riferimento: utilizza l'espressione della `set_intersection` proprietà per creare un elenco di stringhe di tutti i valori *degli* attributi PreferredOpponents comuni a tutti i giocatori della partita.
+ Restrizioni: `minCount` è impostato su 1 per garantire che il personaggio scelto da ogni giocatore (un elenco di stringhe nella misurazione) corrisponda ad almeno uno degli avversari preferiti comuni a tutti i giocatori. (una stringa nel valore di riferimento).
+ Espansione: se una partita non viene riempita entro 15 secondi, allenta il requisito minimo di intersezione.
Il flusso di elaborazione per questa regola è il seguente:
1. Un giocatore viene aggiunto alla corrispondenza potenziale. Il valore di riferimento (un elenco di stringhe) è ricalcolato per includere le intersezioni con l'elenco degli avversari preferiti del nuovo giocatore. Il valore di misurazione (un elenco di elenchi di stringhe) viene ricalcolato per aggiungere il carattere scelto dal nuovo giocatore come un nuovo elenco stringa.
1. Amazon GameLift Servers verifica che ogni elenco di stringhe nel valore di misurazione (i caratteri scelti dai giocatori) si intersechi con almeno una stringa nel valore di riferimento (gli avversari preferiti dei giocatori). Poiché in questo esempio ciascun elenco di stringhe nella misurazione contiene un solo valore, l'intersezione può essere 0 o 1.
1. Se qualsiasi elenco di stringhe nella misurazione non si interseca con l'elenco di stringhe del valore di riferimento, la regola ha esito negativo e il nuovo giocatore viene rimosso dalla corrispondenza potenziale.
1. Se una corrispondenza non viene completata entro 15 secondi, annullare il requisito di corrispondenza dell'avversario per completare gli slot giocatore rimanenti nella corrispondenza.
```
{
"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
}]
}]
}
```
# Esempio: confronta gli attributi di tutti i giocatori
Questo esempio illustra come confrontare gli attributi giocatore all'interno di un gruppo di giocatori.
Il set di regole di esempio descrive una corrispondenza con le seguenti caratteristiche:
+ Struttura del team: due team da un giocatore
+ Attributi dei giocatori:
+ *gameMode*: tipo di gioco scelto dal giocatore (se non fornito, l'impostazione predefinita è su "turn-based").
+ *gameMap*: il mondo di gioco scelto dal giocatore (se non fornito, l'impostazione predefinita è su 1).
+ *character*: personaggio scelto dal giocatore (nessun valore predefinito significa che i giocatori devono specificare un personaggio).
+ Regole di corrispondenza: i giocatori abbinati devono soddisfare i seguenti requisiti:
+ I giocatori devono scegliere la stessa modalità di gioco.
+ I giocatori devono scegliere la stessa mappa di gioco.
+ I giocatori devono scegliere caratteri diversi.
Note sull'utilizzo di questo set di regole:
+ Per implementare la regola di corrispondenza, questo esempio utilizza regole di confronto per verificare i valori degli attributi di tutti i giocatori. Per la modalità e la mappa di gioco, la regola verifica che i valori siano gli stessi. Per il carattere, la regola verifica che i valori siano diversi.
+ Questo esempio usa una definizione di giocatore con una proprietà di quantità per creare entrambi i team di giocatori. Ai team sono assegnati i nomi seguenti: "player\$11" e "player\$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])"]
}]
}
```
# Esempio: crea una partita di grandi dimensioni
Questo esempio illustra come impostare un set di regole per gli abbinamenti che possono superare i 40 giocatori. Quando un set di regole descrive i team con un numero di maxPlayer maggiore di 40, viene elaborato come abbinamento grande. Ulteriori informazioni in [Progetta un set di regole per FlexMatch partite di grandi dimensioni](match-design-rulesets-large.md).
Il set di regole di esempio crea un abbinamento utilizzando le seguenti istruzioni:
+ Crea un team con un massimo di 200 giocatori, con un requisito minimo di 175 giocatori.
+ Criteri di bilanciamento: seleziona i giocatori in base al livello di abilità simile. Tutti i giocatori devono segnalare il livello di abilità da abbinare.
+ Preferenza di raggruppamento: raggruppa i giocatori con criteri di bilanciamento simili durante la creazione degli abbinamenti.
+ Regole di latenza: imposta la latenza massima accettabile per il giocatore di 150 millisecondi.
+ Se l'abbinamento non viene completato rapidamente, rendi più flessibili i requisiti per completare un abbinamento in tempi ragionevoli.
+ Dopo 10 secondi, accetta un team con 150 giocatori.
+ Dopo 12 secondi, aumenta il numero massimo di latenza accettabile a 200 millisecondi.
+ Dopo 15 secondi, accetta un team con 100 giocatori.
Note sull'utilizzo di questo set di regole:
+ Poiché l'algoritmo utilizza la preferenza di raggruppamento "popolazione più ampia", i giocatori vengono prima ordinati in base ai criteri di bilanciamento. Di conseguenza, gli abbinamenti tendono ad essere più complete e contengono giocatori che hanno abilità simili. Tutti i giocatori soddisfano i requisiti di latenza accettabili, ma potrebbero non ottenere la migliore latenza possibile per la loro posizione.
+ La strategia dell'algoritmo utilizzata in questo set di regole, "popolazione più ampia", è l'impostazione predefinita. Per utilizzare l'impostazione predefinita, è possibile decidere di omettere l'impostazione.
+ Se hai attivato il backfill degli abbinamenti, non rendere più flessibili i requisiti di numero dei giocatori troppo rapidamente o potresti avere troppe sessioni di gioco parzialmente completate. Ulteriori informazioni in [Allenta i requisiti delle partite di grandi dimensioni](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
}]
}]
}
```
# Esempio: crea una grande partita a più squadre
Questo esempio illustra come impostare un set di regole per gli abbinamenti con più team che possono superare i 40 giocatori. Questo esempio illustra come creare più team identici con una definizione e come vengono completati i team di dimensioni asimmetriche durante la creazione dell'abbinamento.
Il set di regole di esempio crea un abbinamento utilizzando le seguenti istruzioni:
+ Crea dieci team di "cacciatori" identici con un massimo di 15 giocatori e un team di "mostri" con esattamente 5 giocatori.
+ Criteri di bilanciamento: seleziona i giocatori in base al numero di abilità dei mostri. Se i giocatori non segnalano il numero di uccisioni, utilizza un valore predefinito di 5.
+ Preferenza di raggruppamento: raggruppa i giocatori in base alle regioni che segnalano la latenza del giocatore più veloce.
+ Regola di latenza: imposta una latenza massima accettabile per il giocatore di 200 millisecondi.
+ Se l'abbinamento non viene completato rapidamente, rendi più flessibili i requisiti per completare un abbinamento in tempi ragionevoli.
+ Dopo 15 secondi, accetta i team con 10 giocatori.
+ Dopo 20 secondi, accetta i team con 8 giocatori.
Note sull'utilizzo di questo set di regole:
+ Questo set di regole definisce le squadre che possono contenere fino a 155 giocatori, il che la rende una partita di grandi dimensioni. (10 x 15 cacciatori\$15 mostri = 155)
+ Poiché l'algoritmo utilizza la preferenza di raggruppamento "regione più veloce", i giocatori tendono a essere collocati in regioni in cui segnalano una latenza più rapida e non in regioni in cui presentano una latenza elevata (ma accettabile). Allo stesso tempo, è probabile che gli abbinamenti abbiano meno giocatori e che i criteri di bilanciamento (numero di abilità dei mostri) possano variare in modo più ampio.
+ Quando viene definita un'espansione per una definizione per più team (quantità> 1), l'espansione si applica a tutti i team creati con quella definizione. Quindi, rendendo più flessibile l'impostazione minima dei giocatori del team di cacciatori, tutti e dieci i team di cacciatori sono ugualmente interessati.
+ Poiché questo set di regole è ottimizzato per ridurre al minimo la latenza del giocatore, la regola di latenza funge da catch-all per escludere i giocatori che non hanno opzioni di connessione accettabili. Non abbiamo bisogno di rendere più flessibile questo requisito.
+ Ecco come FlexMatch completa gli abbinamenti per questo set di regole prima che eventuali espansioni diventino effettive:
+ Nessun team ha raggiunto il numero di minPlayers ancora. I team di cacciatori dispongono di 15 slot aperti, mentre il team di mostri ha 5 slot aperti.
+ I primi 100 giocatori vengono assegnati (10 ciascuno) ai dieci team di cacciatori.
+ I successivi 22 giocatori vengono assegnati sequenzialmente (2 ciascuno) ai team di cacciatore e al team di mostri.
+ I team di cacciatori hanno raggiunto il numero di minPlayers di 12 giocatori ciascuno. Il team di mostri ha 2 giocatori e non ha raggiunto il numero di minPlayers.
+ I successivi tre giocatori vengono assegnati al team di mostri.
+ Tutti i team hanno raggiunto il numero di minPlayers. I team di cacciatori hanno tre slot aperti. Il team di mostri è pieno.
+ Gli ultimi 30 giocatori vengono assegnati in sequenza ai team di cacciatori, garantendo che tutti i team di cacciatori abbiano quasi le stesse dimensioni (più o meno un giocatore).
+ Se hai attivato il backfill per gli abbinamenti creati con questo set di regole, non rendere più flessibili i requisiti di numero dei giocatori troppo rapidamente o potresti avere troppe sessioni di gioco parzialmente completate. Ulteriori informazioni in [Allenta i requisiti delle partite di grandi dimensioni](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
}]
}]
}
```
# Esempio: crea una partita di grandi dimensioni con giocatori con caratteristiche simili
Questo esempio illustra come impostare un set di regole per le partite con due squadre che utilizzano`batchDistance`. Nell'esempio:
+ La `SimilarLeague` regola assicura che tutti i giocatori di una partita abbiano un `league` limite di 2 rispetto agli altri giocatori.
+ La `SimilarSkill` regola garantisce che tutti i giocatori di una partita abbiano un `skill` limite di 10 punti dagli altri giocatori. Se un giocatore ha aspettato 10 secondi, la distanza viene aumentata a 20. Se un giocatore ha aspettato 20 secondi, la distanza viene aumentata a 40.
+ La `SameMap` regola garantisce che tutti i giocatori di una partita abbiano richiesto la stessa cosa`map`.
+ La `SameMode` regola garantisce che tutti i giocatori di una partita abbiano richiesto la stessa cosa`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
}]
}]
}
```
# Esempio: usa una regola composta per creare una partita con giocatori con attributi simili o selezioni simili
Questo esempio illustra come impostare un set di regole per le partite con due squadre che utilizzano. `compound` Nell'esempio:
+ La `SimilarLeagueDistance` regola assicura che tutti i giocatori di una partita abbiano un `league` limite di 2 rispetto agli altri giocatori.
+ La `SimilarSkillDistance` regola garantisce che tutti i giocatori di una partita abbiano un `skill` limite di 10 punti dagli altri giocatori. Se un giocatore ha aspettato 10 secondi, la distanza viene aumentata a 20. Se un giocatore ha aspettato 20 secondi, la distanza viene aumentata a 40.
+ La `SameMapComparison` regola garantisce che tutti i giocatori di una partita abbiano richiesto la stessa cosa`map`.
+ La `SameModeComparison` regola garantisce che tutti i giocatori di una partita abbiano richiesto la stessa cosa`mode`.
+ La `CompoundRuleMatchmaker` regola garantisce una partita se almeno una delle seguenti condizioni è vera:
+ I giocatori di una partita hanno richiesto la stessa `map` e la stessa cosa`mode`.
+ I giocatori di una partita hanno `league` caratteristiche `skill` e caratteristiche simili.
```
{
"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
}]
}]
}
```
# Esempio: crea una regola che utilizza la lista dei blocchi di un giocatore
Questo esempio illustra un set di regole che consente ai giocatori di evitare di essere abbinati a determinati altri giocatori. I giocatori possono creare una lista di blocco, che il matchmaker valuta durante la selezione dei giocatori per una partita. Per ulteriori informazioni su come aggiungere una lista di blocco o evitare la funzione di elenco, consulta [Games AWS Blog](https://aws.amazon.com/blogs/gametech/category/game-development/amazon-gamelift/).
Questo esempio riporta le seguenti istruzioni:
+ Crea due squadre composte esattamente da cinque giocatori.
+ Inserisci la lista di blocco di un giocatore, che è una lista di giocatori IDs (fino a 100).
+ Confronta tutti i giocatori con la lista di blocco di ogni giocatore e rifiuta una partita proposta se IDs ne trovi uno bloccato.
Note sull'utilizzo di questo set di regole:
+ Quando si valuta un nuovo giocatore da aggiungere a una partita proposta (o per recuperare un posto in una partita esistente), il giocatore potrebbe essere respinto per uno dei seguenti motivi:
+ Se il nuovo giocatore è in una lista di blocco per tutti i giocatori che sono già stati selezionati per la partita.
+ Se alcuni giocatori già selezionati per la partita sono nella lista di blocco del nuovo giocatore.
+ Come mostrato, questo set di regole impedisce di abbinare un giocatore a qualsiasi giocatore nella sua lista di blocco. Puoi modificare questo requisito in una preferenza (chiamata anche lista «da evitare») aggiungendo un'espansione della regola e aumentando il `maxCount` valore.
```
{
"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
}]
}
```