FlexMatch ルールセットの設計 - Amazon GameLift
ルールセットを記述する (必須)マッチアルゴリズムのカスタマイズプレイヤー属性の宣言対戦チームの定義 プレイヤーマッチングのルール設定時間の経過による要件の許可

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

FlexMatch ルールセットの設計

このトピックでは、ルールセットの基本構造と最大 40 人のプレイヤーのマッチに使用するルールセットの構築方法について説明します。マッチメーキングルールセットは、2 つの操作を行います。1 つ目はマッチングのチーム構造とサイズを設計すること、2 つ目は可能な限り最良のマッチを形成するプレイヤーの選択方法をマッチメーカーに伝えることです。

マッチメーキングルールセットは他にもできることが多くあります。例えば、以下のことが可能です。

  • ゲームのマッチメーキングアルゴリズムを最適化します。

  • ゲームプレイの品質を保護するために、最小プレイヤーレイテンシー要件をセットアップします。

  • 時間をかけてチームの要件とマッチルールを徐々に緩和していき、アクティブなプレイヤー全員が希望するマッチを見つけられるようにします。

  • パーティーの集約を使用してグループのマッチメーキングリクエストの処理を定義します。

  • 40 人以上のプレイヤーが集まる大規模なマッチを処理します。大きなマッチの構築に関する詳細については、「ラージ対戦ルールセットの設計」を参照してください。

マッチメーキングのルールセットを作成する際は、以下のオプションタスクと必須タスクを検討してください。

ルールセットは、Amazon GameLift コンソールまたは CreateMatchmakingRuleSet オペレーションを使用して作成できます。

ルールセットを記述する (必須)

ルールセットの詳細を指定します。

  • name (オプション) – 自分で使用するためのわかりやすいラベル。この値は、Amazon GameLift でルールセットを作成するときに指定するルールセット名とは関連付けられていません。

  • ruleLanguageVersion – FlexMatch ルールの作成に使用されるプロパティ式言語のバージョン。値は 1.0 にする必要があります。

マッチアルゴリズムのカスタマイズ

FlexMatch は、ほとんどのゲームに対してデフォルトのアルゴリズムを最適化し、プレイヤーを最小限の待機時間で許容可能なマッチに入れます。ゲームのアルゴリズムをカスタマイズし、マッチメーキングを調整できます。

以下はデフォルトの FlexMatch マッチメーキングアルゴリズムです。

  1. FlexMatch は、オープンマッチメーキングチケットとバックフィルチケットはすべてチケットプールに配置します。

  2. FlexMatch は、プール内のチケットを 1 つ以上のバッチにランダムにグループ化します。チケットプールが大きくなると、FlexMatch は最適なバッチサイズを維持するために追加のバッチを作成します。

  3. FlexMatch は、各バッチ内のチケットを経過時間別にソートします。

  4. FlexMatch は、各バッチの最も古いチケットに基づいてマッチを作成します。

対戦アルゴリズムをカスタマイズするには、ルールセットスキーマに algorithm コンポーネントを追加します。詳細については、FlexMatch ルールセットスキーマ コマンドのリファレンスを参照してください。

次のオプションのカスタマイズは、マッチメーキングプロセスのさまざまな段階に影響します。

事前バッチソートの追加

バッチを作成する前にチケットプールをソートします。このタイプのカスタマイズは、大規模なチケットプールを持つゲームで最も効果的です。事前バッチソートは、マッチメーキングプロセスをスピードアップし、定義された特性においてプレイヤーの均一性を高めるのに役立ちます。

バッチ前のソート方法は、アルゴリズムプロパティbatchingPreference で定義します。デフォルトの設定は、random です。

