기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon GameLift Servers FlexMatch 매치메이커 빌드
이 섹션에서는 매치메이커의 주요 요소와 게임용 매치메이커를 생성하고 사용자 지정하는 방법을 설명합니다. 여기에는 매치메이킹 구성 및 매치메이킹 규칙 세트 설정이 포함됩니다.
매치메이커 생성은 FlexMatch 로드맵의 첫 번째 단계입니다.
+ [로드맵: Amazon GameLift Servers 호스팅 솔루션에 매치메이킹 추가](match-tasks.md)
+ [로드맵: FlexMatch를 사용하여 독립형 매치메이킹 솔루션 생성](match-tasks-safm.md)
FlexMatch 매치메이커는 게임 매치를 구축하는 작업을 수행합니다. 접수된 매치메이킹 요청 풀을 관리하고, 가능한 최고의 플레이어 그룹을 찾을 수 있도록 플레이어를 처리 및 선택하며, 매치를 위해 팀을 구성합니다. 호스팅에 Amazon GameLift Servers를 사용하는 게임의 경우 매치를 위한 게임 세션도 배치하고 시작합니다.
FlexMatch는 매치메이킹 서비스를 사용자 지정 가능한 규칙 엔진과 연결합니다. 그렇게 하면 플레이어 속성 및 게임 모드를 바탕으로 게임에 적합하게 플레이어들을 서로 매칭하고 FlexMatch를 사용하여 플레이어 그룹 형성의 기본 구조와 플레이어의 게임 내 배치를 관리하는 방식을 설계할 수 있습니다. 사용자 지정 매치메이킹에 대한 자세한 내용은 [FlexMatch 규칙 세트 예제](match-examples.md) 단원을 참조하십시오.
매치를 구성한 후 FlexMatch는 게임 세션 배치를 위한 매치 데이터를 제공합니다. 호스팅Amazon GameLift Servers에를 사용하는 게임의 경우는 일치하는 플레이어가 있는 게임 세션 배치 요청을 게임 세션 대기열로 FlexMatch 보냅니다. 대기열은 Amazon GameLift Servers 플릿에서 사용할 수 있는 호스팅 리소스를 검색하여 매치를 위한 새로운 게임 세션을 시작합니다. 다른 호스팅 솔루션을 사용하는 게임의 경우 FlexMatch는 자체 게임 세션 배치 구성 요소에 제공할 일치 데이터를 제공합니다.
FlexMatch 매치메이커가 수신한 매치메이킹 요청을 처리하는 방법에 대한 자세한 설명은 [FlexMatch 매치메이킹 프로세스](gamelift-match-howitworks.md) 섹션을 참조하세요.
**Topics**
+ [FlexMatch 매치메이커 설계](match-configuration.md)
+ [FlexMatch 규칙 세트 빌드](match-rulesets.md)
+ [매치메이킹 구성 생성](match-create-configuration.md)
+ [FlexMatch 이벤트 알림 설정](match-notification.md)
# FlexMatch 매치메이커 설계
이 주제에서는 게임에 맞는 매치메이커를 설계하는 방법에 대한 지침을 제공합니다.
**Topics**
+ [기본 매치메이커 구성](#match-configuration-elements)
+ [매치메이커를 위한 위치 선택](match-configuration-regions.md)
+ [선택적 요소 추가](match-configuration-options.md)
## 기본 매치메이커 구성
매치메이커는 최소한 다음 요소를 필요로 합니다.
+ **규칙 세트**는 매치를 위한 팀의 규모 및 범위를 결정하고 매치에 참여할 플레이어를 평가할 때 적용할 규칙 세트를 정의합니다. 각 매치메이커는 한 가지 규칙 세트를 사용하도록 구성합니다. [FlexMatch 규칙 세트 빌드](match-rulesets.md) 및 [FlexMatch 규칙 세트 예제](match-examples.md) 섹션을 참조하세요.
+ **알림 대상**은 모든 매치메이킹 이벤트 알림을 받습니다. Amazon Simple Notification Service(SNS) 주제를 설정한 다음 매치메이커에 주제 ID를 추가해야 합니다. 알림 설정에 대한 자세한 정보는 [FlexMatch 이벤트 알림 설정](match-notification.md) 섹션을 참조하세요.
+ **요청 타임아웃**은 매치메이킹 요청이 요청 풀에 잔류하여 잠재적 매치의 평가 대상이 되는 기간을 결정합니다. 요청 시간이 초과되면 매치가 실패한 것이며 풀에서 제거됩니다.
+ Amazon GameLift Servers 관리형 호스팅과 함께 FlexMatch를 사용하는 경우, **게임 세션 대기열**은 매치를 위한 게임 세션을 호스팅하는 데 사용할 수 있는 최상의 리소스를 찾고 새 게임 세션을 시작합니다. 각 대기열은 게임 세션을 배치할 수 있는 위치를 결정하는 위치 및 리소스 유형 (스팟 또는 온디맨드 인스턴스 포함) 목록으로 구성됩니다. 대기열에 대한 자세한 내용은 [다중 위치 대기열 사용](https://docs.aws.amazon.com/gamelift/latest/developerguide/queues-intro.html)을 참조하세요.
# 매치메이커를 위한 위치 선택
매치메이킹 활동을 수행할 위치를 결정하고 해당 위치에서 매치메이킹 구성 및 규칙 세트를 생성합니다. Amazon GameLift Servers는 게임의 매치 요청에 대한 티켓 풀을 유지하여 실행 가능한 매치를 정렬하고 평가합니다. 매칭 후 Amazon GameLift Servers가 게임 세션 배치를 위해 매칭 세부 정보를 전송합니다. 호스팅 솔루션이 지원하는 모든 위치에서 일치하는 게임 세션을 실행할 수 있습니다.
FlexMatch 리소스를 생성할 수 있는 위치는 [FlexMatch 지원되는 AWS 리전](match-regions.md) 섹션을 참조하세요.
매치메이커에 AWS 리전 대해를 선택할 때 위치가 성능에 미치는 영향과 플레이어의 매치 경험을 최적화하는 방법을 고려합니다. 다음 모범 사례를 따르는 것이 좋습니다.
+ 플레이어 및 FlexMatch 매치메이킹 요청을 보내는 클라이언트 서비스와 가까운 위치에 매치메이커를 배치합니다. 이 방식을 사용하면 매치메이킹 요청 워크플로에 미치는 지연 시간이 줄어들어 효율성이 향상됩니다.
+ 게임이 전 세계 시청자에게 도달한다면 여러 위치에 매치메이커를 만들어 플레이어와 가장 가까운 매치메이커로 매치 요청을 라우팅하는 것을 고려해 보세요. 이렇게 하면 효율성이 향상될 뿐만 아니라 지리적으로 서로 가까운 플레이어들로 티켓 풀이 형성되어, e지연 시간 요구 사항에 따라 플레이어들을 매칭할 수 있는 매치메이커의 능력이 향상됩니다.
+ Amazon GameLift Servers 관리형 호스팅과 함께 FlexMatch를 사용하는 경우 매치메이커와 매치메이커가 사용하는 게임 세션 대기열을 동일한 위치에 배치합니다. 이렇게 하면 매치메이커와 대기열 간의 통신 지연을 최소화하는 데 도움이 됩니다.
# 선택적 요소 추가
이러한 최소 요건에 더해, 다음 추가 옵션으로 매치메이커를 구성할 수 있습니다. Amazon GameLift Servers 호스팅 솔루션과 FlexMatch 함께를 사용하는 경우 많은 기능이 내장되어 있습니다. FlexMatch를 독립형 매치메이킹 서비스로 사용하는 경우 이러한 기능을 시스템에 구축하는 것이 좋습니다.
**플레이어 수락**
매치에 선택된 모든 플레이어의 참여 수락을 요청하도록 매치메이커를 구성할 수 있습니다. 시스템에서 수락을 요구하는 경우, 모든 플레이어에게는 제안된 매치에 대해 수락하거나 거부할 수 있는 선택권이 주어져야 합니다. 매치는 제안된 매치에 속한 모든 플레이어로부터 수락을 접수해야만 성사됩니다. 임의의 플레이어가 매치를 거부하거나 수락하지 못한 경우 제안된 매치는 폐기되며 티켓은 다음과 같이 처리됩니다. 티켓에 있는 모든 플레이어가 매치를 수락한 티켓은 계속 처리될 수 있도록 매치메이킹 풀로 반환됩니다. 한 명 이상의 플레이어가 매치를 거부하거나 응답하지 않은 티켓은 실패 상태가 되며 더 이상 처리되지 않습니다. 플레이어 수락에는 시간 제한이 수반되며, 모든 플레이어가 제한 시간 내에 제안된 매치를 수락해야 매치가 계속됩니다.
**채우기 모드**
FlexMatch 채우기를 사용하여 게임 세션의 수명 전반에서 게임 세션을 잘 매칭된 새로운 플레이어로 계속 채웁니다. 채우기 요청을 처리할 때 FlexMatch는 원래 플레이어를 매칭하는 데 사용한 동일한 매치메이커를 사용합니다. 새 매치 티켓의 우선 순위를 지정하여 채우기 티켓을 라인의 맨 앞이나 끝에 배치하는 방식으로 사용자 지정할 수 있습니다. 즉, 새 플레이어가 매치메이킹 풀에 들어오면 새로 구성된 게임에 배정될 확률보다 기존 게임에 배정될 확률이 더 높거나 낮아집니다.
게임에서 관리형 Amazon GameLift Servers 호스팅과 함께 FlexMatch를 사용하든 다른 호스팅 솔루션과 함께 사용하든 관계없이 수동 채우기를 사용할 수 있습니다. 수동 채우기를 사용하면 채우기 요청을 트리거할 시기를 유연하게 결정할 수 있습니다. 예를 들어 게임의 특정 단계 동안 또는 특정 조건이 존재할 때에 새 플레이어를 추가하려고 할 수 있습니다.
자동 채우기는 관리형 Amazon GameLift Servers 호스팅을 사용하는 게임에만 사용할 수 있습니다. 이 기능을 활성화하면 게임 세션이 열린 플레이어 슬롯으로 시작하는 경우 Amazon GameLift Servers는 해당 슬롯에 대한 채우기 요청을 자동으로 생성하기 시작합니다. 이 기능을 사용하면 최소 수의 플레이어로 새 게임을 시작한 다음 새 플레이어가 매치메이킹 풀에 들어오면 신속하게 채워지도록 매치메이킹을 설정할 수 있습니다. 게임 세션 수명 전반에 걸쳐 언제든지 자동 채우기를 끌 수 있습니다.
**게임 속성**
Amazon GameLift Servers 관리형 호스팅과 함께 FlexMatch를 사용하는 게임의 경우 새 게임 세션이 요청될 때마다 게임 서버에 전달할 추가 정보를 제공할 수 있습니다. 이는 생성 중인 매치 유형에 맞게 게임 세션을 시작하는 데 필요한 게임 모드 구성을 전달하는 데 유용한 방법이 될 수 있습니다. 매치메이커가 생성한 매치의 모든 게임 세션에는 동일한 게임 속성 세트를 수신합니다. 다양한 매치메이킹 구성을 생성하여 게임 속성 정보를 변경할 수 있습니다.
**예약된 플레이어 슬롯**
각 매치에 있는 특정 플레이어 슬롯이 예약되었다가 나중에 채워지도록 지정할 수 있습니다. 이는 매치메이킹 구성의 "추가 플레이어 카운트" 속성을 구성함으로써 수행됩니다.
**사용자 지정 이벤트 데이터**
이 속성을 사용하여 매치메이커에 대한 모든 매치메이킹 관련 이벤트에 일단의 사용자 지정 정보를 포함시킵니다. 이 기능은 매치메이커의 성과 추적을 포함하여 게임에 대한 특정한 고유 활동을 추적하는 데 유용할 수 있습니다.
# FlexMatch 규칙 세트 빌드
모든 FlexMatch 매치메이커에는 규칙 세트가 있어야 합니다. 규칙 세트는 매치의 두 가지 핵심 요소인 게임의 팀 구조 및 크기와 최상의 매치를 위해 플레이어를 그룹화하는 방법을 결정합니다.
예를 들어, 규칙 세트에서 다음과 같이 매치를 기술할 수 있을 것입니다. 플레이어가 각각 다섯 명이고 한 팀은 수비이고 다른 한 팀은 공격인 두 팀으로 매치를 생성합니다. 한 팀에 초보 플레이어와 경험이 많은 플레이어가 공존할 수 있지만 두 팀의 평균 스킬 포인트가 서로 10포인트 이내여야 합니다. 30초 이후에 매치가 생성되지 않은 경우 스킬 요구 사항을 점진적으로 완화합니다.
이 단원의 주제에서는 매치메이킹 규칙 세트를 설계 및 빌드하는 방법을 설명합니다. 규칙 세트를 생성할 때 Amazon GameLift Servers 콘솔 또는 AWS CLI를 사용할 수 있습니다.
**Topics**
+ [FlexMatch 규칙 세트 설계](match-design-ruleset.md)
+ [FlexMatch 라지 매치 규칙 세트 설계](match-design-rulesets-large.md)
+ [자습서: 매치메이킹 규칙 세트 생성](match-create-ruleset.md)
+ [FlexMatch 규칙 세트 예제](match-examples.md)
# FlexMatch 규칙 세트 설계
이 주제에서는 규칙 세트의 기본 구조 및 최대 40명의 플레이어로 이루어진 소규모 매치에서 규칙 세트를 구축하는 방법에 대해 다룹니다. 매치메이킹 규칙 세트가 수행하는 작업은 두 가지입니다. 하나는 매치의 팀 구조 및 크기를 레이아웃하는 것이고, 다른 하나는 플레이어를 선택하여 최상의 매치를 구성하는 방법을 매치메이커에게 알리는 것입니다.
하지만 매치메이킹 규칙 세트를 사용하면 더 많은 작업을 수행할 수 있습니다. 예를 들어, 다음을 수행할 수 있습니다.
+ 게임에 맞게 매치메이킹 알고리즘을 최적화합니다.
+ 최소 플레이어 지연 시간 요구 사항을 설정하여 게임 플레이 품질을 보호합니다.
+ 시간이 지남에 따라 팀 요구 사항과 매치 규칙을 점진적으로 완화하여 모든 활성 플레이어가 원할 때 적절한 매치를 찾을 수 있습니다.
+ 그룹 집계를 사용하여 그룹 매치메이킹 요청에 대한 처리를 정의합니다.
+ 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)` 작업을 사용하여 규칙 세트를 구축할 수 있습니다.
# 규칙 세트 설명(필수)
규칙 세트에 대한 세부 정보를 제공합니다.
+ *이름* (선택 사항) - 사용자가 직접 사용할 수 있는 설명 레이블입니다. 이 값은 Amazon GameLift Servers로 규칙 세트를 생성할 때 지정하는 규칙 세트 이름과 관련이 없습니다.
+ *ruleLanguageVersion* - FlexMatch 규칙을 생성하는 데 사용되는 속성 표현식 언어의 버전입니다. 값은 `1.0`이어야 합니다.
# 매치 알고리즘 사용자 정의
FlexMatch는 대부분의 게임에 대한 기본 알고리즘을 최적화하여 플레이어가 최소한의 대기 시간으로 적절한 매치에 참여할 수 있도록 합니다. 알고리즘을 사용자 정의하고 게임에 맞게 매치메이킹을 조정할 수 있습니다.
다음은 기본 FlexMatch 매치메이킹 알고리즘입니다.
1. FlexMatch는 모든 오픈 매치메이킹 티켓과 채우기 티켓을 티켓 풀에 배치합니다.
1. FlexMatch는 풀의 티켓을 하나 이상의 배치로 무작위로 그룹화합니다. 티켓 풀이 더 커지면 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"
},
```
# 플레이어 속성 선언
이 섹션에서는 매치메이킹 요청에 포함할 개별 플레이어 속성을 나열합니다. 규칙 세트에서 플레이어 속성을 선언하는 데에는 두 가지 이유가 있습니다.
+ 규칙 세트에 플레이어 속성에 의존하는 규칙이 포함된 경우.
+ 매치 요청을 통해 플레이어 속성을 게임 세션에 전달하려는 경우. 예를 들어 각 플레이어가 연결하기 전에 플레이어 캐릭터 선택을 게임 세션에 전달하고 싶을 수 있습니다.
플레이어 속성을 선언할 때 다음 정보를 포함합니다.
+ name(필수) - 이 값은 규칙 세트에 대해 고유해야 합니다.**
+ type(필수) - 이는 속성 값의 데이터 유형입니다.** 유효한 데이터 유형은 숫자, 문자열, 문자열 목록 또는 문자열 맵입니다.
+ default(선택 사항) - 매치메이킹 요청이 속성 값을 제공하지 않는 경우 사용할 기본값을 입력합니다.** 기본값이 선언되지 않고 요청에 값이 포함되지 않은 경우 FlexMatch는 요청을 처리할 수 없습니다.
# 매치 팀 정의
매치에 대한 팀의 구조 및 크기를 설명합니다. 각 매치에 팀이 하나 이상 있어야 하며 원하는 수의 팀을 정의할 수 있습니다. 팀의 플레이어 수가 동일할 수 있거나 팀이 비대칭일 수 있습니다. 예를 들어 플레이어가 한 명인 몬스터 팀과 플레이어가 10명인 헌터 팀을 정의할 수 있습니다.
FlexMatch에서는 규칙 세트가 팀 크기를 정의하는 방법에 따라 매치 요청을 스몰 매치 또는 라지 매치로 처리합니다. 플레이어 수가 최대 40명인 잠재적 매치는 스몰 매치이며 플레이어 수가 40을 초과하는 매치는 라지 매치입니다. 규칙 세트의 잠재적 매치 크기를 결정하려면 규칙 세트에 정의된 모든 팀에 대한 *maxPlayer* 설정을 합산합니다.
+ name(필수 항목) - 각 팀에 고유한 이름을 할당합니다.** 이 이름은 규칙과 확장, 및 게임 세션의 매치메이킹 데이터에 대한 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(필수) - 이 type 요소는 규칙을 처리할 때 사용하는 연산을 식별합니다.** 각 규칙 유형에는 추가 속성 세트가 필요합니다. [FlexMatch 규칙 언어](match-rules-reference.md)의 유효한 규칙 유형 및 속성 목록을 참조하세요.
+ 규칙 유형 속성(필수 항목일 수 있음) - 정의되는 규칙 유형에 따라 특정 규칙 속성을 설정해야 할 수도 있습니다. [FlexMatch 규칙 언어](match-rules-reference.md)에서 속성 및 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
}]
}]
```
자동 채우기가 활성화되어 있는 매치메이커의 경우 플레이어 수 요구 사항을 너무 빨리 완화하지 않습니다. 새 게임 세션이 시작되고 자동 채우기를 시작할 때까지 몇 초 정도의 시간이 걸립니다. 보다 나은 접근 방식은 게임에 대한 자동 채우기가 시작될 조짐이 보인 후에만 확장을 시작하는 것입니다. 확장 타이밍은 팀 구성 요소에 따라 다르므로 테스트를 통해 게임에 가장 적합한 확장 전략을 찾습니다.
# FlexMatch 라지 매치 규칙 세트 설계
규칙 세트에서 41\$1200명의 플레이어가 허용되는 매치를 만들 경우 규칙 세트 구성을 약간 조정해야 합니다. 이러한 조정을 통해 매치 알고리즘이 최적화되어 플레이어 대기 시간을 단축하는 동시에 라지 매치를 성공적으로 구축할 수 있습니다. 따라서 라지 매치 규칙 세트는 시간이 많이 걸리는 사용자 지정 규칙을 일반적인 매치메이킹 우선 순위에 최적화된 표준 솔루션으로 대체합니다.
라지 매치를 위해 규칙 세트를 최적화해야 하는지 여부를 결정하는 방법은 다음과 같습니다.
1. 규칙 세트에 정의된 각 팀에 대해 maxPlayer의 값을 얻습니다.**
1. 모든 maxPlayer 값을 추가합니다.** 합계가 40을 초과하는 경우 라지 매치 규칙 세트가 지정된 것입니다.
라지 매치에 맞게 규칙 세트를 최적화하려면 다음에 설명한 대로 조정합니다. [라지 매치에 대한 규칙 세트 스키마](match-ruleset-schema-large.md)에서 라지 매치 규칙 세트에 대한 스키마 및 [예제: 라지 매치 생성](match-examples-7.md)에서 규칙 세트 예를 참조하세요.
# 라지 매치를 위한 매치 알고리즘 사용자 지정
아직 없는 경우 알고리즘 구성 요소를 규칙 세트에 추가합니다. 다음 속성을 설정합니다.
+ `strategy`(필수) - `strategy` 속성을 “balanced”로 설정합니다. 이 설정은 FlexMatch가 `balancedAttribute` 속성에 정의된 지정된 플레이어 속성을 기반으로 최적의 팀 밸런스를 찾기 위해 매치 후 추가 확인을 수행하도록 트리거합니다. 균형 잡힌 전략을 사용하면 균등하게 매칭되는 팀을 구성하기 위한 사용자 지정 규칙의 필요성을 대체합니다.
+ `balancedAttribute`(필수) - 매치에서 팀 밸런스를 맞출 때 사용할 플레이어 속성을 식별합니다. 이 속성은 숫자 데이터 유형(Double 또는 정수)이어야 합니다. 예를 들어, 플레이어 스킬에 균형을 맞추기로 선택한 경우 FlexMatch는 모든 팀의 총 스킬 레벨이 최대한 균등하게 매칭하도록 플레이어를 배정하려고 합니다. 규칙 세트의 플레이어 속성에서 밸런싱 속성을 선언해야 합니다.
+ `batchingPreference`(선택 사항) - 플레이어들이 최대한 지연 시간을 최소화할 수 있는 매치를 만드는 데 어느 정도 중점을 둘 것인지 선택합니다. 이 설정은 매치를 구성하기 전에 매치 티켓을 정렬하는 방식에 영향을 줍니다. 옵션에는 다음이 포함됩니다.
+ 가장 큰 모집단. FlexMatch를 사용하면 한 곳 이상의 공통 위치에서 허용 가능한 지연 시간이 있는 풀의 모든 티켓을 사용하여 매치를 진행할 수 있습니다. 따라서 잠재적 티켓 풀이 커지는 경향이 있어 매치를 더 빨리 채우기가 더 쉬워집니다. 플레이어들이 게임에 적절하게 배정될 수 있지만 항상 최적의 상태는 아니며 지연 시간이 있을 수 있습니다. `batchingPreference` 속성이 설정되지 않은 경우, `strategy`가 “balanced”로 설정된 때의 기본 동작입니다.
+ 가장 빠른 위치. FlexMatch는 가장 낮은 지연 시간 값을 보고하는 위치를 기준으로 풀의 모든 티켓을 사전 정렬합니다. 따라서 동일한 위치에서 지연 시간이 짧다고 보고한 플레이어로 매치를 구성하는 경향이 있습니다. 동시에 각 매치의 잠재적 티켓 풀이 적기 때문에 매치를 채우는 데 필요한 시간이 늘어날 수 있습니다. 또한 지연 시간에 더 높은 우선 순위가 부여되기 때문에 매치에 참가하는 플레이어는 밸런싱 속성과 관련하여 더 폭넓게 달라질 수 있습니다.
다음 예에서는 다음과 같이 동작하도록 매치 알고리즘을 구성합니다. (1) 티켓 풀을 사전 정렬하여 지연 시간 값이 허용되는 위치별로 티켓을 그룹화하고, (2) 매칭을 위해 정렬된 티켓을 일괄 구성하며, (3) 티켓으로 매치를 만들고 팀의 균형을 조정하여 평균 플레이어 스킬을 균등하게 맞춥니다.
```
"algorithm": {
"strategy": "balanced",
"balancedAttribute": "player_skill",
"batchingPreference": "largestPopulation"
},
```
# 플레이어 속성 선언
규칙 세트 알고리즘에서 밸런싱 속성으로 사용되는 플레이어 속성을 선언해야 합니다. 매치메이킹 요청의 각 플레이어마다 이 속성을 포함해야 합니다. 플레이어 속성에 기본값을 제공할 수 있지만 속성 밸런싱은 플레이어별 값을 제공할 때 가장 잘 작동합니다.
# 팀 정의
팀 크기 및 구조를 정의하는 프로세스는 스몰 매치의 경우와 동일하지만 FlexMatch에서 팀을 채우는 방식이 다릅니다. 이는 매치가 부분적으로만 채워졌을 때의 모양과 어떻게 가장 가까울 수 있는지에 영향을 줍니다. 응답에서 최소 팀 크기를 조정할 수도 있습니다.
FlexMatch는 팀에 플레이어를 할당할 때 다음 규칙을 사용합니다. 먼저 아직 해당 최소 플레이어 요구 사항을 충족하지 않은 팀을 찾습니다. 두 번째로, 이러한 팀 중 열려 있는 슬롯이 가장 많은 팀을 찾습니다.
크기가 동일하게 지정된 여러 팀을 정의하는 매치의 경우 채워질 때까지 각 팀에 순차적으로 플레이어가 추가됩니다. 따라서 매치에 참가한 팀의 플레이어 수는 항상 거의 같으며, 매치가 꽉 차지 않은 경우에도 마찬가지입니다. 현재는 라지 매치에서 크기가 동일하게 지정된 팀을 강제 적용할 방법은 없습니다. 비대칭적으로 크기가 지정된 팀이 있는 매치의 경우 이 프로세스는 약간 더 복잡합니다. 이 시나리오에서는 플레이어가 처음에는 열려 있는 슬롯이 가장 많은 가장 큰 팀에 할당됩니다. 열려 있는 슬롯 수가 모든 팀 간에 더 공평하게 분산됨에 따라 플레이어가 더 작은 팀에 슬롯됩니다.
예를 들어, 세 팀으로 구성된 규칙 세트가 있다고 가정해 보겠습니다. Red 팀과 Blue 팀 모두 `maxPlayers`=10, `minPlayers`=5로 설정되어 있으며, Green 팀은 `maxPlayers` =3, `minPlayers` =2로 설정되어 있습니다. 채우기 순서는 다음과 같습니다.
1. 아직 `minPlayers`에 도달한 팀이 없습니다. Red 팀과 Blue 팀에 열려 있는 슬롯이 10개 있는데 Green 팀에는 3개가 있습니다. 첫 10명의 플레이어(각각 5명)가 Red 팀과 Blue 팀에 할당됩니다. 이제 두 팀 모두 `minPlayers`에 도달했습니다.
1. Green 팀은 아직 `minPlayers`에 도달하지 않았습니다. 다음 2명의 플레이어가 Green 팀에 할당됩니다. 이제 Green 팀이 `minPlayers`에 도달했습니다.
1. 모든 팀이 `minPlayers`인 경우, 이제 열린 슬롯 수에 따라 추가 플레이어가 배정됩니다. Red 팀과 Blue 팀에 열려 있는 슬롯이 5개 있는데 Green 팀에는 1개가 있습니다. 다음 8명의 플레이어(각각 4명)가 Red 팀과 Blue 팀에 할당됩니다. 이제 모든 팀에 1개의 빈 슬롯이 있습니다.
1. 나머지 3명의 플레이어 슬롯은 특별한 순서 없이 팀(각 1명씩)에 배정됩니다.
# 라지 매치의 규칙 설정
라지 매치의 매치메이킹은 주로 밸런싱 전략과 지연 시간 배칭 최적화에 의존합니다. 대부분의 사용자 지정 규칙을 사용할 수 없습니다. 하지만 다음과 같은 규칙 유형을 통합할 수 있습니다.
+ 플레이어 지연 시간을 엄격하게 제한하는 규칙. `maxLatency` 속성과 함께 `latency` 규칙 유형을 사용합니다. [지연 규칙](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) 참조를 살펴보세요. 다음은 매치의 플레이어들이 서로 한 스킬 레벨 이내여야 하는 예제입니다.
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# 라지 매치 요구 사항 완화
스몰 매치의 경우처럼 유효한 매치가 가능하지 않을 때 확장을 사용하여 시간 경과에 따라 매치 요구 사항을 완화할 수 있습니다. 라지 매치의 경우 지연 시간 규칙 또는 팀 플레이어 수를 완화하는 옵션이 있습니다.
라지 매치에 자동 매치 채우기를 사용 중인 경우 팀 플레이어 수를 너무 빨리 완화하지는 마십시오. FlexMatch에서는 게임 세션이 시작된 후에만 채우기 요청 생성을 시작합니다. 이는 매치가 생성된 후 몇 초 동안 발생하지 않을 수도 있습니다. 해당 시간 동안 FlexMatch는 특히 플레이어 수 규칙이 낮게 조정될 때 부분적으로 채워진 여러 새 게임 세션을 생성할 수 있습니다. 따라서 결국 필요한 수보다 더 많은 게임 세션이 생성되고 이러한 세션 간에 플레이어가 너무 촘촘하게 분산됩니다. 최상의 방법은 플레이어 수 확장의 첫 번째 단계에 더 긴 대기 시간(게임 세션이 시작하기에 충분히 긴 시간)을 지정하는 것입니다. 라지 매치의 경우 채우기 요청에 더 높은 우선 순위가 지정되므로 새 게임이 시작되기 전에 새로 들어오는 플레이어는 기존 게임에 배정됩니다. 게임에 이상적인 대시 시간을 찾아보는 연습을 해야 할 수도 있습니다.
다음은 초기 대기 시간이 더 긴 Yellow 팀의 플레이어 수를 점진적으로 낮추는 예입니다. 규칙 세트 확장의 대기 시간은 복합 값이 아닌 절대 값임을 명심하십시오. 따라서 첫 번째 확장이 5초에 발생하고, 두 번째 확장이 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 리전에서 보유할 수 있는 최대 규칙 세트 수에 대한 [Service Quotas](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. **생성(Create)**을 선택합니다. 생성을 성공적으로 마쳤으면 매치메이커가 규칙 세트를 사용할 수 있습니다.
------
#### [ AWS CLI ]
**규칙 세트 생성**
명령줄 창을 열고 [create-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-rule-set.html) 명령을 사용합니다.
이 예제 명령에서는 단일 팀을 설정하는 간단한 매치메이킹 규칙 세트를 생성합니다. 사용할 매치메이킹 구성과 동일한 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}]}'
```
생성 요청이 성공하면 Amazon GameLift Servers가 여러분이 지정한 설정과 함께 [MatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html) 객체를 반환합니다. 이제 매치메이커가 새 규칙 세트를 사용할 수 있습니다.
------
------
#### [ 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**
+ [예제: 플레이어가 동등하게 매칭된 두 팀 생성](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)
# 예제: 플레이어가 동등하게 매칭된 두 팀 생성
이 예제에서는 다음과 같은 지침을 기준으로 플레이어가 동등하게 매치된 두 팀을 설정하는 방법을 설명합니다.
+ 두 개의 플레이어 팀을 생성합니다.
+ 각 팀마다 4\$18 명의 플레이어를 포함합니다.
+ 최종적으로 팀들의 플레이어 수가 동일해야 합니다.
+ 플레이어의 스킬 레벨을 포함합니다(제공되지 않은 경우, 기본 설정 10).
+ 스킬 레벨이 다른 플레이어와 비슷한지 여부를 바탕으로 플레이어를 선택합니다. 두 팀의 평균 플레이어 스킬이 10점 이내가 되도록 합니다.
+ 매치가 신속하게 성사되지 않을 경우, 플레이어의 스킬 요건을 완화하여 합리적인 시간 내에서 매치가 성사되도록 합니다.
+ 5초 후에 검색을 확장하여 팀들의 평균 플레이어 스킬 차이를 50점 이내로 완화합니다.
+ 15초 후에 검색을 확장하여 팀들의 평균 플레이어 스킬 차이를 100점 이내로 완화합니다.
이 규칙 세트 사용에 대한 참고 사항:
+ 이 예제에서는 팀의 규모가 4명에서 8명 사이입니다(물론 팀 간에 플레이어 수는 동일해야 함). 유효한 규모의 범위에 속하는 팀에 대해 매치메이커는 허용되는 최대 수의 플레이어를 매치하기 위해 최선의 시도를 합니다.
+ `FairTeamSkill` 규칙에 의해 팀들은 플레이어 스킬을 바탕으로 균등하게 매치됩니다. 새로운 각 잠재 플레이어에 대해 이 규칙을 평가하기 위해 FlexMatch는 임시로 플레이어를 팀에 추가하고 평균을 계산합니다. 규칙에 부합하지 않은 경우 해당 잠재 플레이어는 매치에 추가되지 않습니다.
+ 두 팀의 구조가 서로 일치하므로 팀 정의를 하나만 생성하고 팀 수량을 "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명의 몬스터로 구성되는 별도의 팀을 생성합니다.
+ 다음 플레이어 속성을 포함합니다.
+ 플레이어의 스킬 레벨(제공되지 않은 경우, 기본 설정 10).
+ 플레이어가 선호하는 몬스터 스킬 레벨(제공되지 않은 경우, 기본 설정 10).
+ 플레이어가 몬스터가 되고 싶은지 여부(제공되지 않은 경우, 기본 설정 0 또는 F).
+ 다음 기준에 따라 몬스터가 될 플레이어를 선택합니다.
+ 플레이어가 몬스터 역할을 요청해야 합니다.
+ 플레이어가 헌터 팀에 이미 속한 플레이어가 선호하는 최고 스킬 레벨 이상을 충족해야 합니다.
+ 다음 기준에 따라 헌터 팀 플레이어를 선택합니다.
+ 몬스터 역할을 요청한 플레이어는 헌터 팀에 합류할 수 없습니다.
+ 몬스터 역할이 충원된 경우 플레이어가 원하는 몬스터의 스킬 레벨이 제안된 몬스터의 스킬보다 낮아야 합니다.
+ 매치가 신속하게 이루어지지 않는 경우, 다음과 같이 헌터 팀의 최소 규모를 완화합니다.
+ 30초 후에는 네 명의 플레이어만 헌터 팀에 속해도 게임이 시작될 수 있도록 합니다.
+ 60초 후에는 세 명의 플레이어만 헌터 팀에 속해도 게임이 시작될 수 있도록 합니다.
이 규칙 세트 사용에 대한 참고 사항:
+ 헌터와 몬스터 두 개의 별도 팀을 사용함으로써 각기 다른 일단의 기준으로 바탕으로 회원을 평가할 수 있습니다.
```
{
"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개의 팀을 생성합니다. 또한 모든 플레이어에 대해 최대 지연 시간을 설정해 봅니다. 매치 성사를 위해 시간 경과에 따라 최대 지연 시간을 완화할 수 있습니다. 이 예제에서는 다음과 같은 지침을 설정합니다.
+ 세 개의 플레이어 팀을 생성합니다.
+ 각 팀마다 3\$15명의 플레이어를 포함합니다.
+ 최종적으로 팀들은 동일한 혹은 거의 동일한(차이: 1명 이내) 수의 플레이어를 포함해야 합니다.
+ 다음 플레이어 속성을 포함합니다.
+ 플레이어의 스킬 레벨(제공되지 않은 경우, 기본 설정 10).
+ 플레이어의 캐릭터 역할(제공되지 않은 경우, 기본 설정 "농부").
+ 매치에서 스킬 레벨이 다른 플레이어와 비슷한지 여부를 바탕으로 플레이어를 선택합니다.
+ 각 팀의 평균 플레이어 스킬이 10점 이내가 되도록 합니다.
+ 팀의 "메딕" 캐릭터 수는 다음과 같이 제한합니다.
+ 매치 전체적으로 메딕의 최대 수는 5명입니다.
+ 50밀리초 이하의 지연 시간을 보고하는 플레이어만 매칭합니다.
+ 매치가 신속하게 이루어지지 않는 경우, 다음과 같이 플레이어 지연 시간 요건을 완화합니다.
+ 10초 후에는 플레이어 지연 시간 값을 최대 100ms로 완화합니다.
+ 20초 후에는 플레이어 지연 시간 값을 최대 150ms로 완화합니다.
이 규칙 세트 사용에 대한 참고 사항:
+ 규칙 세트에 의해 팀들은 플레이어 스킬을 바탕으로 균등하게 매치됩니다. `FairTeamSkill` 규칙을 평가하기 위해 FlexMatch는 임시로 잠재 플레이어를 팀에 추가하고 해당 팀에서 플레이어의 평균 스킬을 계산합니다. 그런 다음 해당 평균 스킬을 두 팀에 있는 플레이어의 평균 스킬과 비교합니다. 규칙에 부합하지 않은 경우 해당 잠재 플레이어는 매치에 추가되지 않습니다.
+ 팀 및 매치 레벨 요건(총 메딕 수)은 수집 규칙을 통해 달성합니다. 이 규칙 유형은 모든 플레이어의 캐릭터 속성 목록을 취하고 최대 카운트에 대해 확인합니다. `flatten`을 사용하여 모든 팀의 모든 플레이어 목록을 생성합니다.
+ 지연 시간을 기준으로 평가할 때 다음에 유의합니다.
+ 지연 시간 데이터는 플레이어 객체의 일부로 매치메이킹 요청에 제공됩니다. 플레이어 속성이 아니므로 나열될 필요가 없습니다. 정확한 지연 시간 측정값을 얻으려면 Amazon GameLift Servers의 UDP 핑 비콘을 사용합니다. 이러한 엔드포인트를 사용하면 플레이어 디바이스와 각 잠재적 호스팅 위치 간의 실제 UDP 네트워크 지연 시간을 측정할 수 있으므로 ICMP Ping을 사용하는 것보다 더 정확한 배치 결정을 내릴 수 있습니다. UDP 핑 비콘을 사용하여 지연 시간을 측정하는 방법에 대한 자세한 내용은 [UDP 핑 비콘](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html) 섹션을 참조하세요.
+ 매치메이커는 리전 별로 지연 시간을 평가합니다. 리전을 불문하고 지연 시간의 최대치보다 긴 경우 무시됩니다. 매치에 대해 수락되기 위해서는 플레이어의 지연 시간이 적어도 한 리전에서 최대치보다 짧아야 합니다.
+ 매치메이킹 요청에서 하나 이상의 플레이어에 대한 지연 시간 데이터가 누락된 경우 모든 매치에 대해 요청이 거부됩니다.
```
{
"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명의 플레이어를 포함합니다.
+ 다음 플레이어 속성을 포함합니다.
+ 경험 레벨(제공되지 않은 경우, 기본 설정 50).
+ 선호 게임 모드(복수 값 나열 가능)(제공되지 않은 경우 기본 설정 "협동" 및 "데스매치").
+ 선호 게임 맵(맵 이름 및 선호 가중치 포함)(제공되지 않은 경우 기본 설정 `"defaultMap"` 및 가중치 100).
+ 사전 정렬 설정:
+ 앵커 플레이어와 동일한 게임 맵에 대한 선호를 기준으로 플레이어를 정렬합니다. 플레이어가 복수의 희망 게임 맵을 가질 수 있으므로 이 예제에서는 선호 값을 사용합니다.
+ 경험 레벨이 앵커 플레이어와 얼마나 근접한지를 기준으로 플레이어를 정렬합니다. 이렇게 정렬하고 나면 모든 팀에 있는 모든 플레이어가 최대한 근접하는 경험 레벨을 가지게 될 것입니다.
+ 모든 팀에 걸쳐 모든 플레이어가 선택한 게임 모드 중 공통 게임 모드가 하나 이상 있어야 합니다.
+ 모든 팀에 걸쳐 모든 플레이어가 선택한 게임 맵 중 공통 맵이 하나 이상 있어야 합니다.
이 규칙 세트 사용에 대한 참고 사항:
+ 게임 맵 정렬은 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
}]
}
```
# 예제: 복수 플레이어 속성 간의 교집합 찾기
이 예제에서는 두 개 이상의 플레이어 속성 간에 교집합을 찾기 위해 수집 규칙을 사용하는 방법을 보여줍니다. 속성 모음을 처리할 때 단일 속성의 경우 `intersection` 작업을, 다중 속성의 경우 `reference_intersection_count` 작업을 사용할 수 있습니다.
이러한 접근 방식을 보여주기 위해 이 예제에서는 선호하는 캐릭터를 토대로 매치에서 플레이어를 평가하고 있습니다. 이 예제 게임은 "완전 무료" 방식이기 때문에 매치에서 모든 플레이어가 게임 상대가 될 수 있습니다. 각 플레이어는 (1) 자신의 캐릭터를 선택하고, (2) 게임 상대가 될 캐릭터를 선택하라는 요청 메시지를 받게 됩니다. 매치에 참여하는 모든 플레이어가 다른 모든 플레이어의 선호 상대 목록에 있는 캐릭터를 사용하도록 하는 규칙이 필요합니다.
다음은 다음과 같은 특성이 있는 매치를 설명하는 규칙 세트의 예제입니다.
+ 팀 구성: 5명의 플레이어로 구성된 하나의 팀
+ 플레이어 속성:
+ *myCharacter*: 플레이어가 선택한 캐릭터입니다.
+ *preferredOpponents*: 플레이어가 게임 상대로 선택하고 싶은 캐릭터의 목록입니다.
+ 매치 규칙: 사용 중인 각 캐릭터가 모든 플레이어의 선호 상대 목록에 있는 경우에 잠재적 매치가 허용됩니다.
매치 규칙을 실행하기 위해 이 예제에서는 다음과 같은 속성 값을 가진 수집 규칙을 사용하고 있습니다.
+ 작업 - `reference_intersection_count` 작업을 사용하여 측정 값의 각 문자열 목록이 참조 값의 문자열 목록과 어떻게 교집합을 이루는지 평가합니다.
+ 측정 - `flatten` 속성 표현식을 사용하여 문자열 목록을 생성합니다. 각 문자열 목록에는 한 플레이어의 myCharacter 속성 값이 포함됩니다.**
+ 참조 값 - `set_intersection` 속성 표현식을 사용하여 매치에서 모든 플레이어에게 공통적인 preferredOpponents 속성 값 모두에 대한 문자열 목록을 생성합니다.**
+ 제한 - 각 플레이어가 선택한 캐릭터(측정 시 문자열 목록)는 모든 플레이어에 공통되는 선호 상대 중 최소 한 명과 매치될 수 있도록 `minCount`가 1로 설정됩니다.
+ 확장 - 15초 내에 매치가 성사되지 않으면 최소한의 교집합 요구 사항을 완화합니다.
이 규칙의 프로세스 흐름은 다음과 같습니다.
1. 해당 매치에 플레이어가 추가됩니다. 새 플레이어가 선호하는 상대 목록과의 교집합을 포함시켜 참조 값(문자열 목록)이 다시 계산됩니다. 새 플레이어가 선택한 캐릭터를 새 문자열 목록으로 추가하여 측정 값(문자열 목록의 목록)이 다시 계산됩니다.
1. Amazon GameLift Servers은 측정 값(플레이어가 선택한 캐릭터)의 각 문자열 목록이 최소 하나의 참조 값(플레이어가 선호하는 상대) 목록과 교집합을 이루는지 확인합니다. 이 예제에서는 측정 값의 각 문자열 목록에 오직 하나의 값이 포함되어 있기 때문에 교집합은 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
}]
}]
}
```
# 예제: 모든 플레이어를 대상으로 속성 비교
이 예제에서는 플레이어 그룹에서 플레이어 속성을 비교하는 방법을 보여줍니다.
다음은 다음과 같은 특성이 있는 매치를 설명하는 규칙 세트의 예제입니다.
+ 팀 구조: 두 개의 단일 플레이어 팀
+ 플레이어 속성:
+ *gameMode*: 플레이어가 선택한 게임 유형입니다(제공되지 않는 경우 기본 설정 "순서 기반").
+ *gameMap*: 플레이어가 선택한 게임 세상입니다(제공되지 않는 경우 기본 설정 1).
+ *character*: 플레이어가 선택한 캐릭터입니다. 여기에 기본값이 없으면 플레이어가 캐릭터를 지정해야 합니다.
+ 매치 규칙: 매치된 플레이어는 다음 요구 사항을 충족해야 합니다.
+ 플레이어들이 동일한 게임 모드를 선택해야 합니다.
+ 플레이어들이 동일한 게임 맵을 선택해야 합니다.
+ 플레이어들이 서로 다른 캐릭터를 선택해야 합니다.
이 규칙 세트 사용에 대한 참고 사항:
+ 매치 규칙을 실행하기 위해 이 예제에서는 비교 규칙을 사용하여 모든 플레이어의 속성 값을 확인하고 있습니다. 게임 모드 및 맵에서 규칙은 값들이 동일한지 확인합니다. 각 캐릭터에서 규칙은 값들이 서로 다른지 확인합니다.
+ 이 예제에서는 하나의 플레이어 정의를 수량 속성과 함께 사용하여 두 플레이어 팀을 모두 생성합니다. 팀에 "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)에서 자세히 알아보세요.
이 예제 규칙 세트는 다음 지침에 따라 매치를 생성합니다.
+ 최소 요구 사항이 175명의 플레이어인 최대 200명의 플레이어로 이루어진 팀 하나를 생성합니다.
+ 밸런싱 기준: 유사한 스킬 레벨에 따라 플레이어를 선택합니다. 모든 플레이어는 매칭될 자신의 스킬 레벨을 보고해야 합니다.
+ 일괄 처리 선호도: 매치를 생성할 때 유사한 밸런싱 기준에 따라 플레이어를 그룹화합니다.
+ 지연 시간 규칙: 최대 허용 가능 플레이어 지연 시간을 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명을 초과할 수 있는 복수 팀의 매치에 대한 규칙 세트를 설정하는 방법을 설명합니다. 이 예제에서는 하나의 정의로 동일한 복수 팀을 생성하는 방법 및 매치를 생성하는 동안 비대칭으로 크기가 지정된 팀을 채우는 방법을 설명합니다.
이 예제 규칙 세트는 다음 지침에 따라 매치를 생성합니다.
+ 플레이어 수가 최대 15명인 동일한 "헌터" 팀 10개와 플레이어 수가 정확하게 5명인 "몬스터" 팀 한 개를 생성합니다.
+ 밸런싱 기준: 몬스터 처리 수에 따라 플레이어를 선택합니다. 플레이어가 자신의 처리 수를 보고하지 않는 경우 기본값인 5를 사용합니다.
+ 일괄 처리 선호도: 가장 빠른 플레이어 지연 시간을 보고하는 리전에 따라 플레이어를 그룹화합니다.
+ 지연 시간 규칙: 최대 허용 가능 플레이어 지연 시간을 200밀리초로 설정합니다.
+ 매치가 신속하게 채워지지 않는 경우 적합한 시간 내에 매치를 완료할 수 있도록 요구 사항을 완화합니다.
+ 15초 후에 플레이어가 10명인 팀을 수락합니다.
+ 20초 후에 플레이어가 8명인 팀을 수락합니다.
이 규칙 세트 사용에 대한 참고 사항:
+ 이 규칙 세트는 잠재적으로 최대 155명의 플레이어를 포함할 수 있는 팀을 정의합니다. 이로 인해 라지 매치가 됩니다.(10 x 15명의 헌터 \$1 5명의 몬스터 = 155)
+ 이 알고리즘은 "가장 빠른 리전" 일괄 처리 선호도를 사용하므로 플레이어가 보다 빠른 지연 시간을 보고하는 리전에 배치되려고 하며 높지만 허용 가능한 지연 시간을 보고하는 리전에는 배치되지 않으려는 경향을 보입니다. 동시에 매치에 더 적은 수의 플레이어가 포함될 가능성이 높아지고 밸런싱 기준(몬스터 스킬 수)이 더 다양해질 수도 있습니다.
+ 복수 팀 정의(수량 > 1)에 대한 확장이 정의되면 해당 확장이 해당 정의로 생성된 모든 팀에 적용됩니다. 따라서 헌터 팀의 최소 플레이어 설정을 완화함으로써 10개의 헌터 팀 모두가 동등한 영향을 받게 됩니다.
+ 이 규칙 세트는 플레이어 지연 시간을 최소화하도록 최적화되어 있으므로 지연 시간 규칙이 허용 가능한 연결 옵션이 없는 플레이어를 제외하는 catch-all로 사용됩니다. 이 요구 사항을 완화할 필요가 없습니다.
+ 다음은 확장이 적용되기 전에 FlexMatch에서 이 규칙 세트에 대해 매치를 채우는 방법입니다.
+ 아직 minPlayers 수에 도달한 팀이 없습니다. 헌터 팀의 열린 슬롯은 15개이고 몬스터 팀의 열린 슬롯은 5개입니다.
+ 첫 100명의 플레이어(10명씩)가 10개의 헌터 팀에 할당됩니다.
+ 다음 22명의 플레이어가 순차적으로(2명씩) 헌터 팀과 몬스터 팀에 할당됩니다.
+ 헌터 팀이 각각 12명의 플레이어인 minPlayers 수에 도달했습니다. 몬스터 팀에 2명의 플레이어가 있으며 아직 minPlayers 수에 도달하지 않았습니다.
+ 다음 3명의 플레이어가 몬스터 팀에 할당됩니다.
+ 모든 팀이 minPlayers 수에 도달했습니다. 헌터 팀에는 각각 3개의 열린 슬롯이 있습니다. 몬스터 팀이 채워졌습니다.
+ 마지막 30명의 플레이어가 순차적으로 헌터 팀에 할당됩니다. 따라서 모든 헌터 팀의 크기가 거의 비슷해집니다(한 명의 플레이어가 더 많거나 더 적음).
+ 이 규칙 세트로 생성한 매치에 대한 채우기를 활성화한 경우에는 플레이어 수 요구 사항을 너무 빨리 완화하지 마세요. 부분적으로 채워진 게임 세션이 너무 많아질 수 있습니다. [라지 매치 요구 사항 완화](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`를 사용하여 두 팀이 참가하는 매치에 대한 규칙 세트를 설정하는 방법을 보여줍니다. 예제에서는:
+ `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`를 사용하여 두 팀이 참가하는 매치에 대한 규칙 세트를 설정하는 방법을 보여줍니다. 예제에서는:
+ `SimilarLeagueDistance` 규칙은 매치에 참가하는 모든 플레이어가 다른 플레이어 2명 이내에 `league`를 갖도록 보장합니다.
+ `SimilarSkillDistance` 규칙은 매치에 참가하는 모든 플레이어가 다른 플레이어 10명 이내에 `skill`을 갖도록 보장합니다. 플레이어가 10초 동안 기다린 경우 거리는 20으로 확장됩니다. 플레이어가 20초 동안 기다린 경우 거리는 40으로 확장됩니다.
+ `SameMapComparison` 규칙은 매치에 참가한 모든 플레이어가 동일한 `map`를 요청하도록 보장합니다.
+ `SameModeComparison` 규칙은 매치에 참가한 모든 플레이어가 동일한 `mode`를 요청하도록 보장합니다.
+ 다음 조건 중 하나에 해당하면 `CompoundRuleMatchmaker` 규칙이 일치하는지 확인합니다.
+ 매치에 참가한 플레이어도 동일한 `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](https://aws.amazon.com/blogs/gametech/category/game-development/amazon-gamelift/)를 참조하세요.
이 예제에서는 다음과 같은 지침을 설정합니다.
+ 정확히 5명의 플레이어로 구성된 두 팀을 만듭니다..
+ 플레이어 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
}]
}
```
# 매치메이킹 구성 생성
Amazon GameLift Servers FlexMatch 매치메이커가 매치메이킹 요청을 처리하도록 설정하려면 매치메이킹 구성을 생성합니다. Amazon GameLift Servers 콘솔 또는 AWS Command Line Interface ()를 사용합니다AWS CLI. 매치메이커 생성에 대한 자세한 내용은 [FlexMatch 매치메이커 설계](match-configuration.md) 섹션을 참조하세요.
**Topics**
+ [자습서: Amazon GameLift Servers 호스팅을 위한 매치메이커 생성](match-create-configuration-withqueue.md)
+ [자습서: 독립형 FlexMatch를 위한 매치메이커 생성](match-create-configuration-standalone.md)
+ [자습서: 매치메이킹 구성 편집](match-create-configuration-edit.md)
# 자습서: Amazon GameLift Servers 호스팅을 위한 매치메이커 생성
매치메이킹 구성을 생성하기 전에 매치메이커와 함께 사용할 [규칙 세트와 게임 세션 대기열을 생성합니다](match-create-ruleset.md). Amazon GameLift Servers [https://docs.aws.amazon.com/gameliftservers/latest/developerguide/queues-creating.html](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/queues-creating.html)
------
#### [ Console ]
1. [Amazon GameLift Servers 콘솔](https://console.aws.amazon.com/gamelift/)의 탐색 창에서 **매치메이킹 구성**을 선택합니다.
1. 매치메이커를 생성하려는 AWS 리전으로 전환합니다.
1. **매치메이킹 구성** 페이지에서 **매치메이킹 구성 생성**을 선택합니다.
1. **구성 세부 정보 정의** 페이지의 **매치메이킹 구성 세부 정보**에서 다음을 수행합니다.
1. **이름**에는 목록과 지표에서 매치메이커를 식별하는 데 도움이 되는 매치메이커 이름을 입력합니다. 매치메이커 이름은 리전 내에서 고유해야 합니다. 매치메이킹 요청은 이름 및 리전으로 사용할 매치메이커를 식별합니다.
1. (선택 사항) **설명**에는 매치메이커를 식별하는 데 도움이 되는 설명을 추가합니다.
1. **규칙 세트**에는 목록에서 매치메이커와 함께 사용할 규칙 세트를 선택합니다. 목록은 현재 리전에 생성된 모든 규칙 세트를 포함합니다.
1. **FlexMatch 모드**에서 Amazon GameLift Servers 관리형 호스팅에 대해 **관리형**을 선택합니다. 이 모드에서는 FlexMatch가 성공적인 매치를 지정된 게임 세션 대기열로 전달하라는 메시지를 표시합니다.
1. **AWS 리전**에는 매치메이커와 함께 사용할 게임 세션 대기열을 구성한 리전을 선택합니다.
1. **대기열**에는 매치메이커와 함께 사용하려는 게임 세션 대기열을 선택합니다.
1. **다음**을 선택합니다.
1. **설정 구성** 페이지의 **매치메이킹 설정**에서 다음을 수행합니다.
1. **요청 제한 시간**에는 매치메이커가 각 요청의 매치를 성사시키는 데 대한 최대 시간(초)을 설정합니다. FlexMatch는 이 시간을 초과하는 매치메이킹 요청을 취소합니다.
1. **채우기 모드**에는 매치 채우기를 처리하기 위한 모드를 선택합니다.
+ 자동 채우기 기능을 설정하려면 **자동**을 선택합니다.
+ 자체 채우기 요청 관리를 생성하거나 채우기 기능을 사용하지 않으려면 **수동**을 선택합니다.
1. (선택 사항) **추가 플레이어 수**에는 매치에 계속 열어 둘 플레이어 슬롯 수를 설정합니다. FlexMatch는 이러한 슬롯을 향후에 플레이어로 채울 수 있습니다.
1. (선택 사항) **매치 수락 선택 사항**의 **수락 필수**에서 제안된 매치의 각 플레이어가 매치 참가를 적극적으로 수락하도록 요구하려면 **필수**를 선택합니다. 이 선택 사항을 선택하는 경우 **수락 제한 시간**에 대해 매치메이커가 매치를 취소하기 전에 플레이어 수락을 기다리는 시간(초)을 설정합니다.
1. (선택 사항) **이벤트 알림 설정**에서 다음을 수행합니다.
1. (선택 사항) **SNS 주제**의 경우 매치메이킹 이벤트 알림을 수신할 Amazon Simple Notification Service(SNS) 주제를 선택합니다. 아직 SNS 주제를 설정하지 않았다면 나중에 매치메이킹 구성 편집을 통해 이를 선택할 수 있습니다. 자세한 내용은 [FlexMatch 이벤트 알림 설정](match-notification.md) 단원을 참조하십시오.
1. (선택 사항) **사용자 지정 이벤트 데이터**에는 이벤트 메시징에서 이 매치메이커와 연결하고자 하는 임의의 사용자 지정 데이터를 입력합니다. FlexMatch는 매치메이커와 연결된 모든 이벤트에 이 데이터를 포함합니다.
1. (선택 사항) **추가 게임 데이터**를 확장한 후 다음을 수행합니다.
1. (선택 사항) **게임 세션 데이터**에는 FlexMatch가 이 매치메이킹 구성을 사용하여 만든 매치로 시작하는 새 게임 세션에 전달할 추가 게임 관련 정보를 입력합니다.
1. (선택 사항) **게임 속성**의 경우 새 게임 세션에 대한 정보가 포함된 키-값 쌍 속성을 추가합니다.
1. (선택 사항) **태그**에서 AWS 리소스를 관리하고 추적하는 데 도움이 되는 태그를 추가합니다.
1. **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서 선택 사항을 검토한 다음 **생성**을 선택합니다. 성공적으로 생성되었으면 매치메이커가 매치메이킹 요청을 접수할 준비가 된 것입니다.
------
#### [ AWS CLI ]
를 사용하여 매치메이킹 구성을 생성하려면 명령줄 창을 AWS CLI열고 [create-matchmaking-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-configuration.html) 명령을 사용하여 새 매치메이커를 정의합니다.
이 예제 명령은 플레이어 수락이 필요한 새로운 매치메이킹 구성을 생성하고 자동 채우기를 활성화합니다. 또한 나중에 플레이어를 추가할 수 있도록 FlexMatch에 두 개의 플레이어 슬롯을 예약하고 일부 게임 세션 데이터를 제공합니다.
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode WITH_QUEUE \
--game-session-queue-arns "arn:aws:gamelift:us-west-2:111122223333:gamesessionqueue/MyGameSessionQueue" \
--rule-set-name "MyRuleSet" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--backfill-mode AUTOMATIC \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic" \
--additional-player-count 2 \
--game-session-data "key=map,value=winter444"
```
매치메이킹 구성 생성 요청이 성공하면 Amazon GameLift Servers가 여러분이 요청한 매치메이커 설정과 함께 [MatchmakingConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html) 객체를 반환합니다. 이제 새 매치메이커가 매치메이킹 요청을 접수할 준비가 되었습니다.
------
# 자습서: 독립형 FlexMatch를 위한 매치메이커 생성
매치메이킹 구성을 생성하려면 먼저 매치메이커에 사용할 [규칙 세트를 생성](match-create-ruleset.md)합니다.
------
#### [ Console ]
1. [https://console.aws.amazon.com/gamelift/home](https://console.aws.amazon.com/gamelift/) Amazon GameLift Servers 콘솔을 엽니다.
1. 매치메이커를 생성하려는 AWS 리전으로 전환합니다. FlexMatch 매치메이킹 구성을 지원하는 리전 목록은 [매치메이커를 위한 위치 선택](match-configuration-regions.md) 섹션을 참조하세요.
1. 탐색 창에서 **FlexMatch**, **매치메이킹 구성**을 선택합니다.
1. **매치메이킹 구성** 페이지에서 **매치메이킹 구성 생성**을 선택합니다.
1. **구성 세부 정보 정의** 페이지의 **매치메이킹 구성 세부 정보**에서 다음을 수행합니다.
1. **이름**에는 목록과 지표에서 매치메이커를 식별하는 데 도움이 되는 매치메이커 이름을 입력합니다. 매치메이커 이름은 리전 내에서 고유해야 합니다. 매치메이킹 요청은 이름 및 리전으로 사용할 매치메이커를 식별합니다.
1. (선택 사항) **설명**에는 매치메이커를 식별하는 데 도움이 되는 설명을 추가합니다.
1. **규칙 세트**에는 목록에서 매치메이커와 함께 사용할 규칙 세트를 선택합니다. 목록은 현재 리전에 생성된 모든 규칙 세트를 포함합니다.
1. **FlexMatch 모드**에서 **독립 실행형**을 선택합니다. 이는 Amazon GameLift Servers 외부의 호스팅 솔루션에서 새 게임 세션을 시작하기 위한 사용자 지정 메커니즘이 있음을 나타냅니다.
1. **다음**을 선택합니다.
1. **설정 구성** 페이지의 **매치메이킹 설정**에서 다음을 수행합니다.
1. **요청 제한 시간**에는 매치메이커가 각 요청의 매치를 성사시키는 데 대한 최대 시간(초)을 설정합니다. 이 제한 시간을 초과하는 매치메이킹 요청은 거부됩니다.
1. (선택 사항) **매치 수락 선택 사항**의 **수락 필수**에서 제안된 매치의 각 플레이어가 매치 참가를 적극적으로 수락하도록 요구하려면 **필수**를 선택합니다. 이 선택 사항을 선택하는 경우 **수락 제한 시간**에 대해 매치메이커가 매치를 취소하기 전에 플레이어 수락을 기다리는 시간(초)을 설정합니다.
1. (선택 사항) **이벤트 알림 설정**에서 다음을 수행합니다.
1. (선택 사항) **SNS 주제**의 경우 매치메이킹 이벤트 알림을 수신할 Amazon SNS 주제를 선택합니다. 아직 SNS 주제를 설정하지 않았다면 나중에 매치메이킹 구성 편집을 통해 이를 선택할 수 있습니다. 자세한 내용은 [FlexMatch 이벤트 알림 설정](match-notification.md) 단원을 참조하십시오.
1. (선택 사항) **사용자 지정 이벤트 데이터**에는 이벤트 메시징에서 이 매치메이커와 연결하고자 하는 임의의 사용자 지정 데이터를 입력합니다. FlexMatch는 매치메이커와 연결된 모든 이벤트에 이 데이터를 포함합니다.
1. (선택 사항) **태그**에서 AWS 리소스를 관리하고 추적하는 데 도움이 되는 태그를 추가합니다.
1. **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서 선택 사항을 검토한 다음 **생성**을 선택합니다. 성공적으로 생성되었으면 매치메이커가 매치메이킹 요청을 접수할 준비가 된 것입니다.
------
#### [ AWS CLI ]
를 사용하여 매치메이킹 구성을 생성하려면 명령줄 창을 AWS CLI열고 [create-matchmaking-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-configuration.html) 명령을 사용하여 새 매치메이커를 정의합니다.
이 예제 명령은 플레이어 수락이 필요한 독립형 매치메이커에 대해 새로운 매치메이킹 구성을 생성합니다.
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode STANDALONE \
--rule-set-name "MyRuleSetOne" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic"
```
매치메이킹 구성 생성 요청이 성공하면 Amazon GameLift Servers가 여러분이 요청한 매치메이커 설정과 함께 [MatchmakingConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html) 객체를 반환합니다. 이제 새 매치메이커가 매치메이킹 요청을 접수할 준비가 되었습니다.
------
# 자습서: 매치메이킹 구성 편집
매치메이킹 구성을 편집하려면 탐색 모음에서 **매치메이킹 구성**을 선택하고 편집하려는 구성을 선택합니다. 이름을 제외한 기존 구성의 모든 필드를 업데이트할 수 있습니다.
구성 규칙 세트를 업데이트할 때 기존 활성 매치메이킹 티켓이 있는 경우 다음과 같은 이유로 새 규칙 세트가 호환되지 않을 수 있습니다.
+ 새 팀 이름 또는 다른 팀 이름 또는 팀 수
+ 새 플레이어 속성
+ 기존 플레이어 속성 유형 변경
규칙 세트에 이러한 변경을 적용하려면 업데이트된 규칙 세트를 사용하여 새 매치메이킹 구성을 생성합니다.
# FlexMatch 이벤트 알림 설정
이벤트 알림을 사용하여 개별 매치메이킹 요청 상태를 추적할 수 있습니다. 프로덕션 중인 게임이나 대량의 매치메이킹 활동이 있는 프로덕션 전 게임에서는 이벤트 알림을 사용해야 합니다.
이벤트 알림을 설정하는 데는 두 가지 옵션이 있습니다.
+ 매치메이커는 Amazon Simple Notification Service(SNS) 주제에 이벤트 알림을 게시하도록 합니다.
+ 자동으로 게시된 Amazon EventBridge 이벤트 및 이벤트 관리 도구 모음을 사용합니다.
Amazon GameLift Servers가 내보내는 FlexMatch 이벤트 목록을 보려면 [FlexMatch 매치메이킹 이벤트](match-events.md) 섹션을 참조하세요.
**중요**
대용량 매치메이킹 시스템의 경우 FIFO 주제 대신 표준(비 FIFO) Amazon SNS 주제를 사용하는 것이 좋습니다. FIFO 주제는 표준 주제보다 게시 제한이 적기 때문에 높은 로드 시 스로틀링 예외가 발생할 수 있습니다. FIFO 주제에 스로틀링이 발생하면 FlexMatch 알림이 손실될 수 있습니다.
**참고**
Amazon GameLift Servers는 기본 제공 재시도 로직을 사용하여 Amazon SNS 전송 실패 및 제한을 자동으로 처리합니다. Amazon SNS가 제한 오류 또는 임시 실패를 반환하면 Amazon GameLift Servers는 시도 간 점진적 지연으로 알림 전송을 재시도합니다. 이렇게 하면 이벤트 알림이 안정적으로 전달됩니다. 그러나 모든 재시도 후에도 실패가 지속되거나 권한 부여 실패 또는 주제 누락과 같은 재시도할 수 없는 오류가 발생하는 경우 알림이 손실될 수 있습니다.
**Topics**
+ [EventBridge 이벤트 설정](#match-notification-cwe)
+ [자습서: Amazon SNS 주제 설정](match-notification-sns.md)
+ [SNS 주제에 서버 측 암호화 설정](queue-notification-sns-sse.md)
+ [Lambda 함수를 호출하기 위해 주제 구독 구성](match-notification-lambda.md)
## EventBridge 이벤트 설정
Amazon GameLift Servers는 모든 매치메이킹 이벤트를 Amazon EventBridge에 자동으로 게시합니다. EventBridge를 사용하면 매치메이킹 이벤트를 처리 대상으로 라우팅하도록 규칙을 설정할 수 있습니다. 예를 들어 "PotentialMatchCreated" 이벤트를 플레이어 수락을 처리하는 AWS Lambda 함수로 라우팅하는 규칙을 설정할 수 있습니다. 자세한 내용은 [Amazon EventBridge란 무엇인가요?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 섹션을 참조하세요.
**참고**
매치메이커를 구성할 때 알림 대상 필드를 비워 두거나 EventBridge와 Amazon SNS를 모두 사용하려면 SNS 주제를 참조하세요.
# 자습서: Amazon SNS 주제 설정
Amazon GameLift Servers가 FlexMatch 매치메이커가 생성하는 모든 이벤트를 Amazon SNS 주제에 게시하도록 할 수 있습니다.
**Amazon GameLift Servers 이벤트 알림에 대한 SNS 주제를 생성하려면**
1. [Amazon SNS 콘솔](https://console.aws.amazon.com/sns)을 엽니다.
1. 탐색 창에서 **주제**를 선택합니다.
1. **주제** 페이지에서 **주제 생성**을 선택합니다.
1. 콘솔에서 주제를 생성합니다. 자세한 내용은 *Amazon Simple Notification Service 개발자 가이드*의 [AWS Management Console을 사용하여 주제를 생성하려면](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html#create-topic-aws-console)을 참조하세요.
1. 주제에 대한 **세부 정보** 페이지에서 **편집**을 선택합니다.
1. (선택 사항) 해당 주제의 **편집** 페이지에서 **액세스 정책**을 확장한 후, 다음 AWS Identity and Access Management (IAM) 정책문에서 굵은 구문을 기존 정책 끝에 추가합니다. (명확성을 위해 전체 정책이 여기에 표시됩니다.) 자체 SNS 주제 및 Amazon GameLift Servers 매치메이킹 구성에 대해서는 반드시 Amazon 리소스 이름(ARN) 세부 정보를 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish"
],
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
},
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:us-east-1:111122223333:matchmakingconfiguration/your_configuration_name"
}
}
}
]
}
```
------
1. **변경 사항 저장**을 선택합니다.
# SNS 주제에 서버 측 암호화 설정
서버 측 암호화(SSE)를 사용하면 암호화된 주제에서 민감한 데이터를 저장할 수 있습니다. SSE는 AWS Key Management Service ()에서 관리되는 키를 사용하여 Amazon SNS 주제의 메시지 내용을 보호합니다AWS KMS. Amazon SNS를 포함한 서버 측 암호화에 대한 자세한 내용은 *Amazon Simple Notification Service 개발자 가이드*의 [저장 시 암호화](https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html)를 참조하세요.
SNS 주제에 서버 측 암호화를 설정하려면 다음 주제를 검토합니다.
+ *AWS Key Management Service 개발자 가이드*의 [키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
+ *Amazon Simple Notification Service 개발자 가이드*의 [주제 SSE 활성화](https://docs.aws.amazon.com/sns/latest/dg/sns-enable-encryption-for-topic.html)
KMS 키를 생성할 때는 다음 KMS 키 정책을 사용합니다.
```
{
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:your_region:your_account:matchmakingconfiguration/your_configuration_name"
},
"StringEquals": {
"kms:EncryptionContext:aws:sns:topicArn": "arn:aws:sns:your_region:your_account:your_sns_topic_name"
}
}
}
```
# Lambda 함수를 호출하기 위해 주제 구독 구성
Amazon SNS 주제에 게시된 이벤트 알림을 사용하여 Lambda 함수를 호출할 수 있습니다. 매치메이커를 구성할 때는 알림 대상을 SNS 주제의 ARN으로 설정해야 합니다.
다음 AWS CloudFormation 템플릿은 라는 SNS 주제에 대한 구독을 구성`MyFlexMatchEventTopic`하여 라는 Lambda 함수를 호출합니다`FlexMatchEventHandlerLambdaFunction`. 템플릿은 Amazon GameLift Servers가 SNS 주제에 글을 쓸 수 있도록 허용하는 IAM 권한 정책을 생성합니다. 그런 다음 템플릿은 SNS 주제에 Lambda 함수를 호출할 권한을 추가합니다.
```
FlexMatchEventTopic:
Type: "AWS::SNS::Topic"
Properties:
KmsMasterKeyId: alias/aws/sns #Enables server-side encryption on the topic using an AWS managed key
Subscription:
- Endpoint: !GetAtt FlexMatchEventHandlerLambdaFunction.Arn
Protocol: lambda
TopicName: MyFlexMatchEventTopic
FlexMatchEventTopicPolicy:
Type: "AWS::SNS::TopicPolicy"
DependsOn: FlexMatchEventTopic
Properties:
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: gamelift.amazonaws.com
Action:
- "sns:Publish"
Resource: !Ref FlexMatchEventTopic
Topics:
- Ref: FlexMatchEventTopic
FlexMatchEventHandlerLambdaPermission:
Type: "AWS::Lambda::Permission"
Properties:
Action: "lambda:InvokeFunction"
FunctionName: !Ref FlexMatchEventHandlerLambdaFunction
Principal: sns.amazonaws.com
SourceArn: !Ref FlexMatchEventTopic
```