マッチルールセットを設定する

Last updated on February 4, 2026

注釈：本資料はAI技術を用いて翻訳されています。

概要

マッチルールセットは、AccelByte Gaming Services（AGS）マッチメイキングがマッチチケットをペアリングできるかどうか、またいつペアリングするかを決定するために使用するロジックを定義します。ルールセットに関連する主要な用語は次のとおりです。

属性（Attributes）: 統計とも呼ばれ、マッチメイキングレーティング（MMR）などの数値で、チケットを比較して一緒にマッチングすべきかどうかを判断するために使用できます。これらの値は、マッチメイキング中に使用するためにAGS 統計に保存する必要があります。
カスタムパラメータ（Custom Parameters）: マップ、言語、クロスプレイのプレイヤー設定など、マッチリクエストの一部としてゲームクライアントからAGSマッチメイキングに渡されるプレイヤーの設定を表すキーと値のペアです。
ルールフレキシング（Rule Flexing）: 設定されたルールが時間の経過とともに緩和されるプロセスです。ルールフレキシングを設定することで、プレイヤーが長いキュー時間を経験するのを防ぐことができます。

この記事では、プレイヤー間のチームベース、スキルベース、カスタムパラメータマッチングを有効にするルールの設定方法を説明します。また、プレイヤートラフィックが少ない場合やプレイヤー間のスキル差が大きい場合に待ち時間を短縮するために、これらのルールを時間の経過とともにフレックスする方法も示します。

目標

このページでは、マッチルールセットの概要と以下の内容についての理解を提供します。

AGS Admin Portalでのルールセットの設定
ルールセットの一部として有効にできるさまざまなタイプの動作
プレイヤーが長いキューで待機するのを防ぐために、定義された動作をフレックスする方法

前提条件

この記事のすべての手順を完了するには、以下が必要です。

AGS Lobby、Matchmaking、Sessionに関する知識
AGS Admin Portalへのアクセス
このルールセット用に作成および設定されたセッションテンプレート
スキルベースマッチメイキング用に設定されたAGS Statistics

チームベースマッチメイキング

チームベースマッチメイキングを設定するには、以下の例に示すように、マッチで対象とするチーム数とチームごとのプレイヤー数をJSONで定義する必要があります。以下の設定例では、マッチを開始するために2つのチームが必要であり、ゲーム内に5人以上のプレイヤーが必要であることを指定しています。

注記

JSONブロック内のallianceは、評価中に従うチーム構成を定義します。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    }
}

Auto backfill: マッチ（ゲームセッション）が満員になるまで、マッチメイキングがゲームセッション内の空きスポットを自動的にバックフィルすることを指定します。
Min number: マッチを開始するために必要な最小チーム数を指定します。
Max number: マッチに参加できる最大チーム数を指定します。
Player min number: マッチを開始するためにチームごとに必要な最小プレイヤー数を指定します。
Player max number: マッチ中にチームに参加できる最大プレイヤー数を指定します。

チームのルールフレキシング

マッチを開始するために必要な最小プレイヤー数が見つからない場合、ルールフレキシングを設定してより少ないプレイヤーでマッチを開始できるようにすることができます。以下の設定例では、マッチチケットがキューに入ってから60秒後に、チームごとに必要な最小プレイヤー数が5人から3人に減少することを指定しています。

注記

JSONブロック内のalliance_flexing_ruleは、指定された期間後にルールがどのように緩和されるかを定義します。チーム用の追加のフレキシングルールを追加するには、alliance_flexing_rule内にコンマで区切られた独自のブロックとして追加します。

ヒント

AccelByteは、全体的なゲーム体験を向上させるために、アライアンスフレキシングルールの使用を強く推奨します。この最適化により、少数のプレイヤーでゲームをより迅速に開始でき、プレイヤーが別々のロビーに分かれるのではなく、同じセッションでマッチングされる可能性が大幅に向上します。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    },
    "alliance_flexing_rule": [
        {
            "duration": 60,
            "min_number": 2,
            "max_number": 2,
            "player_min_number": 3,
            "player_max_number": 5
        }
    ]
}

Duration: サービスがルールのフレキシングを開始する前に経過する必要がある秒単位の時間を指定します。
Min number: マッチを開始するために必要な更新された最小チーム数を指定します。
Max number: マッチに参加できる更新された最大チーム数を指定します。
Player min number: マッチを開始するためにチームごとに必要な更新された最小プレイヤー数を指定します。
Player max number: マッチ中に参加できる更新された最大プレイヤー数を指定します。

スキルベースマッチメイキング

