기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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
}]
}
```