파트너 센터에서 매치 메이킹 구성
이 항목에서는 호환되는 플레이어를 선택하도록 파트너 센터를 구성하는 방법을 설명합니다.
SmartMatch 매치 메이킹 런타임 작업의 구성
SmartMatch 구성 시 팀 규칙 정의
SmartMatch 매치 메이킹 런타임 작업의 구성
모든 SmartMatch 매치 메이킹 구성은 파트너 센터를 통해 이루어집니다.
매치 메이킹 세션 템플릿 구성
매칭에는 두 가지 유형의 관련 세션이 있습니다.
- 매치 티켓 세션(매치 메이킹 서비스에 대한 입력).
- 매치 대상 세션(출력).
세션 템플릿을 구성할 때 각 세션 유형별로 템플릿을 하나씩 만들어야 합니다.
티켓 세션의 경우, 정교한 템플릿을 사용할 것입니다. 아니면 로비 세션이나 게임 플레이에 사용되지 않는 다른 세션의 템플릿을 재사용할 수 있습니다.
Important
티켓 세션은 QoS(서비스 품질) 검사를 사용하지 않아야 하고 "게임 플레이" 기능이 표시되어 있지 않아야 합니다.
대상 세션의 경우, 매치가 성사되는 게임 플레이를 위한 템플릿을 사용해야 합니다. 게임 플레이를 시작하기 전에 피어 간에 QoS 검사를 사용하는 설정이 있어야 하고, "게임 플레이" 기능이 표시되어 있어야 합니다.
파트너 센터의 구성 UI를 이용하여 각 세션을 하나 이상의 호퍼에 매핑할 수 있고 그 각각에 해당 호퍼에서 세션들이 어떻게 한 데 매칭되는지 결정하는 규칙을 포함시킬 수 있습니다. 자세한 내용은 다음 매치 메이킹을 위한 기본 호퍼 구성을 참조하세요.
매치 메이킹을 위한 기본 호퍼 구성
이 섹션에서는 기본적인 호퍼 필드를 구성하는 데 사용되는 필드를 정의합니다. 이 구성을 마친 후 이 항목의 후반부에 있는 호퍼 규칙의 구성 섹션에서 설명하는 대로 호퍼 규칙을 구성해야 합니다. 다음 스크린샷은 호퍼 편집기를 보여줍니다. 이는 다음 섹션에 설명되어 있습니다.
이름
매치 메이킹에 세션을 제출하는 데 사용되는 호퍼의 이름입니다. 이 이름은 매치 티켓을 만드는 동안 XblMatchmakingCreateMatchTicketAsync 메서드에 매개 변수로 전달되는 값과 일치해야 합니다.
최소/최대 그룹 크기
호퍼의 세션에서 생성될 플레이어 그룹의 최소 크기와 최대 크기입니다. 매치 메이킹 서비스는 최대 그룹 크기까지 가능한 한 큰 매치 그룹을 생성하려고 시도합니다. 그러나 최소 그룹 크기를 충족하기에 충분한 플레이어들을 모을 수 있는 경우 매치 그룹을 생성합니다.
권고 규칙 확장 주기(Should Rule Expansion Cycles)
권고 규칙의 경우, 성공적인 매치가 발견되지 않을 경우 매치 메이킹 서비스는 시간이 지나면서 검색 공간을 늘리고 제공된 매치 메이킹 규칙을 완화하려고 시도합니다. 이 프로세스는 권고 규칙 확장 주기 필드를 사용하여 지정하는 대로 여러 주기에 걸쳐 수행됩니다.
마지막 확장 주기에서는 권고 규칙이 삭제되어 티켓들이 매치되는 것을 더 이상 막지 않습니다. 그러나 여러 개의 티켓이 제공되는 경우 최고의 매치를 결정하는 데 여전히 사용됩니다. 숫자와 QoS 유형만이 삭제되기 전에 확장됩니다.
자세한 내용은 이 항목의 후반부에 있는 호퍼 규칙 구성 섹션을 참조하세요.
권고 규칙 확장 주기 설정의 값을 높이면 권고 규칙 확장의 주기가 더 많이 제공됩니다. 그러나 이로 인해 매치 메이킹에 걸리는 시간도 늘어납니다. 대부분의 구성에서는 일반적으로 기본값 3이면 충분합니다.
중요
확장 주기는 5초의 고정 시간 간격으로 발생합니다. 마지막 확장 주기에서는 남은 매치 메이킹 시도에 대해 모든 권고 규칙이 더 이상 고려되지 않습니다.
순위가 지정된 호퍼
일반적으로 SmartMatch는 차단된 플레이어들이 매치되는 것을 방지합니다. 순위가 지정된 호퍼를 선택하면 플레이어가 이 시스템을 사용하여 스킬이 더 높은 플레이어를 피하는 것을 막기 위해 이 논리가 무시됩니다.
호퍼 규칙의 구성
이 섹션에서는 호퍼에 대한 규칙을 구성하는 데 사용되는 필드를 정의합니다.
일반 규칙 필드
이 섹션에 정의된 필드는 모든 호퍼 규칙에 공통으로 적용됩니다.
규칙 이름: 구성을 위해 규칙에 표시되는 식별 이름입니다.
규칙 유형: 규칙 유형입니다. 옵션으로 MUST(의무)와 SHOULD(권고)가 있습니다.
의무 규칙은 매치 메이킹이 성공하기 위해 충족되어야만 합니다.
권고 규칙은 성공적인 매치를 찾기 위해 완화 또는 제거될 수 있습니다.
이 프로세스에 대한 자세한 내용은 이 항목의 앞부분에 있는 규칙 확장 주기 섹션을 참조하세요.
데이터 형식: 매치 메이킹 규칙 특성의 데이터 형식입니다. 가능한 값은 다음과 같습니다.
- 숫자: 간단한 32비트 숫자값을 지정합니다.
- 문자열: 최대 128자의 유니코드 문자열을 지정합니다.
- 컬렉션: 문자열들의 배열을 지정합니다. 다운로드 가능한 콘텐츠(DLC), 스쿼드 멤버십, 또는 플레이어들의 역할 선호 설정을 식별할 때 이 값을 사용합니다.
-
서비스 품질: 매치 메이킹에 지연 시간 QoS 데이터를 포함시키기 위한 사용자 지정 데이터 형식을 지정합니다. 매치 메이킹 호퍼당 이러한 규칙을 하나만 사용해야 합니다.
참고 항목
이 제한이 여러분의 타이틀에 문제가 될 경우 DAM(개발자 계정 관리자)에게 문의하세요.
- 총 값: 제출된 매치 메이킹 값을 모두 합하는 사용자 지정 데이터 형식을 지정합니다. 이 값을 사용하여 결과 총합이 특정 범위 내에 있거나 특정한 값이 되도록 할 수 있습니다.
- 팀: 매치 메이킹 요청에 포함되는 플레이어의 팀을 위한 사용자 지정 데이터 형식을 지정합니다. 이 값을 사용하여, 한 매치 티켓 내의 플레이어들이 여러 팀 사이에 분할되는 것을 피할 수 있습니다.
데이터 형식별 규칙 필드
이 섹션은 일부 데이터 형식에는 적용되지만 다른 형식에는 적용되지 않는 규칙을 정의할 때 사용되는 필드를 정의합니다. UI는 어떤 데이터 형식이 특정 규칙에 적용되는지 명확히 할 수 있어야 합니다.
와일드카드 허용: 매치 티켓에서 해당 특성을 생략할 수 있는지 여부를 나타내는 값입니다. 특성이 생략되면 티켓은 이 특성의 값에 관계없이 다른 모든 티켓과 호환됩니다.
특성 원본: 데이터 형식 값의 원본입니다. 가능한 원본은 다음과 같습니다.
- 제공된 타이틀: 데이터 값이 매치 티켓에 제출됩니다.
-
사용자 통계 인스턴스: 데이터 값이
UserStatistics서비스에서 자동으로 검색됩니다.
특성 이름: 특성 값 원본의 이름입니다. 매치 티켓에 있는 속성 이름이거나 사용자 통계의 이름입니다.
기본값: 매치 메이킹 요청 시 값이 지정되거나 제공되지 않는 경우, 데이터 형식을 위한 기본값입니다. 와일드카드 허용 필드를 선택하고 값을 지정하지 않으면 기본값이 적용되지 않습니다.
가중치: 규칙의 중요성입니다. 이 가중치를 이용하여 매치 메이킹과 규칙 확장 시 어떤 규칙이 우선시되는지 나타낼 수 있습니다. 가중치 값은 양수여야 하며 기본값은 1입니다.
평면화 방식: 숫자 데이터 형식만 해당됩니다. 여러 값들이 특정 매치를 충족하기 위해 어떻게 결합되는지를 나타내는 값입니다. 이 값은 하나의 매치 티켓과 여러 매치 티켓에서 여러 플레이어들의 여러 값에 적용됩니다. 가능한 값은 다음과 같습니다.
- 최솟값/최댓값: 여러 매치 티켓의 여러 개의 값 중에서 가장 작거나 가장 큰 값을 사용합니다.
- 평균: 여러 매치 티켓에 있는 여러 개의 값들의 평균값을 사용합니다.
최대 차이: 숫자 데이터 형식만 해당됩니다. 특정 규칙을 충족하기 위해 비교되는 두 가지 값 사이에 허용되는 최대 숫자입니다. 권고 규칙의 경우, 이 값이 규칙 확장의 시작점입니다.
설정 작업: 컬렉션 데이터 형식만 해당됩니다. 설정값의 그룹을 매칭할 때 수행하는 작업입니다. 가능한 옵션은 다음과 같습니다.
교집합: 두 컬렉션 간의 교집합 양에 기초하여 이 둘을 매칭합니다. 이 설정을 사용하면 컬렉션 값이 비슷하거나 동일합니다.
차이점: 두 컬렉션 간의 차이의 정도에 기초하여 이 둘을 매칭합니다.
역할 선호: 역할 기반 게임 모드에서 플레이어의 역할에 대한 선호도에 기초하여 컬렉션을 매칭합니다.
대상 교집합: 설정 작업 구성의 일부입니다. 두 컬렉션이 매칭되기 전에 이 둘의 최소 교집합 또는 최대 차이입니다.
네트워크 토폴로지: 서비스 품질 데이터 형식만 해당됩니다. QoS에 사용되는 네트워크 토폴로지입니다. 가능한 값은 피어 투 피어, 피어 투 호스트, 클라이언트/서버입니다.
최대 대기 시간/조정 최대값: 서비스 품질 데이터 형식만 해당됩니다. 지정된 네트워크 토폴로지 내에서 매치 메이킹에 성공하기 위한 최대 지연 시간입니다.
이 값은 클라이언트-서버 서비스 품질 권고 규칙을 사용할 경우 (필수 지연 시간이 아니라) 조정값으로 처리됩니다.
참고 항목
이와 더불어, 호퍼에는 기본 평판 역할도 적용됩니다. 이러한 규칙은 삭제할 수 없으며, 매치 메이킹 시 평판이 올바로 처리되도록 하는 데 사용됩니다.
역할 대기 허용: 컬렉션 역할 선호 데이터 형식만 해당됩니다. 매치 서비스가 사용 가능한 모든 역할을 채우기 위해 매치 메이킹 티켓을 보유하는지를 지정합니다.
확장 변화량
각 확장 생성에 대해 제출된 규칙을 얼마나 완화할 것인지를 나타내는 값입니다. 이 확장 변화량은 최대 차이 값에 추가로 적용됩니다. 자세한 내용은 이 항목의 나중에 예제 1(규칙 확장)을 참조하세요.
이 확장 변화량을 사용하여 여러 가지 숫자 값을 서로 다른 속도로 확장할 수도 있습니다. 이는 확장 주기 구성 설정은 모든 규칙에 적용되기 때문에 확장 주기 구성 설정에서는 사용할 수 없습니다. 대신, 이 방식에서는 0.4와 같은 십진수 확장값을 사용합니다.
확장은 새 정수에 도달할 때에만 발생하며, 따라서 확장 주기의 수가 동일하더라도 여러 개의 확장 속도를 허용합니다.
QoS 확장(피어 투 피어, 피어 투 호스트)
피어 게임의 서비스 품질 형식 확장에서는 확장 변화량을 구성할 수 없습니다. 대신, 다음과 같은 확장 전략 중 하나를 사용해야 합니다.
256 미만의 MaxLatency
확장은 MaxLatency × 확장 주기에서 수행됩니다.
예를 들어 초깃값이 200이면 첫 번째 주기에 200이 사용되고 두 번째 주기에 400이 사용되는 방식입니다.
MaxLatency가 256보다 크거나 같음
확장은 50에서 MaxLatency 256까지 선형적으로 조정됩니다.
예를 들어 초깃값이 556이면 주기가 거듭되면서 이 값이 50에서 300까지 선형적으로 조정됩니다. 즉, 여섯 번의 주기를 선택할 경우 이 값은 50, 100, 150, 200, 250, 300이 될 것입니다. 주기를 5회로 선택하면 값이 50, 112.5, 175, 237.5, 300이 될 것입니다.
QoS 확장(클라이언트/서버)
전용 서버를 사용할 경우, 확장은 상대적 선호에 기초합니다. 초기 확장 주기에서는 가장 선호되는 서버만이 고려됩니다. 시간이 지남에 따라 덜 선호되는 다른 서버가 사용됩니다.
확장이 제대로 되도록 하기 위해서는 MaxLatency와 유사한 값 즉, 조정 최대값이라는 값이 필요합니다. 허용되는 최대 ping 시간으로 설정해야 합니다. 그러나 이 값은 ping 시간을 위한 절대 요구치를 제공하는 것이 아니라 플레이어가 제공하는 여러 가지 서버 ping 시간에 따른 상대적인 조정을 제공합니다.
허용되지 않는 ping 시간이 적용된 서버들은 요청 목록에서 삭제함으로써 배제할 수 있습니다.
예시 1(규칙 확장)
플레이어 레벨을 사용하여 매치 메이킹이 이루어지고 레벨이 서로 비슷한지 여부에 따라 플레이어가 느슨하게 매칭됩니다. 서로의 레벨 차이가 가장 작은 플레이어들이 선호됩니다.
- 플레이어 레벨 규칙
- 규칙 유형: 권고
- 데이터 형식: 숫자
- 최대 차이: 1
- 확장 변화량: 2
- 평면화 방식: 평균
기본적으로, 플레이어 레벨 간의 필수 차이는 1 이하입니다.
- 이 차이 내에서 매치가 발견되면 플레이어가 매칭됩니다.
- 초기 매치가 발견되지 않으면 반복할 때마다 플레이어 레벨 값이 2만큼 확장됩니다(기본적으로 반복 횟수는 3).
이 시나리오의 결과는 아래의 표와 같이 레벨 20의 플레이어를 위한 매치 메이킹 동작으로 나타납니다.
| 단계 | 잠재적 매치 후보들의 레벨 값 | 성공적인 매치를 위한 효과적인 레벨 차이 |
|---|---|---|
| 처음 제출된 값 | 19-21 | 1 |
| 확장 주기 1 | 17-23 | 3 |
| 확장 주기 2 | 15-25 | 5 |
| 확장 주기 3 | 13-27 | 7 |
확장 주기가 계속되면서 성공적인 매치를 위한 효과적인 레벨 차이는 증가하고 [최대 차이] 값은 변화하지 않습니다. 오직 플레이어 레벨 값만 완화됩니다.
예시 2(컬렉션 규칙)
게임에서는 플레이어가 사용할 수 있는 세 가지 유형의 DLC를 릴리스합니다. 이 매치 메이킹 규칙은 "DLC 전용" 게임 플레이 매치 메이킹에 적용되며, 플레이어가 다른 플레이어들과 매치를 성사시키려면 적어도 하나의 DLC를 소유하고 있어야 합니다.
- 플레이어 DLC 규칙
- 규칙 유형: 의무
- 데이터 형식: 컬렉션
- 설정 작업: 교집합
- 대상 교집합: 1
플레이어들이 자신의 DLC를 평가하여 다음 표에 표시된 값들을 자신의 매치 티켓에 제출합니다.
참고 항목
다음 표에서 컬렉션 값은 DLC의 소유권을 나타냅니다. 플레이어에게 DLC가 제공될 경우 값은 1로 설정됩니다. 그렇지 않은 경우 0으로 설정됩니다. |
| 플레이어 | 컬렉션 값 | 플레이어와 매치됨 | 참고 |
|---|---|---|---|
| 플레이어 1 | { "1", "1", "1"} | 3 | 모든 DLC를 소유함 |
| 플레이어 2 | { "0", "0", "0"} | 없음 | DLC를 소유하지 않음 |
| 플레이어 3 | { "1", "0", "0"} | 1 | 첫 번째 DLC를 소유함 |
이 예에서 대상 교집합이 2로 설정될 경우, 플레이어 1과 3은 매치되지 않습니다. 왜냐하면 이들 사이의 교집합은 오직 1뿐이기 때문입니다.
예시 3(이전 플레이어 피하기)
타이틀은 가장 최근에 플레이한 플레이어와의 게임을 피하는 것을 선호합니다.
- 규칙 유형: 의무
- 데이터 형식: 컬렉션
- 설정 작업: 차이
- 대상 교집합: 0
SmartMatch 구성 시 팀 규칙 정의
팀 규칙 구성
팀 규칙을 설정하려면 우선 파트너 센터에서 팀 규칙을 만들어야 합니다. 게임이 이 호퍼에서 매칭되는 티켓에서 생성할 것으로 예상되는 팀 크기를 입력하세요.
예를 들어 게임에서 4대4가 예상되는 경우 2개의 항목을 만들고 각각 최대 크기 4를 예상하면서 서로 다른 이름을 생성해야 합니다.
최소 팀 크기도 있습니다. 더 적은 플레이어들로 구성된 팀으로 플레이할 수 있는 게임의 경우에 사용하세요. 그렇지 않으면, 최소 크기와 최대 크기가 동일해야 합니다.
팀 규칙 사용
팀 규칙이 구성되면 분할을 하지 않고는 그룹을 여러 팀에 맞출 방법이 없는 경우 호퍼 내 티켓이 매칭되지 않습니다. 규칙은 이에 따른 팀 할당을 대상 세션의 members/constants/custom/matchmakingresult/initialTeam에 기록합니다.
참고 항목
이 할당은 그저 제안일 뿐입니다. 타이틀은 플레이어들을 다시 배열함으로써 티켓이 서로 다른 팀으로 분할되는 것을 계속 방지하면서도 더 나은 게임을 만들 수 있을 것이라고 판단할 지도 모릅니다.
진행 중인 게임을 위해 티켓이 만들어진 경우, 팀 규칙에 추가 정보가 필요하게 됩니다. 예를 들어, 8명의 플레이어가 4대4 게임을 하다가 플레이어 2명이 그만두거나 연결이 끊어진다고 가정해 보겠습니다. 타이틀은 빈 자리를 채우고 싶어하지만 게임이 플레이되는 동안에는 팀을 다시 섞을 수가 없습니다.
진행 중인 게임을 채우려는 시도는 PreserveSession 필드가 always(으)로 설정된 티켓들으 표시됩니다.
이 경우에는 팀이 이미 플레이어에게 할당되었기 때문에 타이틀은 현재 팀 할당을 지정하여 매치에서 각 팀에 얼마나 많은 공간이 비어 있는지 알 수 있도록 해야 합니다.
각 플레이어가 속한 팀의 이름을 제공하기 위해, 각 플레이어는 자신의 팀명을 게임 세션의 members/me/properties/system/groups에 기록합니다.
이 필드는 JArray입니다.
이전에 언급한 속성이 게임 세션에 기록된 후 한 플레이어가 더 많은 플레이어를 찾기 위해 세션에 티켓을 생성합니다. 해당 티켓이 실행되면 매치는 다시 members/constants/custom/matchmakingresult/initialTeam에 참가하는 플레이어로 구성된 제안된 팀을 기록합니다.
동등한 팀 선호
또한, 매치는 가장 큰 팀에서 먼저 성사됩니다. 즉, 가상의 4대4 호퍼에서는 4명으로 구성된 티켓이 남지 않을 때까지 플레이어가 4명인 티켓이 먼저 매칭됩니다. 그 다음에는 3명으로 구성된 티켓이 필요 시 싱글톤을 가져오면서 계속 이어지는 방식입니다.
이 같은 방식으로 유사한 크기의 티켓이 존재하고 다른 규칙에 의해 금지되지 않을 경우 일반적으로 이러한 티켓이 서로 경쟁하게 됩니다.
참고 항목
이렇게 하면 팀 규칙이 다른 규칙들보다 훨씬 더 높은 우선순위를 갖게 됩니다. 예를 들어 스킬이 높고 크기가 4인 티켓 1개(A), 스킬이 낮고 크기가 4인 티켓 1개(B), 그리고 스킬이 높고 크기가 1개인 티켓 4개(C-F)로 구성된 한정된 플레이어 그룹이 있다고 가정해 보겠습니다. 팀 규칙은 매치가 A, C, D, E, F가 아닌 A와 B의 매칭을 선호하게 합니다.
권고 변형
의무 규칙은 티켓이 생성될 때마다 분할되는 것을 막고 동등한 팀을 선호하는 정렬 방식을 제공합니다. 권고 규칙은 티켓이 마지막으로 생성될 때까지는 동일하지만 마지막 생성 시에는 동등한 팀을 선호하는 정렬 방식이 아직 작동하더라도 티켓들이 분할될 수 있습니다.