スキルベースマッチングを設定するには、プレイヤーのスキルを表すメトリクスを追跡するためにAGS Statisticsを設定する必要があります。統計が定義されると、プレイヤー間の距離を比較して、一緒にマッチングする必要があるかどうかを判断するために使用できます。以下の設定例では、マッチには5人のプレイヤーからなる2つのチームが含まれ、プレイヤー間で+/- 200のマッチメイキングレーティング（MMR）の差が許容されることを指定しています。

注記

JSONブロック内のmatching_ruleは、評価中にどの統計が比較されるかを定義します。より多くの統計のための追加ルールを追加するには、matching_rule内にコンマで区切られた独自のブロックとして追加します。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    },
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 200,
            "max": 3000
        }
    ]
}

Attribute: マッチ適合性のためにプレイヤーを比較するために使用される統計を指定します。
Criteria: 統計を比較するために使用される基準を指定します。注意: "distance"は現在サポートされている唯一の基準です。
Reference: 許可される統計間の差を指定します。この例では、プレイヤーはマッチングされるために+/- 200である必要があります。
Max: 統計属性の最大値を指定します。これはマッチングおよびリバランシングプロセスに使用されます。

統計のルールフレキシング

指定された範囲内の統計値を持つプレイヤーが十分にいない場合、ルールフレキシングを設定して、より大きな差でプレイヤーがマッチングできるようにすることができます。以下の設定例では、15秒の待機ごとに許容される差が100ポイント拡大され、最大500ポイントになることを指定しています。

注記

JSONブロック内のflexing_ruleは、指定された期間後にルールがどのように緩和されるかを定義します。統計のための追加のフレキシングルールを追加するには、flexing_rule内にコンマで区切られた独自のブロックとして追加します。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    },
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 200
        }
    ],
    "flexing_rule": [
        {
            "duration": 15,
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 300
        },
        {
            "duration": 30,
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 400
        },
        {
            "duration": 45,
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 500
        }
    ]
}

Duration: サービスがルールのフレキシングを開始する前に経過する必要がある秒単位の時間を指定します。
Attribute: マッチ適合性のためにプレイヤーを比較するために使用される統計を指定します。
Criteria: 統計を比較するために使用される基準を指定します。注意: "distance"は現在サポートされている唯一の基準です。
Reference: 許可される統計間の新しい差を指定します。この例では、時間の経過とともに+/- 500に増加し、マッチングされます。

カスタムパラメータマッチメイキング

場合によっては、マッチング基準として使用されるマッチリクエストの一部として、プレイヤーの設定を含むカスタムパラメータをゲームクライアントが渡せるようにすることが望ましいことがあります。例としては、マップの選択、言語、またはクロスプレイに参加したいかどうかが含まれます。以下の設定例では、両方のプレイヤーがプレイする設定として少なくとも1つの一致するマップを指定した場合にのみマッチングできることを指定しています。

注記

JSONブロック内のmatching_optionsは、ゲームクライアントから渡されたカスタマーパラメータのうち、評価中に使用されるものを定義します。より多くのカスタムパラメータのための追加ルールを追加するには、options内にコンマで区切られた独自のブロックとして追加します。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    },
    "match_options": {
        "options": [
            {
                "name": "map_names",
                "type": "any"
            }
        ]
    }
}

Name: ゲームクライアントから渡されるパラメータの名前（キー）を指定します。
Type: マッチング中にカスタムパラメータをどのように評価するかを指定します。
- All: プレイヤーは同じパラメータと値を持つ他のプレイヤーとマッチングされる必要があることを示します。
- Any: プレイヤーは同じオプションパラメータ名を持ち、少なくとも1つの一致する値を持つ他のプレイヤーとマッチングされる必要があることを示します。
- Unique: プレイヤーは同じオプションパラメータ名を持つが、異なる値を持つ他のプレイヤーとマッチングされる必要があることを示します。

ゲームクライアントのマッチメイキングリクエストにカスタムパラメータを追加する

ゲームクライアントからカスタムパラメータを渡すには、プレイヤーが設定を選択できる方法を実装し、それをマッチリクエストの一部として渡せるようにする必要があります。次に、以下の例を使用して、これらの設定をカスタムパラメータとしてリクエストに含めるように実装できます。

注記

パラメータに指定された名前は、マッチルールセットJSONで設定されているものと一致する必要があります。

OSS
Unreal Engine
Unity

const IOnlineSubsystem* Subsystem = Online::GetSubsystem(GetWorld());
if (!ensure(Subsystem != nullptr))
{
    return;
}

