기술 자료

Development

User Acquisition

Monetization

산업 분야

Multiplayer Services SDK

All Services

Multiplayer Services SDK

이 페이지는 선택한 언어로 제공되지 않습니다.
Multiplayer
​
​
Multiplayer Services SDK
  • Overview
  • Get started
  • Use multiplayer sessions
  • Manage sessions
  • Connect players through a relay
  • Networking
  • Matchmaking
    • Get started with matchmaking
      • Matchmaking ticket flow
      • Authentication
      • Matchmaking rate limits
      • Queues and pools
      • Matchmaker hosting providers
    • Manage and configure matchmaking
    • Matchmaker troubleshooting
    • Integrations with other UGS services
    • Deploy Matchmaker configurations
  • Monitor and debug sessions
  • Tutorials
  • Reference
  1. Multiplayer Services SDK

Queues and pools

Control how matchmaking tickets are grouped, filtered, and matched in your game with queues and pools.
읽는 시간 3분
최근 업데이트: 15일 전

Queues and pools are important components for customizing matchmaking in your game. Queues let you separate tickets by game mode or ruleset, while pools provide an additional level of filtering within a queue, so you can target specific platforms, regions, or other player attributes.

Queues

A queue contains a mutually exclusive set of tickets that you can match together. Tickets in a queue are not matched with tickets found in another queue. This behavior is useful when building a game with discrete game modes that don't overlap, such as Team Deathmatch, Free-For-All, and Capture the Flag, or where the type of game is different, such as a competitive game with ranked and unranked modes.

Default queue

The default queue serves as a fallback queue if the ticket created doesn't specify the name of the queue. This fallback method allows you to dynamically switch to the default queue after the game goes live without changing the game client.
This ability to fall back to the default queue also supports legacy versions of Matchmaker where the game clients do not specify queue names. Therefore you do not need to update your game client to include a queue name when migrating your services.

Pools

A pool represents a dynamic separation of tickets within a queue. Pools contain filters that indicate which tickets the pool processes. The matchmaker assigns tickets that don't match the filters of a pool to a subsequent pool. If the ticket isn't compatible with any of the pools, it uses the default pool of that queue.
For each pool, it's possible to specify hosting information, and the matchmaking logic to use when building matches with the tickets within the pool.
You can separate pools by platform by using filters to target the specific platforms, such as a console or Windows. You can also use pools to target regions, such as North America, the European Union, or Asia.

Default pool

Similarly to queues, the default pool serves as a fallback to make sure you can still process tickets that aren't compatible with any other pool. For example, if you have pools for each region, the default pool is used to put players in a fallback region.

Filters

Filters are a way for pools to decide which tickets to process based on attribute values. You can add custom values under the
Attributes
section when you create a matchmaking ticket in your game client code.
The matchmaker supports two types of attribute values:
text
and
numbers
. Filters themselves can also be of the following two types:
  • The
    Comparator
    type supports the four basic logical operations:
    =
    ,
    !=
    ,
    <
    , and
    >
    .
  • The
    CEL
    type lets you write your own boolean expression. Refer to Language Definition (Google) for the full definition of the CEL language.
Note the following rules:
  • All filters are case sensitive.
  • If a pool contains multiple filters, all filters must pass in order for a ticket to be accepted in this pool. The more flexible
    CEL
    filter type can be used to accept tickets with only a partial match.
  • The
    Comparator
    filter type infers the
    text
    value type for you.
    CEL
    doesn't. Don't forget quotation marks to denote a literal
    text
    value when using
    CEL
    .
  • The
    CEL
    language can be quite powerful, but ticket attributes are still limited to the key-value type, and values can only be
    text
    or
    numbers
    .

Examples of filters

The following table demonstrates how to use each type of filter:

Type

Field

Operator

Value

Description

Comparatorplatform=windowsThe platform attribute in the tickets must be equal to `windows`.
CELn/an/aplatform == "windows" || platform == "ps5"The platform attribute in the tickets must be equal to either
windows
or
ps5
.

Ticket attributes

The following code snippets show how to declare ticket attributes in C# or JSON.
var attributes = new Dictionary<string, object>{ { "platform", "windows" }, { "playerRating", 1500 }};
"attributes": [ { "platform": "windows", "playerRating": 1500 }]

Copyright © 2026 Unity Technologies
법률 정보개인정보 처리방침쿠키Documentation Terms of Use개인 정보 판매 또는 공유 금지개인정보 보호 선택(쿠키 설정)

'Unity', Unity 로고 및 기타 Unity 상표는 미국 및 기타 지역 내 Unity Technologies 또는 그 계열사의 상표 또는 등록상표입니다(자세한 내용은 여기에서 확인하세요). 기타 명칭 또는 브랜드는 해당 소유자의 상표입니다.

일부 페이지는 편의를 위해 기계 번역되었으며 부정확한 내용이 있을 수 있습니다. 정보가 상충되는 경우, 영어 버전을 우선으로 참조하세요.

  • 보고 있는 페이지
    • Queues

      • Default queue

    • Pools

      • Default pool

      • Filters

        • Examples of filters

        • Ticket attributes


이 페이지의 문제 보고
​
​