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

Last updated on July 14, 2026

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

Overview

マッチルールセットは、AccelByte Gaming Services (AGS) Matchmaking がマッチチケットをいつ、どのようにペアリングするかを判断するために使用するロジックを定義します。ルールセットに関連する主な用語は以下のとおりです。

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

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

Goals

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

AGS Admin Portal でルールセットを設定する方法。
ルールセットの一部として有効にできる、さまざまな種類の動作。
定義した動作のフレキシングを有効にして、プレイヤーが長い待ち行列で待たされることを防ぐ方法。

Prerequisites

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

AGS Lobby、Matchmaking、および Session についての知識。
AGS Admin Portal へのアクセス権。
このルールセット用に作成・設定済みのセッションテンプレート。
スキルベースのマッチメイキング用に設定済みの AGS Statistics。

Team-based matchmaking

チームベースのマッチメイキングを設定するには、以下の例のように、マッチの対象となるチーム数とチームごとのプレイヤー数を 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: マッチ中にチームに参加できる最大プレイヤー数を指定します。

Rule flexing for teams

マッチを開始するために必要な最小プレイヤー数が確保できない場合、ルールフレキシングを設定することで、より少ないプレイヤー数でもマッチを開始できるようにすることができます。以下の設定例では、マッチチケットが待ち行列に入ってから 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: マッチ中に参加できる、更新後の最大プレイヤー数を指定します。

Skill-based matchmaking

スキルベースのマッチングを設定するには、プレイヤーのスキルを表す指標を追跡するために AGS Statistics を設定する必要があります。統計情報が定義されると、それを使用してプレイヤー間の差を比較し、マッチさせるべきかどうかを判断できます。以下の設定例では、5 人ずつの 2 チームで構成されるマッチにおいて、プレイヤー間で許容されるマッチメイキングレーティング (MMR) の差を ±200 に指定しています。

注記

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: 統計属性の最大値を指定します。これはマッチングおよびリバランス処理で使用されます。

Rule flexing for statistics

指定した範囲内の統計値を持つプレイヤーが十分に見つからない場合、ルールフレキシングを設定することで、より大きな差でもプレイヤーをマッチさせることができます。以下の設定例では、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 まで拡大してマッチします。

Bidirectional matching

マッチメイキングは双方向です。マッチが成立するには、両方のチケットが同時にお互いの許容範囲内に収まる必要があります。マッチが提案されるのは、プレイヤー A の現在の検索範囲がプレイヤー B の統計値を含み、かつ同時にプレイヤー B の現在の検索範囲がプレイヤー A の統計値を含んでいる場合のみです。

例: 上記の設定を使用し、プレイヤー A の MMR が 700、プレイヤー B の MMR が 200 だとします。開始時点（差 200）では両者はマッチせず、マッチが成立しないままチケットのフレキシングが続きます。

15 秒後（差 300）: プレイヤー A の範囲は 400〜1000、プレイヤー B の範囲は 0〜500 です。プレイヤー B（200）はプレイヤー A の下限（400）より低いため、マッチしません。
30 秒後（差 400）: プレイヤー A の範囲は 300〜1100、プレイヤー B の範囲は 0〜600 です。プレイヤー B（200）は依然としてプレイヤー A の下限（300）より低いため、マッチしません。
45 秒後（差 500）: プレイヤー A の範囲は 200〜1200、プレイヤー B の範囲は 0〜700 です。プレイヤー B（200）はプレイヤー A の範囲内に収まり、かつプレイヤー A（700）もプレイヤー B の範囲内に収まるため、マッチが提案されます。

この双方向設計は、ランクの低いプレイヤーが自身の許容範囲外のマッチに引き込まれることを防ぎ、すべてのプレイヤーにとってより公平なマッチを実現するためのものです。トレードオフとして、ランクの高いプレイヤーはマッチが見つかるまでに時間がかかる場合があります。ランクの高いプレイヤーの待機時間を短縮したい場合は、カスタム MMR アルゴリズムを使用して MMR の分布を調整することを検討してください。例として extend-mmr-calculator を参照してください。

Custom parameter matchmaking