const FOnlineSessionAccelBytePtr SessionInterface = StaticCastSharedPtr<FOnlineSessionV2AccelByte>(Subsystem->GetSessionInterface());
if (!ensure(SessionInterface.IsValid()))
{
    return;
}
const FUniqueNetIdPtr LocalPlayerId = GetUniquePlayerId();
if (!ensure(LocalPlayerId.IsValid()))
{
    return false;
}

// Create a new search handle instance for matchmaking. IMPORTANT: You will need to set the match pool that you are searching for with SETTING_SESSION_MATCHPOOL, as shown below.
TSharedRef<FOnlineSessionSearch> MatchmakingSearchHandle = MakeShared<FOnlineSessionSearch>();
MatchmakingSearchHandle->QuerySettings.Set(SETTING_SESSION_MATCHPOOL, FString(TEXT("YOUR_MATCHPOOL_NAME_GOES_HERE")), EOnlineComparisonOp::Equals);

// Add the map names as values for the custom parameter
MatchmakingSearchHandle->QuerySettings.Set(
    FName(TEXT("map_names")),
    TEXT("map_01"), EOnlineComparisonOp::Equals);

// Bind a function that has a return type of void and these parameters:
// FName SessionName, bool bWasSuccessful
const FOnMatchmakingCompleteDelegate OnMatchmakingCompleteDelegate = /* Bind to lambda or class method */;
SessionInterface->AddOnMatchmakingCompleteDelegate_Handle(OnMatchmakingCompleteDelegate);

if (SessionInterface->StartMatchmaking(USER_ID_TO_MATCHMAKING_USER_ARRAY(LocalPlayerId.ToSharedRef()), NAME_GameSession, FOnlineSessionSettings(), MatchmakingSearchHandle, OnStartMatchmakingCompleteDelegate))
{
    // Update the current search result handle class member with the search handle passed to AGS Matchmaking.
    CurrentMatchmakingSearchHandle = MatchmakingSearchHandle;
}

// Set the matchpool name
FString MatchPoolName = "YOUR_MATCHPOOL_NAME_GOES_HERE";

// Get the default API client to call the AGS backend endpoints
FApiClientPtr ApiClient = AccelByteOnlineSubsystemPtr->GetApiClient();

// Set the optional parameter attributes to save the option selected
FAccelByteModelsV2MatchTicketOptionalParams Optionals;
TSharedPtr<FJsonObject> Attributes = MakeShared<FJsonObject>();

// Add the map names as values for the custom parameter
TArray<TSharedPtr<FJsonValue>> mapValues = {
  MakeShareable(new FJsonValueString(TEXT("map_01")))
};

Attributes->SetArrayField("map_names", CrossPlayValues);
Optionals.Attributes.JsonObject = Attributes;

auto OnSuccess = THandler<FAccelByteModelsV2MatchmakingCreateTicketResponse>::CreateLambda(
  [&](const FAccelByteModelsV2MatchmakingCreateTicketResponse& Result)
{
  // Do something on create ticket success
});
auto OnError = FErrorHandler::CreateLambda([&](int32 Code, const FString& Message)
{
  // Do something on create ticket failure
});

// Request matchmaking with the optional parameter attached to the match ticket.
ApiClient->MatchmakingV2.CreateMatchTicket(MatchPoolName, OnSuccess, OnError, Optionals);

// Get the matchmaking API client to call the AGS backend endpoints
var matchmaking = AccelByteSDK.GetClientRegistry().GetApi().GetMatchmakingV2();

// Set the matchpool name
string matchPoolName = "YOUR_MATCHPOOL_NAME_GOES_HERE";

// Set the optional parameter attributes to save the option selected
MatchmakingV2CreateTicketRequestOptionalParams Optionals = new MatchmakingV2CreateTicketRequestOptionalParams();

// Add the map names as values for the custom parameter
Optionals.attributes = new Dictionary<string, object>()
{
    { "map_names", "map_01" }
};

// Request matchmaking with the optional parameter attached to the match ticket.
matchmaking.CreateMatchmakingTicket(matchPoolName, Optionals, result => 
{
    if (result.IsError)
    {
        // Do something if CreateMatchmakingTicket has an error
        Debug.Log($"Error CreateMatchmakingTicket, Error Code: {result.Error.Code} Error Message: {result.Error.Message}");
        return;
    }

    // Do something if CreateMatchmakingTicket has been successful
});

バックフィルの詳細