事前バッチソートのカスタマイズには、次のオプションが含まれます。

  • [Sort by player attributes.]（プレイヤーの属性でソート。） チケットプールを事前ソートするプレイヤー属性のリストを提供します。

    プレイヤー属性でソートするには、batchingPreference を sorted に設定し、sortByAttributesでプレイヤー属性のリストを定義します。属性を使用するには、最初にルールセットの playerAttributes コンポーネント内で属性を宣言します。

    次の例では、FlexMatch はプレイヤーの優先ゲームマップに基づいてチケットプールをソートし、次にプレイヤーのスキル別にソートします。結果のバッチには、同じマップを使用したい類似のスキルのプレイヤーが含まれる可能性が高くなります。

    "algorithm": {
    "batchingPreference": "sorted",
    "sortByAttributes": ["map", "player_skill"],
    "strategy": "exhaustiveSearch"
},

  • [Sort by latency](レイテンシーでソート) 可能な限りのレイテンシーでマッチを作成するか、許容できるレイテンシーでマッチを迅速に作成します。このカスタマイズは、40 人以上のプレイヤーが参加する大規模なマッチを形成するルールセットに役立ちます。

    アルゴリズムプロパティ strategy を balanced に設定します。バランス戦略では、使用できるルールステートメントのタイプが制限されます。詳細については、「ラージ対戦ルールセットの設計」を参照してください。

    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 は、部分的に完了した試合のチケットが特定の期間に達したときに拡張ルールを適用します。チケットの作成タイムスタンプによって、Amazon GameLift がルールを適用するタイミングが決まります。デフォルトでは、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 ルールセットの例」のトピックを参照してください。

プレイヤーマッチングのルール設定

マッチングの承諾についてプレイヤーを評価する一連のルールステートメントを作成します。ルールにより、個別のプレイヤー、チーム、またはマッチング全体の要件が設定される場合があります。Amazon GameLift がマッチングリクエストを処理する際には、使用可能なプレイヤーのプールで最も古いプレイヤーから開始し、そのプレイヤーを中心にマッチを構築します。FlexMatch ルール作成の詳細なヘルプについては、「FlexMatch ルールタイプ」を参照してください。

  • name (必須) – ルールセット内のルールをユニークに識別する意味のある名前。ルール名は、このルールに関連するアクティビティを追跡するイベントログとメトリクスでも参照されます。

  • [description](説明 )(オプション) この要素を使用して自由形式のテキストの説明をアタッチします。

  • [type](タイプ) (必須) タイプ要素は、ルールを処理する際に使用するオペレーションを識別します。各ルールタイプには一連の追加プロパティが必要です。有効なルールタイプとプロパティのリストについては、「FlexMatch ルール言語」を参照してください。

  • ルールタイププロパティ (必須の場合があります) 定義するルールの種類に応じて、特定のルールプロパティの設定が必要になる場合があります。プロパティと FlexMatch プロパティ表現言語の使用方法については、「FlexMatch ルール言語」の詳細はこちら。

時間の経過による要件の許可

拡張により、 FlexMatch がマッチを見つけることができない場合に、時間の経過とともにルール基準を緩和できます。この機能により、FlexMatch では完璧なマッチが得られない場合でも最適な結果が得られます。拡張によりルールを緩和すると、対戦可能なプレイヤーのプールが徐々に拡大されます。

拡張は、不完全なマッチの最新のチケットの経過時間が拡張待機時間と一致する場合に開始されます。FlexMatch が新しいチケットをマッチに追加すると、拡張待機時間クロックがリセットされることがあります。拡張がルールセットの algorithm セクションで開始する方法をカスタマイズできます。

以下に、試合に必要な最低スキルレベルが徐々に上昇する拡張の例を挙げます。ルールセットは SkillDelta という名前の距離ルールステートメントを使用して、試合内のすべてのプレイヤーが 5 スキルレベル以内であることを要求します。15 秒間新しいマッチが作成されない場合は、この拡張はスキルレベルの差 10 を探し、10 秒後に 20 の差を探します。

"expansions": [{
        "target": "rules[SkillDelta].maxDistance",
        "steps": [{
            "waitTimeSeconds": 15,
            "value": 10
        }, {
            "waitTimeSeconds": 25,
            "value": 20
        }]
    }]

自動バックフィルが有効なマッチメーカーで使用されている場合、プレイヤーカウントの要件を急に緩和しないでください。新しいゲームセッションを起動し、自動バックフィルを開始するには数秒かかります。より良い方法は、自動バックフィルがゲームで開始された後に拡張待機時間を開始することです。拡張タイミングはチームの構成によって異なるため、ゲームに最適な拡張戦略を見つけるためにテストを実施します。