場合によっては、マッチングの基準として使用するプレイヤーの希望を含むカスタムパラメーターを、ゲームクライアントからマッチリクエストの一部として渡せるようにすることが望ましいことがあります。例としては、マップの選択、言語、クロスプレイに参加するかどうかなどがあります。以下の設定例では、両方のプレイヤーが希望するマップとして少なくとも 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: プレイヤーは同じオプションパラメーター名を持つが、異なる値を持つ他のプレイヤーとマッチする必要があることを示します。

Add custom parameters to the matchmaking request in the game client

ゲームクライアントからカスタムパラメーターを渡すには、プレイヤーが自分の希望を選択できる仕組みを実装し、それをマッチリクエストの一部として渡せるようにする必要があります。その後、以下の例を使用して、それらの希望をリクエストに含めるカスタムパラメーターとして追加する実装ができます。

注記

パラメーターに指定する名前は、マッチルールセットの 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
});

More on backfill

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

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

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

もう 1 つ重要なフローとして、マッチプール設定における Auto-accept Backfill Proposal の影響について理解しておく必要があります。ルールセットの最小プレイヤー数が 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 が無効な場合、マッチメイキングはゲームセッション A に再びバックフィルする前に、プレイヤー 1、2 が DS（専用サーバー）に受け入れられるのを待つ可能性があるため、プレイヤー 3、4 はゲームセッション 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 がセッション属性を更新していくつかの値を追加します。

Session data

...
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」設定のみを参照してマッチするプレイヤーを検索するようにできます。

Updated ruleset

{
    "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 がゲームセッションデータにいくつかの追加属性を加えていた場合でも、プレイヤーはゲームセッションにバックフィルされることができます。

Region expansion ruleset

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

{
    "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 を超えるレイテンシを持つプレイヤーはマッチできないことを意味します。

Bidirectional region or latency match

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

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 つのチケットのサンプルシナリオを以下に示します。

Tickets:
- player 1 latencies: us-east-1: 50ms, us-east-2: 50ms, us-west-2: 80ms, eu-west-1: 100ms, eu-central-1: 102ms, ap-southeast-1: 200ms
- player 2 latencies: us-east-1: 150ms, us-east-2: 100ms, us-west-2: 122ms, eu-west-1: 30ms, eu-central-1: 55ms, ap-southeast-1: 200ms

Ruleset:

{
    "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 回目の拡張（130 ミリ秒 (ms) の時点）で eu-west-1 と eu-central-1 を検索対象にします。プレイヤー 1 がすでに 110ms まで拡張済みの時点でプレイヤー 2 がマッチチケットを提出した場合、プレイヤー 2 はまだリージョン拡張を行っておらず eu-west-1 リージョン内でのみ検索しているため、プレイヤー 1 とはマッチしません。

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

Rebalance of matched teams with multiple attributes

リバランスは、マッチメイキングが各パーティーをどのチームスロットに配置するかを決定するプロセスです。パーティーは常に一つの単位として移動し、チーム間で分割されることはありません。競技性のあるゲームでは、これによりパーティーを一緒にしたまま、MMR のような全体的なチーム統計値のバランスを取ることができます。リバランスプロセスの詳細については、マッチメイキングのリバランスのトピックを参照してください。

注記

distance マッチングルールがなくても、リバランスを有効にするとチーム構成には影響します。リバランスアルゴリズムはチーム間のプレイヤー数の分布も最適化するため、サイズの異なるパーティーを公平に配分する必要がある場合に重要になります。

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

{
    "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
        },
    ]
}

Matchmaking reserved keys

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

{
    "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 です。

警告

上記の予約キーを他の目的で使用しないでください。使用すると、新しいマッチやバックフィル処理で予期しない動作が発生する可能性があります。

Matchmaking weight calculation

マッチメイキング処理では、1 つのチケットがピボットチケットとして選択され、それが互換性のあるチケット（候補チケットと呼ばれる）を検索します。各候補チケットには、ピボットチケットからの距離を表すスコアが付与されます。このスコアは、各マッチメイキングルールについてピボットと候補の間の距離を合計することで計算されます。すべての候補チケットのスコアが算出されると、それらはソートされ、ピボットチケットはスコアの低いものから順にマッチを試みます。

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

Latency
distance 基準を使用する matching_rule

あるルールを他のルールより優先したい場合、例えばレイテンシを最小化することがマッチメイキングにおいて最も重要な要素であると判断した場合、チケットのレイテンシと matching_rule の属性の重みを以下のように設定することでこれを実現できます。

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

レイテンシルールとマッチルールの両方における重みのデフォルト値は 1 で、これはそれらのルールが等しく優先されることを意味します。重みの範囲は 0〜1000 で、値が高いほどマッチメイキングプロセスにおいてそのルールが重視されます。例えば、レイテンシを低く保つことよりも、似た 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 の差が小さい方のチケットが選ばれます。

Configure rulesets in the Admin Portal

まず、マッチのためにプレイヤーを比較する際にルールセットに使用させたいロジックを決定します。JSON を定義したら、ルールセットの作成に進みます。
AGS Admin Portal で、目的の namespace に移動し、Multiplayer > Matchmaking > Matchmaking Configuration に進みます。
Match Ruleset タブで、+ Create Rulesets をクリックします。Create Match Ruleset ページが表示されます。
Ruleset Name フィールドに、このルールセットの名前を入力します。
Configuration (JSON) フィールドで、本文を希望する JSON に置き換えます。
検証エラーがなければ、Create をクリックします。

Example: Team 8 vs. 8

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

Auto-backfill は無効です。
マッチを開始するには 2 つのチームが必要です。
チームは 2 つを超えることはできません。
マッチを開始するには各チームに少なくとも 4 人のプレイヤーが必要です。
チームごとのプレイヤー数は 8 人を超えることはできません。

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

Example: 4-player co-op with player level and rating matching

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

Auto-backfill は有効です。
これは co-op マッチであるため、チームは 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
        }
    ]
}