マッチメイキングのバックフィルプロセスは、特にプレイヤーがゲーム途中で退出または切断した場合や、ゲームセッションが満員でない状態で作成された場合に、オンラインマルチプレイヤーゲームでバランスの取れた公平なプレイヤーマッチアップを維持するように設計されています。デフォルトでは、マッチメイキングは新しいマッチ（ゲームセッション）を作成する前に、まだ空きスロットがあるセッションのバックフィルを優先します。

現在、最小プレイヤー数を必要とするルールセットがあり、セッションがその数を下回った場合（つまり、プレイヤーが退出したため）、バックフィルチケットは、セッションを最小プレイヤー制限（min_number * player_min_number）まで埋めるのに十分なプレイヤーが見つかるまでマッチングされません。例えば、最低2チームとチームごとに3人のプレイヤーを必要とするアライアンスルールを持つルールセットを設定しているとします。6人未満のプレイヤーでは新しいマッチは作成されません。6人のプレイヤーでマッチが成立し、DSが起動します。その後、4人がマッチから退出し、DSはセッションのためにより多くのプレイヤーを見つけるためにバックフィルチケットを作成します。マッチメイキングは、ゲームに誰かを追加する前に、4人の互換性のあるプレイヤーが到着するまで待機します。

マッチルールセットでauto_backfill: trueを指定すると、マッチメイキングプロセスから作成されたすべてのマッチ（ゲームセッション）がバックフィル可能としてマークされます。ゲームセッションが満員になった後、セッションが満員になった後にプレイヤーが残っている場合でも、その特定のセッションのバックフィル提案は停止されます。専用ゲームサーバー（DS）は、ゲームセッションでバックフィルチケットを作成または削除することにより、バックフィルステータスを手動で制御することもできます。ゲーム管理者は、いくつかのケースでマニュアルバックフィルを利用できます。たとえば、すべての新しいマッチをセッション内の全プレイヤーで形成したい場合、プレイヤーが1分前にセッションを退出したときにのみゲームセッションへのバックフィルを有効にできます。バックフィルチケットの管理の詳細については、このセクションを参照してください。

matchpools configurationにおけるAuto-accept Backfill Proposalの影響を理解するためのもう1つの重要なフローがあります。ルールセットの最小プレイヤー数が1で、最大プレイヤー数が10であると仮定します。ゲームセッションAが最初に4人のプレイヤーで作成されたとします。その場合、Auto-accept Backfill Proposalが有効になっていると、マッチメイキングは各マッチメイキングティックでキュー内のプレイヤーをセッションに直接バックフィルしようとします。例えば：

ティック1: プレイヤー1と2がマッチメイキングキューに入る
ティック2: プレイヤー3と4がマッチメイキングキューに入る
ティック3: プレイヤー5と6がマッチメイキングキューに入る Auto-accept Backfill Proposalが有効な場合、プレイヤー1〜6のすべてがゲームセッションAにバックフィルされます。 Auto-accept Backfill Proposalが無効な場合、プレイヤー3と4は、マッチメイキングがゲームセッションAを再びバックフィルする前にプレイヤー1と2がDS（専用サーバー）によって受け入れられるのを待つ可能性があるため、ゲームセッションAにバックフィルされない可能性があります。

デフォルトでは、マッチメイキングは、バックフィルチケットが作成されたときにゲームセッション内の属性とリージョンを使用して、バックフィルされるマッチングプレイヤーを探します。ただし、ゲームプレイ中にゲームセッション属性がDSによって変更/更新される場合があります。セッション属性の更新後にDSがバックフィルチケットを再作成すると、最新の属性がマッチングプレイヤーを探すために使用されるため、バックフィルフローに影響を与えます。たとえば、マッチメイキングチケットに次のように"start_map"属性が含まれているとします。

Match Ticket

{
  "attributes": {
    "start_map": "City_Center" 
  },
  "latencies": {
    "us-west-2":44,
    "eu-west-2":187,
    "ap-northeast-1":600
  },
  "matchPool": "matchpool_test",
  "sessionID": ""
}

Ruleset

{
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    },
    "match_options": {
        "options": [
            {
                "name": "start_map",
                "type": "all"
            }
        ]
    }
}

マッチメイキングチケットにはattributes値が含まれているため、常にゲームセッション属性に含まれます。マッチが開始された後、DSはセッション属性を更新していくつかの値を含めます。

セッションデータ

...
attributes: {
    "start_map": "City_Center",
    "experience_booster": "normal",
    "difficulty": "normal"
}
...

