翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# FlexMatch ルールセットの作成
FlexMatch マッチメーカーごとにルールセットが必要です。ルールセットは、マッチングの 2 つの重要な要素として、ゲームのチーム構造とサイズ、および最善のマッチングを実現するためにプレイヤーをグループ化する方法を決定します。
たとえば、ルールセットでは「5 名のプレイヤーで構成されるチームを 2 つ編成し、1 つのチームは防御者、別のチームは攻撃者として両チームのマッチングを作成する」というように定義できます。チームには初心者と経験豊富なプレイヤーが含まれる可能性がありますが、2 つのチームのスキル平均は 10 ポイント以内である必要があります。30 秒後にマッチングが作成されない場合は、スキルの要件を徐々に緩和します。
このセクションのトピックでは、マッチメイキングルールセットを設計、構築する方法について説明します。ルールセットを作成するときは、AWS コンソールまたは Amazon GameLift Servers CLI を使用できます。
**Topics**
+ [FlexMatch ルールセットを設計する](match-design-ruleset.md)
+ [FlexMatch の大規模マッチングルールセットを設計する](match-design-rulesets-large.md)
+ [チュートリアル: マッチメーキングルールセットを作成する](match-create-ruleset.md)
+ [FlexMatch ルールセットの例](match-examples.md)
# FlexMatch ルールセットを設計する
このトピックでは、ルールセットの基本構造と最大 40 人のプレイヤーのマッチに使用するルールセットの構築方法について説明します。マッチメーキングルールセットは、2 つの操作を行います。1 つ目はマッチングのチーム構造とサイズを設計すること、2 つ目は可能な限り最良のマッチを形成するプレイヤーの選択方法をマッチメーカーに伝えることです。
マッチメーキングルールセットは他にもできることが多くあります。例えば、以下のことが可能です:
+ ゲームのマッチメーキングアルゴリズムを最適化します。
+ ゲームプレイの品質を保護するために、最小プレイヤーレイテンシー要件をセットアップします。
+ 時間をかけてチームの要件とマッチルールを徐々に緩和していき、アクティブなプレイヤー全員が希望するマッチを見つけられるようにします。
+ パーティーの集約を使用してグループのマッチメーキングリクエストの処理を定義します。
+ 40 人以上のプレイヤーが集まる大規模なマッチを処理します。大きなマッチの構築に関する詳細については、「[FlexMatch の大規模マッチングルールセットを設計する](match-design-rulesets-large.md)」を参照してください。
マッチメーキングのルールセットを作成する際は、以下のオプションタスクと必須タスクを検討してください。
+ [ルールセットを記述する (必須)](match-rulesets-components-set.md)
+ [マッチアルゴリズムのカスタマイズ](match-rulesets-components-algorithm.md)
+ [プレイヤー属性の宣言](match-rulesets-components-attributes.md)
+ [対戦チームの定義](match-rulesets-components-teams.md)
+ [プレイヤーマッチングのルール設定](match-rulesets-components-rules.md)
+ [時間の経過による要件の許可](match-rulesets-components-expansion.md)
ルールセットは、Amazon GameLift Servers コンソールまたは `[CreateMatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateMatchmakingRuleSet.html)` オペレーションを使用して作成できます。
# ルールセットを記述する (必須)
ルールセットの詳細を指定します。
+ *name* (オプション) – 自分で使用するためのわかりやすいラベル。この値は、Amazon GameLift Servers でルールセットを作成するときに指定するルールセット名とは関連付けられていません。
+ *ruleLanguageVersion* – FlexMatchルールの作成に使用されるプロパティ式言語のバージョン。値は `1.0` にする必要があります。
# マッチアルゴリズムのカスタマイズ
FlexMatch は、ほとんどのゲームに対してデフォルトのアルゴリズムを最適化し、プレイヤーを最小限の待機時間で許容可能なマッチに入れます。ゲームのアルゴリズムをカスタマイズし、マッチメーキングを調整できます。
以下はデフォルトの FlexMatch マッチメーキングアルゴリズムです。
1. FlexMatch は、オープンマッチメーキングチケットとバックフィルチケットはすべてチケットプールに配置します。
1. FlexMatch は、プール内のチケットを 1 つ以上のバッチにランダムにグループ化します。チケットプールが大きくなると、FlexMatch は最適なバッチサイズを維持するために追加のバッチを作成します。
1. FlexMatch は、各バッチ内のチケットを経過時間別にソートします。
1. FlexMatch は、各バッチの最も古いチケットに基づいてマッチを作成します。
対戦アルゴリズムをカスタマイズするには、ルールセットスキーマに `algorithm` コンポーネントを追加します。詳細については、[FlexMatch ルールセットスキーマ](match-ruleset-schema.md) コマンドのリファレンスを参照してください。
次のオプションのカスタマイズは、マッチメーキングプロセスのさまざまな段階に影響します。
+ [事前バッチソートの追加](#match-rulesets-components-algorithm-presort)
+ [batchDistance 属性に基づいてバッチを形成する](https://docs.aws.amazon.com//gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html#match-rules-reference-ruletype-batchdistance)
+ [バックフィルチケットの優先順位付け](#match-rulesets-components-algorithm-backfill)
+ [拡張時に古いチケットを優先](#match-rulesets-components-algorithm-expansion)
## 事前バッチソートの追加
バッチを作成する前にチケットプールをソートします。このタイプのカスタマイズは、大規模なチケットプールを持つゲームで最も効果的です。事前バッチソートは、マッチメーキングプロセスをスピードアップし、定義された特性においてプレイヤーの均一性を高めるのに役立ちます。
バッチ前のソート方法は、アルゴリズムプロパティ`batchingPreference` で定義します。デフォルトの設定は `random` です。
事前バッチソートのカスタマイズには、次のオプションが含まれます。
+ **プレイヤーの属性でソート。**チケットプールを事前ソートするプレイヤー属性のリストを提供します。
プレイヤー属性でソートするには、`batchingPreference` を `sorted` に設定し、`sortByAttributes`でプレイヤー属性のリストを定義します。属性を使用するには、最初にルールセットの `playerAttributes` コンポーネント内で属性を宣言します。
次の例では、FlexMatch はプレイヤーの優先ゲームマップに基づいてチケットプールをソートし、次にプレイヤーのスキル別にソートします。結果のバッチには、同じマップを使用したい類似のスキルのプレイヤーが含まれる可能性が高くなります。
```
"algorithm": {
"batchingPreference": "sorted",
"sortByAttributes": ["map", "player_skill"],
"strategy": "exhaustiveSearch"
},
```
+ **レイテンシーでソート。**可能な限りのレイテンシーでマッチを作成するか、許容できるレイテンシーでマッチを迅速に作成します。このカスタマイズは、40 人以上のプレイヤーが参加する大規模なマッチを形成するルールセットに役立ちます。
アルゴリズムプロパティ `strategy` を `balanced` に設定します。バランス戦略では、使用できるルールステートメントのタイプが制限されます。詳細については、「[FlexMatch の大規模マッチングルールセットを設計する](match-design-rulesets-large.md)」を参照してください。
FlexMatch は、次のいずれかの方法で、プレイヤーから報告されたレイテンシーデータに基づいてチケットをソートします。
+ *レイテンシーが最も低い場所。*チケットプールは、プレイヤーがレイテンシーの最小値を報告するロケーションによって事前にソートされています。 FlexMatch は、同じロケーションでレイテンシーの低いチケットをバッチ処理するため、ゲームプレイエクスペリエンスが向上します。また、各バッチのチケット数を減らすため、マッチメーキングに時間がかかることがあります。このカスタマイズを使用するには、次の例のように `batchingPreference` を `fastestRegion` に設定します。
```
"algorithm": {
"batchingPreference": "fastestRegion",
"strategy": "balanced"
},
```
+ *許容可能なレイテンシーをすぐにマッチングする。*チケットプールは、プレーヤーが許容可能なレイテンシー値を報告するロケーション別に事前にソートされています。これにより、より多くのチケットを含むバッチの数が減ります。各バッチでより多くのチケットがあると、許容可能なマッチを見つけるのが迅速になります。このカスタマイズを使用するには、次の例のようにプロパティ `batchingPreference` を ` largestPopulation` に設定します。
```
"algorithm": {
"batchingPreference": "largestPopulation",
"strategy": "balanced"
},
```
**注記**
バランス戦略のデフォルト値は、`largestPopulation` です。
## バックフィルチケットの優先順位付け
ゲームが自動バックフィルまたは手動バックフィルを実行している場合、FlexMatch はリクエストタイプに基づいてマッチメーキングチケットを処理する方法をカスタマイズできます。リクエストタイプは、新しいマッチリクエストでもバックフィルリクエストでもかまいません。デフォルトでは、FlexMatch はどちらのタイプのリクエストも同様に扱います。
バックフィルの優先順位付けは、FlexMatch がチケットをバッチ処理した後の処理方法に影響します。バックフィルの優先順位付けは、網羅的な検索戦略を使用するルールセットを必要とします。
FlexMatch は複数のバックフィルチケットをまとめてマッチングしません。
バックフィルチケットの優先順位を変更するには、プロパティ `backfillPriority` を設定します。
+ **バックフィルチケットを最初にマッチします。**このオプションは、新しいマッチを作成する前に、バックフィルチケットのマッチングを試みます。つまり、参加するプレイヤーは、既存のゲームにスロットされる可能性が高くなります。
ゲームで自動バックフィルを使用している場合は、これを使用するのが最適です。自動バックフィルは、ゲームセッション時間が短く、プレーヤーのターンアラウンドが高いゲームでよく使用されます。自動バックフィルは、FlexMatch がオープンスロットを埋めるためにより多くのプレイヤーを検索しても、これらのゲームが最小限の実行可能な試合を形成して開始するのに役立ちます。
`backfillPriority` を `high` に設定します。
```
"algorithm": {
"backfillPriority": "high",
"strategy": "exhaustiveSearch"
},
```
+ **バックフィルチケットを最後にマッチングする。**このオプションでは、他のすべてのチケットが評価されるまで、バックフィルチケットは無視されます。つまり、FlexMatch は参加するプレイヤーを新しいゲームにマッチングできない場合にのみ、既存のゲームにバックフィルします。
このオプションは、バックフィルを、新しい試合を形成できるプレーヤーが十分ではない場合などに、プレイヤーがゲームに参加できる最後のチャンスのオプションとして使用する場合に便利です。
`backfillPriority` を `low` に設定します。
```
"algorithm": {
"backfillPriority": "low",
"strategy": "exhaustiveSearch"
},
```
## 拡張時に古いチケットを優先
拡張ルールは、マッチングの完了が難しい場合にマッチング基準を緩和します。 は、部分的に完了したマッチングのチケットが特定の期間に達したときに拡張ルール Amazon GameLift Servers を適用します。チケットの作成タイムスタンプによって、Amazon GameLift Servers が適用されるタイミングが決まります。デフォルトでは、FlexMatch は最後に対戦したチケットのタイムスタンプを追跡します。
FlexMatch が拡張ルールを適用するタイミングを変更するには、プロパティ `expansionAgeSelection` を以下のように設定します。
+ **最新のチケットに基づいて拡張します。**このオプションは、潜在的な対戦に追加された最新のチケットに基づいて拡張ルールを適用します。FlexMatch が新しいチケットをマッチングするたびに、タイムクロックがリセットされます。このオプションを使うと、マッチの質が高くなる傾向がありますが、マッチングに時間がかかる傾向があります。マッチングに時間がかかりすぎると、完了する前にマッチリクエストがタイムアウトする場合があります。`expansionAgeSelection` を `newest` に設定します。`newest` はデフォルトです。
+ **最も古いチケットに基づいて拡張する。**このオプションは、マッチ候補の最も古いチケットに基づいて拡張ルールを適用します。このオプションを使用すると、FlexMatch は拡張をより速く適用するため、最も早くマッチングしたプレイヤーの待ち時間が改善されるますが、すべてのプレイヤーのマッチ品質が低下します。`expansionAgeSelection` を `oldest` に設定します。
```
"algorithm": {
"expansionAgeSelection": "oldest",
"strategy": "exhaustiveSearch"
},
```
# プレイヤー属性の宣言
このセクションでは、マッチメーキングリクエストに含める個々のプレイヤーの属性をリストアップします。ルールセットでプレイヤー属性を宣言する理由は 2 つあります。
+ ルールセットにプレイヤー属性に依存するルールが含まれている場合。
+ マッチリクエストを通じてプレイヤー属性をゲームセッションに渡したい場合。例えば、各プレイヤーが接続する前に、プレイヤーキャラクターの選択肢をゲームセッションに渡したい場合があります。
プレイヤー属性を宣言する際に、以下の情報を含めます。
+ *名前* (必須) この値はルールセットごとにユニークであることが必要です。
+ *type* (必須) 属性値のデータ型です。有効なデータ型は、数値、文字列、または文字列マップです。
+ *default* (オプション) マッチメーキングリクエストが属性値を提供しない場合、使用するデフォルト値を入力します。デフォルトが宣言されておらず、リクエストに値が含まれていない場合、FlexMatch はリクエストを処理できません。
# 対戦チームの定義
マッチング用のチームの構造とサイズを記述します。各マッチングには少なくとも 1 つのチームが必要であり、チームの数は自由に定義できます。チームには同じ数のプレイヤーを含めることも、非対称とすることもできます。たとえば、プレイヤー 1 人のモンスターチームと、プレイヤー 10 人のハンターチームを定義できます。
FlexMatch はルールセットでのチームサイズの定義に基づいて、小規模なマッチング、または大規模なマッチングとしてマッチングリクエストを処理します。最大 40 人のプレイヤーのマッチング案は小規模なマッチングで、40 人を超えるプレイヤーのマッチング案は大規模なマッチングです。ルールセットのマッチングサイズ案を定義するには、ルールセットに定義されたすべてのチームに対して *maxPlayer* 設定を追加します。
+ *名前 *(必須) - 各チームにユニークな名前を割り当てます。この名前はルールや拡張で使用し、FlexMatch はゲームセッションのマッチメーキングデータを参照します。
+ *maxPlayers* (必須) チームに割り当てるプレイヤーの最大数を指定します。
+ *minPlayers* (必須) チームに割り当てるプレイヤーの最小数を指定します。
+ *quantity* (オプション) — この定義で作成するチームの数を指定します。FlexMatch がマッチを作成すると、これらのチームには指定された名前が与えられ、その後に数字が付加されます。例: `Red-Team1`、`Red-Team2`、`Red-Team3`。
FlexMatch は、チームを最大プレイヤー数まで満たすよう試みますが、より少ないプレイヤー数でチームを作成します。マッチング内のすべてのチームのサイズを均等にする場合は、そのためのルールを作成できます。`EqualTeamSizes` ルールの例に関するトピックは、「[FlexMatch ルールセットの例](match-examples.md)」のトピックを参照してください。
# プレイヤーマッチングのルール設定
マッチングの承諾についてプレイヤーを評価する一連のルールステートメントを作成します。ルールにより、個別のプレイヤー、チーム、またはマッチング全体の要件が設定される場合があります。Amazon GameLift Servers がマッチングリクエストを処理する際には、使用可能なプレイヤーのプールで最も古いプレイヤーから開始し、そのプレイヤーを中心にマッチングを構築します。FlexMatch ルール作成の詳細なヘルプについては、「[FlexMatch ルールタイプ](match-rules-reference-ruletype.md)」を参照してください。
+ *[name]* (必須) – ルールセット内のルールをユニークに識別する意味のある名前。ルール名は、このルールに関連するアクティビティを追跡するイベントログとメトリクスでも参照されます。
+ *[description]*(説明)(オプション) - この要素を使用して自由形式のテキストの説明をアタッチします。
+ *[type]*(タイプ)(必須) - タイプ要素は、ルールを処理する際に使用するオペレーションを識別します。各ルールタイプには一連の追加プロパティが必要です。有効なルールタイプとプロパティのリストについては、「[FlexMatch ルール言語](match-rules-reference.md)」を参照してください。
+ ルールタイププロパティ (必須の場合があります) 定義するルールの種類に応じて、特定のルールプロパティの設定が必要になる場合があります。プロパティと FlexMatch プロパティ式言語の使用方法については、「[FlexMatch ルール言語](match-rules-reference.md)」を参照してください。
# 時間の経過による要件の許可
拡張により、FlexMatch がマッチを見つけることができない場合に、時間の経過とともにルール基準を緩和できます。この機能により、FlexMatch では完璧なマッチが得られない場合でも最適な結果が得られます。拡張によりルールを緩和すると、対戦可能なプレイヤーのプールが徐々に拡大されます。
拡張は、不完全なマッチの最新のチケットの経過時間が拡張待機時間と一致する場合に開始されます。FlexMatch が新しいチケットをマッチに追加すると、拡張待機時間クロックがリセットされることがあります。拡張がルールセットの `algorithm` セクションで開始する方法をカスタマイズできます。
以下に、試合に必要な最低スキルレベルが徐々に上昇する拡張の例を挙げます。ルールセットは *SkillDelta* という名前の距離ルールステートメントを使用して、試合内のすべてのプレイヤーが 5 スキルレベル以内であることを要求します。15 秒間新しいマッチが作成されない場合は、この拡張はスキルレベルの差 10 を探し、10 秒後に 20 の差を探します。
```
"expansions": [{
"target": "rules[SkillDelta].maxDistance",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 25,
"value": 20
}]
}]
```
自動バックフィルが有効なマッチメーカーで使用されている場合、プレイヤーカウントの要件を急に緩和しないでください。新しいゲームセッションを起動し、自動バックフィルを開始するには数秒かかります。より良い方法は、自動バックフィルがゲームで開始された後に拡張待機時間を開始することです。拡張タイミングはチームの構成によって異なるため、ゲームに最適な拡張戦略を見つけるためにテストを実施します。
# FlexMatch の大規模マッチングルールセットを設計する
41～200 人のプレイヤーを許可するマッチングがルールセットで作成される場合、ルールセットの設定を調整する必要があります。これらの調整により、対戦アルゴリズムが最適化され、プレーヤーの待機時間を短くしながら、実行可能な大規模なマッチを構築できます。その結果、大規模なマッチルールセットでは、時間のかかるカスタムルールを、一般的なマッチメーキング優先度に最適化されたスタンダード ソリューションに置き換えます。
大規模なマッチに対してルールセットを最適化する必要があるかどうかを判断する方法は次のとおりです。
1. ルールセットで定義された各チームについて、*maxPlayer* の値を取得します、
1. *[maxPlayer]*(最大プレイヤー数) 値のすべてを追加。この設定が 40 を超えている場合は、大規模なマッチルール設定を保持しています。
大規模なマッチに対してルールセットを最適化するには、次のように調整します。大規模なマッチルールセットのスキーマについては、「[大規模対戦用のルールセットスキーマ](match-ruleset-schema-large.md)」およびルールセットの例「[例: 大規模なマッチを作成する](match-examples-7.md)」を参照してください。
# 大規模なマッチアルゴリズムのカスタマイズ
アルゴリズムコンポーネントがまだ存在しない場合は、アルゴリズムコンポーネントをルールセットに追加します。以下のパラメータを設定します。
+ `strategy` (必須)`strategy` プロパティを「バランス」に設定します。この設定は、FlexMatch をトリガーして、指定されたプレイヤー属性 (`balancedAttribute` プロパティで定義) に基づいて最適なチームバランスを見つけるために、追加のマッチ後チェックを実行します。バランスの取れた戦略は、均等に対戦しているチームを構築するためのカスタムルールの必要性を置き換えます。
+ `balancedAttribute` (必須)— 試合中のチームのバランスをとるときに使用するプレイヤー属性を識別します。この属性は、数値データ型 (倍精度または整数) でなければなりません。たとえば、プレイヤースキルのバランスをとることを選択した場合、FlexMatch はすべてのチームに可能な限り均等にマッチする合計スキルレベルを持つようにプレイヤーを割り当てようとします。ルールセットのプレイヤー属性で、必ずバランシング属性を必ず宣言してください。
+ `batchingPreference` (オプション)— プレイヤーにとって可能な限り低いレイテンシー マッチを形成する際にどの程度の重点を置きたいかを選択します。この設定は、試合を構築する前に対戦チケットをソートする方法に影響します。オプションには以下が含まれます。
+ FlexMatch では、共通する少なくとも 1 つのロケーションで許容されるレイテンシー値を持つプール内のすべてのチケットを使用してマッチを許可します。その結果、潜在的なチケットプールは大規模になる傾向があり、試合をより迅速に埋めることが容易になります。プレイヤーは、許容できるが、必ずしも最適ではないレイテンシーでゲームに参加することができます。`batchingPreference` プロパティが設定されていない場合、この動作は、`strategy` が「バランス」に設定されているときにデフォルトになります。
+ FlexMatch は、最も低いレイテンシー値を報告する場所に基づいて、プール内のすべてのチケットを事前にソートします。その結果、同じロケーションでレイテンシーが低いプレイヤーとのマッチが形成される傾向があります。同時に、各試合の潜在的なチケットプールが小さくなり、試合の完了に必要な時間が長くなります。また、レイテンシーに高い優先順位が設定されるため、マッチ中のプレイヤーは、バランシング属性に関して、より差が広がる可能性があります。
以下の例では、次のように動作するように対戦アルゴリズムを設定します。(1) チケットプールを事前にソートして、許容レイテンシー値を持つリージョン別にチケットをグループ化し、(2) ソートされた対戦チケットのバッチを形成し、(3) バッチ内に試合チケットを作成して、プレイヤースキルを平均化できるようにチームのバランスを取ります。
```
"algorithm": {
"strategy": "balanced",
"balancedAttribute": "player_skill",
"batchingPreference": "largestPopulation"
},
```
# プレイヤー属性の宣言
少なくとも、ルールセットのアルゴリズムでバランシング属性として使用されるプレイヤー属性を宣言する必要があります。この属性は、マッチメーキングリクエストの各プレイヤーに対して含める必要があります。プレイヤー属性にはデフォルト値を指定できますが、プレイヤー固有の値を提供した場合に、属性のバランシングが最適に機能します。
# チームの定義
チームサイズと構造を定義するプロセスは小規模のマッチングと同様ですが、FlexMatch がチームを満たす方法は異なります。これは、部分的に満たされた場合の試合に影響します。これに応じて、チームの最小サイズを調整できます。
プレイヤーをチームに割り当てる際に、FlexMatch は以下のルールを使用します。1: 最小プレイヤー要件に到達していないチームを探す。2: これらのチームのうち、空きスロットが最も多いチームを探す。
複数の均等なサイズのチームを定義するマッチングでは、いっぱいになるまでプレイヤーが順に各チームに追加されます。その結果、マッチングがいっぱいでなくても、マッチングのチームのプレイヤー数は、常にほぼ同数になります。現時点では、大規模なマッチでチームサイズを強制的に均等にすることはできません。非対称のチームサイズのマッチングの場合、プロセスはもう少し複雑です。この場合、プレイヤーは空きスロットが最も多い最大のチームに最初に割り当てられます。次に、空きスロットの数がすべてのチーム間でより均等に分配されるにつれて、プレイヤーはより小さなチームに追加され始めます。
たとえば、3 つのチームで構成されるルールセットがあるとします。赤チームと青チームはどちらも `maxPlayers`=10、`minPlayers`=5 に設定されます。グリーンチームは `maxPlayers`=3、`minPlayers`=2 に設定されています。塗りつぶし順序は次のとおりです。
1. どのチームも `minPlayers` に到達していません。赤チームと青チームには 10 個の空きスロットがあり、緑チームには 3 個の空きスロットがあります。最初の 10 人のプレイヤー (5 人ごと) は、赤チームと青チームに割り当てられます。両方のチームが `minPlayers` に達しました。
1. 緑チームはまだ `minPlayers` に達していません。次の 2 人のプレイヤーが緑チームに割り当てられます。グリーンチームが現在 `minPlayers` に達しました。
1. これですべてのチームが `minPlayers` で、オープンスロット数に基づいて追加のプレイヤーが割り当てられてるようになりました。赤チームと青チームにはそれぞれ5個の空きスロットがあり、緑チームには1個の空きスロットがあります。次の 8 人のプレイヤーは、赤チームと青チームに (それぞれ 4 人) 割り当てられます。すべてのチームに 1 つのオープンスロットがあります。
1. 残りの 3 個のプレイヤースロットは、順不同でチームに (1 個ずつ) が割り当てられます。
# 大規模なマッチのルールを設定する
大規模なマッチのマッチメーキングは、主にバランシング戦略とレイテンシーのバッチ最適化に依存します。ほとんどのカスタムルールは使用できません。ただし、以下の種類のルールを組み込むこともできます。
+ プレイヤーのレイテンシーに厳しい制限を設定するルール。`latency` ルールタイプはプロパティ `maxLatency` と一緒に使用してください。[レイテンシールール](match-rules-reference-ruletype.md#match-rules-reference-ruletype-latency) リファレンスを参照してください。最大プレイヤーレイテンシーを 200 ミリ秒に設定する例を次に示します。
```
"rules": [{
"name": "player-latency",
"type": "latency",
"maxLatency": 200
}],
```
+ 指定したプレーヤー属性の近さに基づいてプレーヤーをバッチ処理するルール。これは、均等にマッチしたチームを構築することに重点を置く大規模なマッチアルゴリズムの一部としてバランス属性を定義することとは異なります。このルールは、ビギナースキルやエキスパートスキルなど、指定された属性値の類似性に基づいてマッチメーキングチケットを一括処理します。そのため、特定の属性について密接に整合しているプレイヤー同士がマッチすることになる傾向があります。`batchDistance` ルールタイプを使用し、数値ベースの属性を特定し、許可する最も広い範囲を指定します。[バッチ距離ルール](match-rules-reference-ruletype.md#match-rules-reference-ruletype-batchdistance) リファレンスを参照してください。マッチのプレイヤー同士のスキルレベルが 1 つ以内であることを求める例を以下に示します。
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# 大規模なマッチ要件を緩和する
小規模なマッチングの場合と同様に、マッチングが不可能な場合に時間の経過ともに要件を緩和する拡張を使用できます。大規模なマッチでは、レイテンシールールを緩和するか、チームプレイヤーカウントを緩和するか選択できます。
大規模なマッチに自動マッチングバックフィルを使用している場合は、チームプレイヤーカウントを急に緩和しないでください。FlexMatch はゲームセッションが開始された後にのみバックフィルリクエストを生成します。この動作は、マッチングが作成された後数秒間は発生しないことがあります。その間、FlexMatch は部分的に満たされた複数の新しいゲームセッションを作成します。これは特にプレイヤーカウントルールを低くした場合に発生します。その結果、必要以上の数のゲームセッションが作成され、ゲームセッション間のプレイヤーがまばらになります。ベストプラクティスは、最初のステップとして、ゲームセッションを開始するのに十分な、プレイヤー数の拡張により長い時間を設定します。バックフィルリクエストでは大規模なマッチにより高い優先度が与えられるため、着信プレイヤーは新しいゲームが開始される前に既存のゲームのスロットに配置されます。ゲームに対して最適な待機時間を見つけるために、実験が必要になる場合があります。
黄色チームの待機時間を最初よりも長くして、段階的にプレイヤーカウントを低くする例を次に示します。ルールセット内の待機時間は絶対値であり、複合されないことに注意してください。したがって、最初の拡大が 5 秒で発生し、2 番目の拡張はその 5 秒後から10 秒ごとに発生します。
```
"expansions": [{
"target": "teams[Yellow].minPlayers",
"steps": [{
"waitTimeSeconds": 5,
"value": 8
}, {
"waitTimeSeconds": 10,
"value": 5
}]
}]
```
# チュートリアル: マッチメーキングルールセットを作成する
Amazon GameLift Servers FlexMatch マッチメーカー用のマッチメーキングルールセットを作成する前に、[ルールセット構文](match-rules-reference.md)を確認することをお勧めします。Amazon GameLift Servers コンソールまたは AWS Command Line Interface (AWS CLI) を使用してルールセットを作成すると、それを変更することはできません。
AWS リージョンに設定できるルールセットの最大数には[サービスクォータ](https://console.aws.amazon.com/servicequotas/home/services/gamelift/quotas/)があるため、未使用のルールセットは削除することをお勧めします。
**Topics**
------
#### [ Console ]
**ルールセットを作成する**
1. [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/) で Amazon GameLift Servers コンソールを開きます。
1. ルールセットの作成先の AWS リージョンに切り替えます。ルールセットは、ルールセットを使用するマッチメーキング設定と同じリージョンに定義します。
1. ナビゲーションペインで、[**FlexMatch**]、[**マッチメーキングルールセット**] を選択します。
1. **[マッチメーキングルールセット]** ページで、**[ルールセットを作成]** を選択します。
1. **[マッチメーキングルールセットの作成]** ページで、次の操作を行います。
1. **[ルールセット設定]** の **[名前]** に、リスト、イベント、メトリクステーブルで識別できる一意のわかりやすい名前を入力します。
1. **[ルールセット]** には、JSON 形式のルールセットを入力します。ルール指定に関する情報は、「[FlexMatch ルールセットを設計する](match-design-ruleset.md)」を参照してください。[FlexMatch ルールセットの例](match-examples.md) からルールセット例を使用することもできます。
1. **[検証]** をクリックし、ルールセットの構文が正しいことを検証します。ルールセットは、作成した後に編集できないため、ルールセットを検証するようお勧めします。
1. (オプション) **[タグ]** に、リソースの管理と追跡に役立つタグを追加します。AWS
1. **[作成]** を選択します。正常に作成されたら、そのルールセットをマッチメーカーで使用できます。
------
#### [ AWS CLI ]
**ルールセットを作成する**
コマンドラインウィンドウを開き、[create-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-rule-set.html) コマンドを使用します。
このコマンド例では、1 つのチームをセットアップする簡単なマッチメーキングルールセットを作成します。ルールセットは、それを使用するマッチメーキング設定と同じ AWS リージョンで必ず作成してください。
```
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}]}'
```
作成リクエストが成功すると、指定した設定が含まれている [MatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html) オブジェクトが Amazon GameLift Servers から返されます。これでマッチメーカーで新しいルールセットを使用できるようになりました。
------
------
#### [ Console ]
**ルールセットを削除する**
1. [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/) で Amazon GameLift Servers コンソールを開きます。
1. ルールセットを作成したリージョンに切り替えます。
1. ナビゲーションペインで、[**FlexMatch**]、[**マッチメーキングルールセット**] を選択します。
1. **[マッチメーキングルールセット]** ページで、削除するルールセットを選択し、**[削除]** を選択します。
1. **[ルールセットの削除]** のダイアログボックスで、**[削除]** を選択して確認します。
**注記**
マッチメーキング設定がルールセットを使用している場合、Amazon GameLift Servers はエラーメッセージ (**ルールセットを削除できません**) を表示します。この場合は、別のルールセットを使用するようにマッチメーキング設定を変更してから、もう一度試してください。ルールセットを使用しているマッチメーキング設定を見つけるには、ルールセット名を選択してその詳細ページを表示します。
------
#### [ AWS CLI ]
**ルールセットを削除する**
コマンドラインウィンドウを開き、[delete-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-matchmaking-rule-set.html) コマンドを使用してマッチメーキングルールセットを削除します。
マッチメーキング設定がルールセットを使用している場合、Amazon GameLift Servers はエラーメッセージを返します。この場合は、別のルールセットを使用するようにマッチメーキング設定を変更してから、もう一度試してください。ルールセットを現在使用しているマッチメーキング設定のリストを取得するには、コマンド [describe-matchmaking-configurations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-matchmaking-configurations.html) を使用し、ルールセット名を指定します。
このコマンド例では、最初にマッチメーキングルールセットの使用状況を確認し、次にルールセットを削除します。
```
aws gamelift describe-matchmaking-rule-sets \
--rule-set-name "SampleRuleSet123" \
--limit 10
aws gamelift delete-matchmaking-rule-set \
--name "SampleRuleSet123"
```
------
# FlexMatch ルールセットの例
FlexMatch ルールセットは、さまざまなマッチメーキングシナリオに対応できます。以下の例は、FlexMatch 設定構造およびプロパティ式の言語に準拠しています。これらのルールセット全体をコピーするか、必要に応じてコンポーネントを選択します。
FlexMatch ルールおよびルールセットの詳しい使用方法については、以下のトピックを参照してください。
**注記**
複数のプレイヤーが含まれるマッチメーキングチケットを評価する場合は、リクエスト内のすべてのプレイヤーがマッチング要件を満たす必要があります。
**Topics**
+ [例: プレイヤーが均等にマッチングされる 2 つのチームを作成する](match-examples-1.md)
+ [例: 不均等なチーム (ハンター対モンスター) を作成する](match-examples-2.md)
+ [例: チームレベル要件とレイテンシーの制限を設定する](match-examples-3.md)
+ [例: 明示的な並べ替えを使用して最適なマッチングを見つける](match-examples-4.md)
+ [例: 複数のプレイヤー属性間の交差を見つける](match-examples-5.md)
+ [例: すべてのプレイヤー間の属性の比較](match-examples-6.md)
+ [例: 大規模なマッチを作成する](match-examples-7.md)
+ [例: 複数チームのラージ試合を作成する](match-examples-8.md)
+ [例: 類似の属性を持つプレイヤーとの大規模なマッチを作成する](match-examples-9.md)
+ [例: 複合ルールを使用して、類似の属性または類似のセレクションを持つプレイヤーとのマッチを作成する](match-examples-10.md)
+ [例: プレイヤーのブロックリストを使用するルールを作成する](match-examples-11.md)
# 例: プレイヤーが均等にマッチングされる 2 つのチームを作成する
この例では、プレイヤーが均等にマッチングされる 2 つのチームを設定する手順を示します。
+ プレイヤーのチームを 2 つ作成します。
+ 各チームに 4〜8 名のプレイヤーを含めます。
+ 最終的に両チームのプレイヤー数は同じにする必要があります。
+ プレイヤーのスキルレベルを含めます (指定しない場合、デフォルトの 10 が使用されます)。
+ スキルレベルが類似するプレイヤーを選択します。両チームのプレイヤーの平均スキル差は 10 ポイント以内とします。
+ すぐにマッチングが満たされない場合は、妥当な時間内にマッチングが完了するようにプレイヤーのスキル要件を緩和します。
+ 5 秒後に、検索範囲を広げて平均スキル差が 50 ポイント以内のプレイヤーを対象にします。
+ 15 秒後に、検索範囲を広げて平均スキル差が 100 ポイント以内のプレイヤーを対象にします。
このルールセットの使用に関する注意事項
+ この例では、チームのサイズが 4 〜 8 プレイヤーの任意のチームを対象にしています (ただし、両チームのサイズは同じにする必要があります)。チームのサイズが有効な範囲内である場合、マッチメーカーはできる限り最大数のプレイヤーをマッチングします。
+ `FairTeamSkill` ルールでは、プレイヤーのスキルに基づいてチームを均等にマッチングします。新たな見込みプレイヤーごとにこのルールを評価するために、FlexMatch は暫定的にチームにプレーヤーを追加し、平均を計算します。ルールが失敗すると、プレイヤー候補はマッチングに追加されません。
+ 両方のチームは同一の構造を持っているため、1 つのチーム定義だけを作成し、チーム数を "2" に設定できます。このシナリオでは、チームを "aliens" と名付けた場合、チームには "aliens\$11" と "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
}]
}]
}
```
# 例: 不均等なチーム (ハンター対モンスター) を作成する
この例は、プレイヤーのグループが単一のモンスターをハントするゲームモードを示しています。プレイヤーは、ハンターまたはモンスターのロールを選択します。ハンターは、敵対するモンスターの最小スキルレベルを指定します。ハンターチームの最小サイズは、マッチングを達成するために徐々に緩和できます。このシナリオでは、以下の手順に従います。
+ 正確に 5 名のハンターで構成される 1 つのチームを作成します。
+ 正確に 1 匹のモンスターで構成される別のチームを作成します。
+ 以下のプレイヤー属性を含めます。
+ プレイヤーのスキルレベル (指定しない場合、デフォルトの 10 が使用されます)。
+ プレイヤーが希望するモンスターのスキルレベル (指定しない場合、デフォルトの 10 が使用されます)。
+ プレイヤーがモンスターのロールを希望するかどうか (指定しない場合、デフォルトで 0 または false になります)。
+ 以下の条件に基づいてモンスターとなるプレイヤーを選択します。
+ プレイヤーはモンスターのロールをリクエストする必要があります。
+ プレイヤーは、ハンターチームに既に追加されているプレイヤーが希望する最高のスキルレベルを達成済みであるか、超えている必要があります。
+ 以下の条件に基づいてハンターチームに属するプレイヤーを選択します。
+ モンスターのロールをリクエストしたプレイヤーは、ハンターチームに参加できません。
+ モンスターのロールが既に埋まっている場合、プレイヤーが希望するモンスターのスキルレベルは、モンスター候補のスキルより低くなければなりません。
+ すぐにマッチングが達成されない場合は、以下のようにハンターチームの最小サイズを緩和します。
+ 30 秒後に、ハンターチームのプレイヤー 4 名のみでゲームを開始することを許可します。
+ 60 秒後に、ハンターチームのプレイヤー 3 名のみでゲームを開始することを許可します。
このルールセットの使用に関する注意事項
+ ハンターとモンスターに 2 つの異なるチームを使用することで、さまざまな条件のセットに基づいてメンバーシップを評価できます。
```
{
"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
}]
}]
}
```
# 例: チームレベル要件とレイテンシーの制限を設定する
この例は、プレイヤーチームのセットアップ方法と、各プレイヤーの代わりに各チームに一連のルールセットを適用する方法を示しています。3 つの均等にマッチングされたチームを作成するための 1 つの定義を使用します。また、すべてのプレイヤーの最大レイテンシーを設定します。レイテンシーの最大値は、マッチングを達成するために徐々に緩和できます。この例では、以下の手順を開始します。
+ プレイヤーのチームを 3 つ作成します。
+ 各チームに 3〜5 名のプレイヤーを含めます。
+ 各チームの最終的なプレイヤー数は同数またはほぼ同数 (差は 1 以内) にする必要があります。
+ 以下のプレイヤー属性を含めます。
+ プレイヤーのスキルレベル (指定しない場合、デフォルトの 10 が使用されます)。
+ プレイヤーのキャラクターロール (指定しない場合、デフォルトの「農民」が使用されます)。
+ マッチングのスキルレベルが類似するプレイヤーを選択します。
+ 各チームのプレイヤーの平均スキル差は 10 ポイント以内とします。
+ チームの「医者」キャラクターを以下の数に制限します。
+ マッチング全体の医者の最大数は 5 とします。
+ 50 ミリ秒以下のレイテンシーを報告したプレイヤーのみにマッチングします。
+ すぐにマッチングが達成されない場合は、以下のようにプレイヤーのレイテンシー要件を緩和します。
+ 10 秒後に、プレイヤーのレイテンシー値として最大 100 ミリ秒まで許可します。
+ 20 秒後に、プレイヤーのレイテンシー値として最大 150 ミリ秒まで許可します。
このルールセットの使用に関する注意事項
+ このルールセットでは、プレイヤーのスキルに基づいてチームを均等にマッチングします。`FairTeamSkill` ルールを評価するため、FlexMatch が暫定的にプレイヤー候補をチームに追加し、チームのプレイヤーの平均スキルを計算します。次に、これを両方のチームのプレイヤー平均スキルと比較します。ルールが失敗すると、プレイヤー候補はマッチングに追加されません。
+ チームレベルおよびマッチングレベルの要件 (医者の総数) は、収集ルールを通じて達成されます。このルールタイプでは、すべてのプレイヤーのキャラクター属性のリストを、最大数に照らしてチェックします。すべてのチームのすべてのプレイヤーのリストを作成するには、`flatten` を使用します。
+ レイテンシーに基づいて評価する場合は、以下の点に注意してください。
+ レイテンシーデータは、Player オブジェクトの一部としてマッチメーキングリクエストで提供されます。これは属性ではないため、属性としてリストする必要はありません。正確なレイテンシー測定値を取得するには、Amazon GameLift Servers の UDP ping ビーコンを使用します。これらのエンドポイントを使用すると、プレイヤーデバイスと潜在的な各ホスティングロケーション間の実際の UDP ネットワークレイテンシーを測定できるため、ICMP ping を使用するよりも正確な配置決定を行うことができます。UDP ping ビーコンを使用してレイテンシーを測定する方法の詳細については、[「UDP ping ビーコン](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)」を参照してください。
+ マッチメーカーは、リージョン別にレイテンシーを評価します。レイテンシーが最大数を超えるすべてのリージョンは無視されます。プレイヤーがマッチングで承諾されるためには、レイテンシーが最大値未満のリージョンが少なくとも 1 つ必要です。
+ マッチメーキングリクエストが 1 人または複数のプレイヤーのレイテンシデータを省略した場合、そのリクエストはすべてのマッチで拒否されます。
```
{
"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
}]
}]
}
```
# 例: 明示的な並べ替えを使用して最適なマッチングを見つける
この例では、3 人ずつのプレイヤーで構成される 2 つのチームでシンプルなマッチングを設定します。明示的な並べ替えルールを使用して、可能な限り最良のマッチングをできるだけ早く見つける方法を示します。これらのルールでは、すべてのアクティブなマッチメーキングチケットを事前に並べ替え、特定のキーとなる要件に基づいて最適な対戦を作成します。この例は、以下の手順に従って実装します。
+ プレイヤーのチームを 2 つ作成します。
+ 各チームを正確に 3 人のプレイヤーで構成します。
+ 以下のプレイヤー属性を含めます。
+ 経験レベル (指定しない場合、デフォルトで 50 が使用されます)。
+ 優先するゲームモード (複数の値をリスト可能) (指定しない場合、デフォルトで「クープ」と「デスマッチ」が使用されます)。
+ 優先するゲームマップ (マップ名と優先重み付けを含む) (指定しない場合、デフォルトで重み 100 の `"defaultMap"` が使用されます)。
+ 事前並べ替えを設定します。
+ アンカープレイヤーとして同じゲームマップを優先する度合いに基づいてプレイヤーを並べ替えます。プレイヤーのお気に入りのゲームマップは複数存在することがあるため、この例では優先値を使用しています。
+ 経験レベルがアンカープレイヤーとどれだけ近くマッチングするかに基づいてプレイヤーを並べ替えます。この並べ替えにより、すべてのチーム間ですべてのプレイヤーの経験レベルができるだけ近いものになります。
+ すべてのチーム間ですべてのプレイヤーが少なくとも 1 つのゲームモードを共通して選択している必要があります。
+ すべてのチーム間ですべてのプレイヤーが少なくとも 1 つのゲームマップを共通して選択している必要があります。
このルールセットの使用に関する注意事項
+ ゲームマップの並べ替えでは、mapPreference 属性値を比較する絶対並べ替えを使用します。これはルールセットの最初のルールであるため、この並べ替えが最初に実行されます。
+ 経験の並べ替えでは、アンカープレイヤーのスキルとともに候補プレイヤーのスキルレベルを比較するために、距離の並べ替えが使用されます。
+ 並べ替えは、ルールセットで指定された順に実行されます。このシナリオでは、プレイヤーがゲームマップの優先度によって並べ替えられ、さらに経験レベル順に並べ替えられます。
```
{
"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
}]
}
```
# 例: 複数のプレイヤー属性間の交差を見つける
この例では、収集ルールを使用して、2 つ以上のプレイヤー属性の交差を見つける方法を説明します。コレクションを操作するときは、1 つの属性に対しては `intersection` オペレーションを使用し、複数の属性に対しては `reference_intersection_count` オペレーションを使用できます。
この方法を説明するために、この例ではキャラクターの設定に基づいて、マッチングのプレイヤーを評価します。このサンプルゲームは自由に参加できる形式で、マッチングのすべてのプレイヤーが対戦相手になります。各プレイヤーは、(1) 自分のキャラクターを選択し、(2) 対戦するキャラクターを選択することが求められます。マッチングの各プレイヤーが、他のすべてのプレイヤーの希望する対戦相手リストに含まれているキャラクターを使用するようにするルールが必要です。
このルールセットの例では、次の特性を持つマッチングについて説明します。
+ チーム構造: 5 人のプレイヤーがいる 1 つのチーム
+ プレイヤー属性:
+ *myCharacter*: プレイヤーが選択したキャラクター。
+ *preferredOpponents*: プレイヤーが対戦したいキャラクターのリスト。
+ マッチングルール: 使用中の各キャラクターが各プレイヤーの希望する対戦リストに含まれている場合、マッチング候補は受け入れ可能です。
マッチングルールを実装するため、この例では次のプロパティ値を持つ収集ルールを使用します。
+ オペレーション - `reference_intersection_count` オペレーションを使用して、測定値の文字列リストがリファレンス値の文字列リストと交差する方法を評価します。
+ 測定 - `flatten` プロパティ表現を使用して文字列のリストを作成し、各リストに 1 人のプレイヤーの *myCharacter* 属性値を含めます。
+ リファレンス値 - `set_intersection` プロパティ表現を使用して、試合の各プレイヤーに共通するすべての *preferredOpponents* 属性値を含む文字列のリストを作成します。
+ 制約 - `minCount` を 1 に設定し、各プレイヤーの選択したキャラクター (測定値の文字列のリスト) が、すべてのプレイヤーに共通の 1 人以上の優先される対戦相手 (リファレンス値の文字列) と一致するようにします。
+ 拡張 15 秒以内にマッチングが達成されない場合は、最小の交差要件を緩和します。
このルールのプロセスフローは次のようになります。
1. プレイヤーがマッチング候補に追加されます。参照値 (文字列のリスト) が再計算され、新しいプレイヤーの希望の対戦相手リストに交差が含まれるようにします。計測値 (文字列のリスト) が再計算され、新しいプレイヤーの選択されたキャラクターが新しい文字列リストとして追加されます。
1. Amazon GameLift Servers は測定値 (プレイヤーが選択したキャラクター) の各文字列リストが、参照値 (プレイヤーの希望する対戦相手) の少なくとも 1 つの文字列と交差することを確認します。この例では、測定値の各文字列リストには値が 1 つしか含まれないため、交差は 0 または 1 になります。
1. 測定値の文字列リストが参照値の文字列リストと交差しない場合、ルールは失敗し、新しいプレイヤーはマッチング候補から削除されます。
1. マッチングが 15 秒以内に達成されない場合は、対戦相手のマッチング要件を削除し、マッチングの残りのプレイヤースロットを埋めます。
```
{
"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
}]
}]
}
```
# 例: すべてのプレイヤー間の属性の比較
この例では、プレイヤーのグループ間でプレイヤー属性を比較する方法を示します。
このルールセットの例では、次の特性を持つマッチングについて説明します。
+ チーム構造: 2 つの単一プレイヤーチーム
+ プレイヤー属性:
+ *gameMode*: プレイヤーによって選択されたゲームのタイプ (指定されていない場合は、デフォルトで「順番ベース」となります)。
+ *gameMap*: プレイヤーによって選択されたゲーム世界 (指定されない場合は、デフォルトで 1 になります)。
+ *キャラクター*: プレイヤーによって選択されたキャラクター (デフォルト値がない場合、プレイヤーはキャラクターを指定する必要があります)。
+ マッチングルール: マッチングされたプレイヤーは次の要件を満たす必要があります。
+ プレイヤーは同じゲームモードを選択する必要があります。
+ プレイヤーは同じゲームマップを選択する必要があります。
+ 多くのプレイヤーは異なるキャラクターを選択します。
このルールセットの使用に関する注意事項
+ この例では、マッチングルールを実装するため、比較ルールを使用してすべてのプレイヤーの属性値を確認します。ゲームモードとマップについては、値が同じことがルールで確認されます。キャラクターについては、値が異なることがルールで確認されます。
+ この例では、両方のプレイヤーチームを作成するために数量プロパティを指定して 1 つのプレイヤー定義を使用します。チームには、"player\$11" や "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])"]
}]
}
```
# 例: 大規模なマッチを作成する
この例では、40 人を超えるプレイヤーのマッチングに対するルールセットを設定する方法を示します。ルールセットでチームの maxPlayer 合計カウントが 40 以上であると定義された場合、大規模なマッチとして処理されます。詳細については、「[FlexMatch の大規模マッチングルールセットを設計する](match-design-rulesets-large.md)」を参照してください。
この例のルールセットでは、以下の手順に従ってマッチングが作成されます。
+ 最大 200 人、最低 175 人のプレイヤーがいる 1 つのチームを作成します。
+ バランシング条件: 類似したスキルレベルに基づいてプレイヤーを選択します。すべてプレイヤーは、マッチングのためにスキルレベルを報告する必要があります。
+ バッチ優先設定: マッチングの作成時に、類似したバランシング条件によってプレイヤーをグループ化します。
+ レイテンシールール: 最大許容プレイヤーレイテンシーとして 150 ミリ秒を設定します。
+ すぐにマッチングが満たされない場合は、妥当な時間内にマッチングを完了するために要件を緩和します。
+ 10 秒後に、プレイヤーが 150 人のチームを受け入れます。
+ 12 秒後に、許容されるレイテンシーの最大値を 200 ミリ秒に引き上げます。
+ 15 秒後に、プレイヤーが 100 人のチームを受け入れます。
このルールセットの使用に関する注意事項
+ アルゴリズムは「最大母集団」バッチ優先設定を使用しているため、プレイヤーはまずバランシング要件に基づいて並べ替えられます。その結果、マッチングはより詳細になり、スキルがより類似したプレイヤーが含まれる可能性が高くなります。すべてのプレイヤーは許容されるレイテンシー要件を満たしますが、その場所での最大限のレイテンシーを取得できない可能性もあります。
+ ルールセットで使用されるこのアルゴリズム戦略は、「最大母集団」がデフォルト設定です。デフォルト設定を使用するには、設定を省略することもできます。
+ マッチングバックフィルを有効にしている場合は、プレイヤーカウント要件を急に緩和しないでください。緩和が速すぎると、部分的に満たされたゲームセッションが大量に生成される可能性があります。詳細については、「[大規模なマッチ要件を緩和する](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
}]
}]
}
```
# 例: 複数チームのラージ試合を作成する
この例は、プレイヤーが 40 人を超える複数チームのマッチング用にルールをセットセットアップする方法を示しています。この例は、1 つの定義を持つ複数の同じチームを作成する方法と、マッチング作成で非対称サイズのチームを満たす方法を示しています。
この例のルールセットでは、以下の手順に従ってマッチングが作成されます。
+ 最大 15 人のプレイヤーがいる同一の「ハンター」チームを 10 個と、厳密に 5 人のプレイヤーがいる「モンスター」チームを 1 個作成します。
+ バランシング要件: モンスターを倒した数を基準にプレイヤーを選択します。プレイヤーが倒した数を報告しない場合は、デフォルト値の 5 を使用します。
+ バッチ優先設定: 最短のプレイヤーレイテンシーが報告されているリージョンを基準に、プレイヤーをグループ化します。
+ レイテンシールール: 許容されるプレイヤーレイテンシーの最大値を 200 ミリ秒に設定します。
+ すぐにマッチングが満たされない場合は、妥当な時間内にマッチングを完了するために要件を緩和します。
+ 15 秒後に、10 人のプレイヤーチームを受け入れます。
+ 20 秒後に、8 人のプレイヤーチームを受け入れます。
このルールセットの使用に関する注意事項
+ このルールセットは、潜在的に最大 155 人のプレイヤーを保持できるチームを定義します。これは大規模なマッチとなります。（10×15ハンター \$1 5 モンスター = 155）
+ アルゴリズムは「最短リージョン」バッチ優先設定を使用しているため、プレイヤーはより高い (許容範囲内の) レイテンシーを報告しているリージョンよりも、より速いレイテンシーを報告しているリージョンに配置される傾向があります。同時に、マッチングのプレイヤーはより少数になり、バランシング条件 (モンスタースキルの数) はより広範囲になる可能性があります。
+ 拡張は、複数チーム (数量 > 1) に対して定義された場合、定義を作成したすべてのチームに適用されます。したがって、ハンターチームの最小プレイヤー設定を緩和することによって、10 個すべてのハンターチームが同様に影響を受けます。
+ このルールセットはプレイヤーレイテンシーを最小にするために最適化されているため、このレイテンシールールは許容される接続オプションを持たないプレイヤーを除外するキャッチオールとして機能します。この要件を緩和する必要はありません。
+ 拡張が有効になる前に FlexMatch がこのルールセットに対してマッチングを満たす方法は、次のとおりです。
+ どのチームも minPlayers カウントにまだ達していません。ハンターチームには 15 個の空きスロットがあり、モンスターチームには 5 つの空きスロットがあります。
+ 最初の 100 人のプレイヤーが (10 人ずつ) 10 個のハンターチームに割り当てられます。
+ 次の 22 名のプレイヤーは順番に (2 人ずつ) ハンターチームとモンスターチームに割り当てられます。
+ ハンターチームはそれぞれ minPlayers カウントである 12 人のプレイヤーに達しました。モンスターチームには 2 人のプレイヤーがいて、minPlayers カウントには達していません。
+ 次の 3 人のプレイヤーがモンスターチームに割り当てられます。
+ すべてのチームが minPlayers カウントに達しました。ハンターチームにはそれぞれ 3 つの空きスロットがあります。モンスターチームのスロットがいっぱいになりました。
+ 最後の 30 人のプレイヤーが順にハンターチームに割り当てられ、すべてのハンターチームがほぼ同じサイズ (\$1/- 1 人のプレイヤー) になります。
+ このルールセットを使用して作成されたマッチングに対してバックフィルが有効になっている場合、プレイヤーカウント要件を急に緩和しないでください。緩和が速すぎると、部分的に満たされたゲームセッションが大量に作成される可能性があります。詳細については、「[大規模なマッチ要件を緩和する](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
}]
}]
}
```
# 例: 類似の属性を持つプレイヤーとの大規模なマッチを作成する
この例では、`batchDistance` を使用して 2 つのチームとの試合にルールセットを設定する方法を示します。これらの例では:
+ `SimilarLeague` ルールにより、試合内のすべてのプレイヤーが、他の 2 人のプレイヤーとの間で `league` に参加します。
+ `SimilarSkill` ルールにより、試合内のすべてのプレイヤーが、他の 10 人のプレイヤーとの間で `skill` に参加します。プレイヤーが 10 秒待っている場合、距離は20に拡大されます。プレイヤーが 20 秒待っている場合、距離は40に拡大されます。
+ `SameMap` ルールにより、試合内のすべてのプレイヤーが同じ `map` をリクエストしていることが保証されます。
+ `SameMode`ルールにより、試合内のすべてのプレイヤーが同じことをリクエストしていることが保証されます`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
}]
}]
}
```
# 例: 複合ルールを使用して、類似の属性または類似のセレクションを持つプレイヤーとのマッチを作成する
この例では、`compound` を使用して 2 つのチームとの試合にルールセットを設定する方法を示します。これらの例では:
+ `SimilarLeagueDistance` ルールにより、試合内のすべてのプレイヤーが、他の 2 人のプレイヤーとの間で `league` に参加します。
+ `SimilarSkillDistance` ルールにより、試合内のすべてのプレイヤーが、他の 10 人のプレイヤーとの間で `skill` に参加します。プレイヤーが 10 秒待っている場合、距離は20に拡大されます。プレイヤーが 20 秒待っている場合、距離は40に拡大されます。
+ `SameMapComparison` ルールにより、試合内のすべてのプレイヤーが同じ `map` をリクエストしていることが保証されます。
+ `SameModeComparison`ルールにより、試合内のすべてのプレイヤーが同じことをリクエストしていることが保証されます`mode`。
+ `CompoundRuleMatchmaker` ルールにより、以下の条件の内 1 つが true である場合に、マッチを保証します。
+ マッチ内のプレイヤーは同じ `map` と同じ `mode` リクエストしています。
+ マッチに参加したプレイヤーには、同等の `skill` および `league` 属性があります。
```
{
"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
}]
}]
}
```
# 例: プレイヤーのブロックリストを使用するルールを作成する
この例は、プレーヤーが他の特定のプレーヤーとマッチングされないようにするルールセットを示しています。プレイヤーはブロックリストを作成できます。ブロックリストは、マッチのプレイヤー選択時にマッチメーカーが評価します。ブロックリストまたは回避リスト機能の追加に関する詳しいガイダンスについては、「[AWS for Games ブログ](https://aws.amazon.com/blogs/gametech/category/game-development/amazon-gamelift/)」を参照してください。
この例では、以下の手順を開始します。
+ 正確に 5 人のプレイヤーで構成される 2 つのチームを作成します。
+ プレイヤー ID (最大 100 個) のリストであるプレイヤーのブロックリストを渡します。
+ 全プレイヤーを各プレイヤーのブロックリストと比較し、ブロックされたプレイヤー ID が見つかった場合はマッチを拒否します。
このルールセットの使用に関する注意事項
+ 新規プレイヤーを評価して提案されたマッチに追加する (または既存のマッチでポジションをバックフィルする) 場合、そのプレイヤーは以下のいずれかの理由で拒否されることがあります。
+ その新規プレイヤーが、すでにマッチに選ばれているプレイヤーのブロックリストに載っている場合。
+ マッチにすでに選ばれているプレイヤーが新しいプレイヤーのブロックリストに載っている場合。
+ このように、このルールセットでは、ブロックリストにあるどのプレイヤーともプレイヤーをマッチングさせません。ルール拡張を追加して `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
}]
}
```