Example: 25-player free for all with MMR flexing

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

Auto-backfill は有効です。
これはフリーフォーオールマッチであるため、チームは 1 つのみです。
- 注: プレイヤーが協力していなくても、常に 1 つの基盤となるチームが必要です。
マッチを開始するには 25 人のプレイヤーが必要です。
マッチメイキングは、ピボットプレイヤーとマッチメイキングレーティング (MMR) 差 200 以内の 25 人のプレイヤーを見つけようとします。
15 秒経過しても 25 人がマッチしていない場合、マッチメイキングはピボットプレイヤーと MMR 差 300 以内の追加プレイヤーを見つけようとします。
30 秒経過しても 25 人がマッチしていない場合、マッチメイキングはピボットプレイヤーと MMR 差 400 以内の追加プレイヤーを見つけようとします。
45 秒経過しても 25 人がマッチしていない場合、マッチメイキングはピボットプレイヤーと MMR 差 500 以内の追加プレイヤーを見つけようとします。

{
    "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
        }
    ]
}

Example: Team 4 vs 4 with crossplay preference validation

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

Auto-backfill は無効です。
マッチを開始するには 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"
            }
        ]
    }
}

Overview​

Goals​

Prerequisites​

Team-based matchmaking​

Rule flexing for teams​

Skill-based matchmaking​

Rule flexing for statistics​

Bidirectional matching​

Custom parameter matchmaking​

Add custom parameters to the matchmaking request in the game client​

More on backfill​

Region expansion ruleset​

Bidirectional region or latency match​

Rebalance of matched teams with multiple attributes​

Matchmaking reserved keys​

Matchmaking weight calculation​

Configure rulesets in the Admin Portal​

Example: Team 8 vs. 8​

Example: 4-player co-op with player level and rating matching​

Example: 25-player free for all with MMR flexing​

Example: Team 4 vs 4 with crossplay preference validation​

Overview

Goals

Prerequisites

Team-based matchmaking

Rule flexing for teams

Skill-based matchmaking

Rule flexing for statistics

Bidirectional matching

Custom parameter matchmaking

Add custom parameters to the matchmaking request in the game client

More on backfill

Region expansion ruleset

Bidirectional region or latency match

Rebalance of matched teams with multiple attributes

Matchmaking reserved keys

Matchmaking weight calculation

Configure rulesets in the Admin Portal

Example: Team 8 vs. 8

Example: 4-player co-op with player level and rating matching

Example: 25-player free for all with MMR flexing

Example: Team 4 vs 4 with crossplay preference validation