マッチが開始された直後に、2人のプレイヤーがセッションを退出し、DSがバックフィルを有効にします。この場合、キュー内のマッチングプレイヤーを探すときに、start_map、experience_booster、difficulty属性が考慮されます。マッチチケットにはstart_map属性のみが含まれているため、セッションのために再フィルされるプレイヤーはいません。この問題を回避するために、match_options_referred_for_backfill設定を使用して、マッチメイキングがマッチングプレイヤーを探すために"match_options"設定のみを参照するようにすることができます。

更新されたルールセット

{
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 5,
        "player_max_number": 5
    },
    "match_options": {
        "options": [
            {
                "name": "start_map",
                "type": "all"
            }
        ]
    },
    "match_options_referred_for_backfill": true
}

match_options_referred_for_backfillフラグが有効になっている場合、マッチメイキングはゲームセッション属性に関係なくstart_map属性のみを使用します。したがって、上記の例の場合、DSがゲームセッションデータにいくつかの追加属性を既に追加している場合でも、プレイヤーはゲームセッションにバックフィルできます。

リージョン拡張ルールセット

最高のマッチメイキング体験を提供したいため、マッチメイキングロジックには、レイテンシに基づいてプレイヤーをマッチングする際の厳格なルールがあります。ただし、ゲームのプレイヤーベースが小さい場合があり、自分のリージョンでのみ探している場合はマッチを見つけるのが難しくなります。リージョン拡張ルールセットは、複数のリージョンに分散しているプレイヤーをサポートするゲーム専用です。以下の例では、プレイヤーは自分の設定とゲームが提供するリージョンに基づいてマッチメイキングをリクエストできます。この設定は、プレイヤーのレイテンシに基づいて異なるリージョンのプレイヤーをマッチングするために使用でき、マッチルールセットで設定された値に基づいて時間の経過とともにフレックスします。

{
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 1,
        "player_max_number": 1
    },
    "auto_backfill": false,
    "region_latency_initial_range_ms": 50,
    "region_expansion_range_ms": 50,
    "region_expansion_rate_ms": 10000,
    "region_latency_max_ms": 200
}

region_latency_initial_range_ms: 同じリージョンでマッチングプレイヤーを検索するための初期リージョンレイテンシを指定します。設定されていない場合のデフォルト値は200 msです。
region_expansion_range_ms: 各拡張レートで初期レイテンシに追加されるミリ秒（ms）数を指定します。設定されていない場合のデフォルト値は50です。
region_expansion_rate_ms: 追加のregion_expansion_range_msがマッチメイキングチケットに追加されるmsレートを指定します。拡張レートが設定されていない場合、レイテンシはマッチメイキングティックごとに拡張されます。
region_latency_max_ms: リージョン拡張の最大レイテンシを指定します。この設定が指定されていない場合、最大レイテンシ拡張制限はありません。

上記のマッチルールセットの例は次のように機能します。

"region_latency_initial_range_ms": 50は以下を意味します。
- プレイヤーのレイテンシが50 ms未満の場合、チケット検索を拡張する必要はありません。たとえば、2人のプレイヤーがそれぞれ50 ms未満の場合、すぐに互いにマッチングされます。
- プレイヤーのレイテンシが50 msを超える場合、チケット検索はプレイヤーのレイテンシに応じて拡張されます。たとえば、2人のプレイヤーがそれぞれ90 msのレイテンシを持っている場合、互いにマッチングされるには10秒（最初の検索拡張）待つ必要があります。
"region_expansion_rate_ms": 10000は、10000 ms（10秒）ごとにチケット検索が拡張されることを意味します。
"region_expansion_range_ms": 50は、チケット検索が拡張されたとき（この例では10秒ごと）、レイテンシが50 ms増加することを意味します。
"region_latency_max_ms": 200は、200を超えるレイテンシを持つプレイヤーはマッチングできないことを意味します。

双方向リージョンまたはレイテンシマッチ

マッチングプレイヤー候補（マッチチケット）をフィルタリングする際、マッチメイキングは各プレイヤーのマッチチケットの経過時間に基づいてリージョン拡張ロジックを適用します。マッチの検索では、ピボットプレイヤー（マッチチケット）と同じリージョンを持つ候補プレイヤー、またはピボットプレイヤーと同じリージョンに既に拡張している候補プレイヤーのみが許可されます。

For each {region} in [pivot player's regions]
  For each candidate tickets:
    apply region expansion logic based on candidate ticket's age
    include candidate ticket only if it has expanded to {region}

特定のルールセットを持つ2つのチケットのサンプルシナリオは次のとおりです。

チケット:
- プレイヤー1のレイテンシ: us-east-1: 50ms, us-east-2: 50ms, us-west-2: 80ms, eu-west-1: 100ms, eu-central-1: 102ms, ap-southeast-1: 200ms
- プレイヤー2のレイテンシ: us-east-1: 150ms, us-east-2: 100ms, us-west-2: 122ms, eu-west-1: 30ms, eu-central-1: 55ms, ap-southeast-1: 200ms

ルールセット:

{
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 1,
        "player_max_number": 1
    },
    "auto_backfill": false,
    "region_latency_initial_range_ms": 30,
    "region_expansion_range_ms": 50,
    "region_expansion_rate_ms": 10000,
    "region_latency_max_ms": 350
}

マッチメイキングが10秒ごとにティックするように設定されており、プレイヤー1がピボットであると仮定します。プレイヤー1は、3回目の拡張でeu-west-1とeu-central-1を検索します。これは130ミリ秒（ms）です。プレイヤー1が既に110msに拡張しているときにプレイヤー2がマッチチケットを送信した場合、プレイヤー2はまだリージョン拡張に達しておらず、eu-west-1リージョン内で検索しているため、プレイヤー1とマッチングされません。

ただし、ある時点で、古すぎるチケットが双方向性をスキップして、その拡張範囲内のチケットとマッチを見つけることを許可したい場合があります。これを行うには、ルールセットでdisable_bidirectional_latency_after_ms（ミリ秒単位）オプションを使用できます。デフォルトでは無効（0または負）になっており、常に双方向性に従うことを意味します。ただし、設定されている場合、disable_bidirectional_latency_after_msよりも古いピボットチケットは、候補チケットのフィルタリングステップをスキップします。

複数の属性を持つマッチングチームのリバランス

リバランスは、マッチメイキングが既に一緒にマッチングされたプレイヤーをバランスの取れたチームに配置するプロセスです。競技ゲームでは、ゲームプレイが公平であり、マッチチーム間で全体的なMMRが類似していることを確認するために、リバランスプロセスが重要です。リバランスプロセスの詳細については、matchmaking rebalanceトピックを参照してください。

デフォルトでは、リバランスプロセスに使用される属性は、マッチングルールの最初の設定です。例えば：

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 1,
        "max_number": 1,
        "player_min_number": 25,
        "player_max_number": 25
    },
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 200
        },
        {
            "attribute": "elo",
            "criteria": "distance",
            "reference": 100
        },
    ]
}

上記のサンプルルールセットでは、属性mmrのみがリバランスプロセスに使用されます。ただし、isForBalancingフラグを使用して、リバランスプロセスで両方の属性を考慮するように設定できます。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 1,
        "max_number": 1,
        "player_min_number": 25,
        "player_max_number": 25
    },
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 200,
            "isForBalancing": true
        },
        {
            "attribute": "elo",
            "criteria": "distance",
            "reference": 100,
            "isForBalancing": true
        },
    ]
}

AccelByteは、matching rule設定で使用されるstatisticコードに対してnormalizationMax値を定義することを推奨しています。これにより、マッチメイキングサービスが統計の値を正規化でき、マッチングおよびチームバランシングプロセス中に統計ルール全体でより良い優先順位付けと重み付けが可能になります。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 1,
        "max_number": 1,
        "player_min_number": 25,
        "player_max_number": 25
    },
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 200,
            "normalizationMax": 2000,
            "isForBalancing": true
        },
        {
            "attribute": "elo",
            "criteria": "distance",
            "reference": 100,
            "normalizationMax": 3000,
            "isForBalancing": true
        },
    ]
}

マッチメイキング予約キー

AGSマッチメイキングには、ゲームクライアントがマッチメイキングリクエスト（チケット）を送信するときに使用できるいくつかの予約キーがあります。基本的なマッチメイキングチケットの構造は以下のとおりです。

{
    "sessionId": "string", // OPTIONAL - the party/game session ID that is being used for matchmaking
    "matchPool": "string", // REQUIRED - the matchpool name that will be used for matchmaking
    "latencies": "string", // OPTIONAL - the player latencies to the datacenter. It is the result for QoS call if you are using Accelbyte Multiplayer Server (AMS)
    "attributes": {}, // OPTIONAL - any matchmaking attributes from the game client to be considered for the matchmaking and backfill process
}

ゲームクライアントは、マッチメイキングチケット内に任意のattributesデータを設定できます。このデータは、マッチングプレイヤーの候補とバックフィルプロセス用のオープンセッションを検索するために使用されます。マッチメイキングチケットのすべての属性は、デフォルトでゲームセッション属性に含まれます。ただし、ゲームセッションに含まれないattributesオブジェクト内に設定できる予約キーがいくつかあります。attributesオブジェクト内の予約キーのリストは次のとおりです。

client_version: "string" - この属性は、マッチメイキングに使用されるゲームバージョンまたは専用ゲームサーバーバージョンを参照します。Accelbyte Multiplayer Servers（AMS）と統合し、client_version値が設定されている場合、ゲームセッションは、client_version値と同じクレームキーを持つ開発フリートから専用サーバーを最初にリクエストします。
server_name: "string": 専用サーバー管理にAMSを使用している場合のローカル専用サーバー名。
role: - ロールベースマッチメイキングのプレイヤーのロール設定を指定します。
cross_platform: "string" - プレイヤーの現在のプラットフォーム値。詳細については、クロスプレイマッチメイキングを参照してください。
current_platform: [] - プレイヤーがマッチングしたいプラットフォームのリスト。詳細については、クロスプレイマッチメイキングを参照してください。
new_session_only: boolean - プレイヤーがバックフィルされるのをスキップして、新しいセッションのみを開始したいかどうかを指定します。デフォルト値はfalseです。

警告

上記の予約キーを他の目的で使用しないでください。そうしないと、新しいマッチとバックフィルプロセスが予期しない動作を引き起こす可能性があります。

マッチメイキング重み計算

マッチメイキングプロセスでは、1つのチケットがピボットチケットとして選択され、候補チケットと呼ばれる互換性のあるチケットを検索します。各候補チケットには、ピボットチケットからの距離を表すスコアが与えられます。このスコアは、各マッチメイキングルールについて、ピボットと候補の間の距離を合計することによって計算されます。すべての候補チケットがスコア付けされると、それらはソートされ、ピボットチケットは最も低いスコアのものから最初にマッチングしようとします。

現在スコアリングをサポートしているマッチメイキングルールは次のとおりです。

レイテンシ
distance基準を使用するmatching_rule

あるルールを別のルールよりも優先したい場合、たとえば、レイテンシを最小化することがマッチメイキングの最も重要な側面であると決定した場合、次のようにチケットレイテンシとmatching_rule属性の重みを設定してこれを許可できます。

latency: region_latency_rule_weight - オプション、デフォルト値は1、範囲0〜1000。
match rule: weight - オプション、デフォルト値は1、範囲0〜1000。

レイテンシルールとマッチルールの両方の重みのデフォルト値は1です。これは、これらのルールが等しく優先されることを意味します。重みの範囲は0〜1,000で、より高い値がマッチメイキングプロセス中にそのルールにより多くの重要性を与えます。たとえば、類似したMMR値を持つプレイヤーをマッチングすることが、レイテンシを低く保つことの5倍重要である場合は、レイテンシの重みを1に、MMRの重みを5に設定します。

important

重み付けを使用する場合は、ルールにnormalizationMaxを設定し、重みを割り当てるときに予想される正規化された値を考慮してください。

{
    ...
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 500,
            "normalizationMax": 3000,
            "weight": 5
        }
    ],
    "region_latency_max_ms": 200,
    "region_latency_rule_weight": 1,
    ...
}

2つのマッチングチケットのMMRとレイテンシの間に類似したデルタがある場合、MMRがレイテンシよりも高い重みを持つため、デルタMMRが低いチケットが選択されます。

Admin Portalでルールセットを設定する

まず、マッチのためにプレイヤーを比較するときにルールセットが使用する必要がある目的のロジックを決定します。JSONが定義されたら、ルールセットの作成を続行します。
AGS Admin Portalで、目的のネームスペースに移動し、Multiplayer > Matchmaking > Matchmaking Configurationに移動します。
Match Rulesetタブで、+ Create Rulesetsをクリックします。Create Match Rulesetページが表示されます。
Ruleset Nameフィールドに、このルールセットの名前を入力します。
**Configuration (JSON)**フィールドで、本文を目的のJSONに置き換えます。
検証エラーがない場合は、Createをクリックします。

例: チーム8対8

この例では、JSONは以下の基準でマッチメイキングを機能するように設定します。

オートバックフィルは無効です。
マッチを開始する前に2つのチームが必要です。
2つ以上のチームは存在できません。
マッチを開始する前に各チームに少なくとも4人のプレイヤーが必要です。
チームごとに8人以上のプレイヤーは存在できません。

{
    "auto_backfill": false,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 4,
        "player_max_number": 8
    }
}

例: プレイヤーレベルとレーティングマッチングを使用した4人協力プレイ

この例では、JSONは以下の基準でマッチメイキングを機能するように設定します。

オートバックフィルは有効です。
これは協力プレイマッチであるため、チームは1つのみです。
マッチを開始する前に4人のプレイヤーが必要です。
マッチメイキングは、ピボットプレイヤーの2レベル以内および20レーティングポイント以内の4人のプレイヤーを見つけようとします。
- この例では、"rating"は、プレイヤーが一緒にプレイした他のプレイヤーに応じたプレイヤーのレーティングを指定します。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 1,
        "max_number": 1,
        "player_min_number": 4,
        "player_max_number": 4
    },
    "matching_rule": [
        {
            "attribute": "level",
            "criteria": "distance",
            "reference": 2
        },
        {
            "attribute": "rating",
            "criteria": "distance",
            "reference": 20
        }
    ]
}

例: MMRフレキシングを使用した25人フリーフォーオール

この例では、JSONは以下の基準でマッチメイキングを機能するように設定します。

オートバックフィルは有効です。
これはフリーフォーオールマッチであるため、チームは1つのみです。
- 注意: プレイヤーが一緒に作業していない場合でも、常に1つの基礎となるチームが必要です。
マッチを開始する前に25人のプレイヤーが必要です。
マッチメイキングは、ピボットプレイヤーの200マッチメイキングレーティング（MMR）以内の25人のプレイヤーを見つけようとします。
15秒後に25人のプレイヤーがマッチングされていない場合、マッチメイキングはピボットプレイヤーの300 MMR以内の追加のプレイヤーを見つけようとします。
30秒後に25人のプレイヤーがマッチングされていない場合、マッチメイキングはピボットプレイヤーの400 MMR以内の追加のプレイヤーを見つけようとします。
45秒後に25人のプレイヤーがマッチングされていない場合、マッチメイキングはピボットプレイヤーの500 MMR以内の追加のプレイヤーを見つけようとします。

{
    "auto_backfill": true,
    "alliance": {
        "min_number": 1,
        "max_number": 1,
        "player_min_number": 25,
        "player_max_number": 25
    },
    "matching_rule": [
        {
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 200
        }
    ],
    "flexing_rule": [
        {
            "duration": 15,
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 300
        },
        {
            "duration": 30,
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 400
        },
        {
            "duration": 45,
            "attribute": "mmr",
            "criteria": "distance",
            "reference": 500
        }
    ]
}

例: クロスプレイ設定検証を使用したチーム4対4

この例では、JSONは以下の基準でマッチメイキングを機能するように設定します。

オートバックフィルは無効です。
マッチを開始する前に2つのチームが必要です。
2つ以上のチームは存在できません。
マッチを開始する前に各チームに少なくとも4人のプレイヤーが必要です。
チームごとに4人以上のプレイヤーは存在できません。
同じプラットフォームでクロスプレイを選択したプレイヤーのみがマッチングされます。

{
    "auto_backfill": false,
    "alliance": {
        "min_number": 2,
        "max_number": 2,
        "player_min_number": 4,
        "player_max_number": 4
    },
    "match_options": {
        "options": [
            {
                "name": "cross_platform",
                "type": "all"
            }
        ]
    }
}

概要​

目標​

前提条件​

チームベースマッチメイキング​

チームのルールフレキシング​

スキルベースマッチメイキング​

統計のルールフレキシング​

カスタムパラメータマッチメイキング​

ゲームクライアントのマッチメイキングリクエストにカスタムパラメータを追加する​

バックフィルの詳細​

リージョン拡張ルールセット​

双方向リージョンまたはレイテンシマッチ​

複数の属性を持つマッチングチームのリバランス​

マッチメイキング予約キー​

マッチメイキング重み計算​

Admin Portalでルールセットを設定する​

例: チーム8対8​

例: プレイヤーレベルとレーティングマッチングを使用した4人協力プレイ​

例: MMRフレキシングを使用した25人フリーフォーオール​

例: クロスプレイ設定検証を使用したチーム4対4​

概要

目標

前提条件

チームベースマッチメイキング

チームのルールフレキシング

スキルベースマッチメイキング

統計のルールフレキシング

カスタムパラメータマッチメイキング

ゲームクライアントのマッチメイキングリクエストにカスタムパラメータを追加する

バックフィルの詳細

リージョン拡張ルールセット

双方向リージョンまたはレイテンシマッチ

複数の属性を持つマッチングチームのリバランス

マッチメイキング予約キー

マッチメイキング重み計算

Admin Portalでルールセットを設定する

例: チーム8対8

例: プレイヤーレベルとレーティングマッチングを使用した4人協力プレイ

例: MMRフレキシングを使用した25人フリーフォーオール

例: クロスプレイ設定検証を使用したチーム4対4