SmartMatch 매치메이킹 런타임 작업 구성
모든 SmartMatch 매치메이킹 구성은 파트너 센터를 통해 수행됩니다.매치메이킹 세션 템플릿 구성
매치메이킹에는 두 가지 유형의 관련 세션이 있습니다.- 매치 티켓 세션, 매치메이킹 서비스에 대한 입력입니다.
- 매치 대상 세션, 매치메이킹 서비스의 출력입니다.
티켓 세션에는 서비스 품질(QoS) 검사가 활성화되지 않아야 하며, “gameplay” 기능으로 표시되지 않아야 합니다.
매치메이킹을 위한 기본 호퍼 구성
이 섹션에서는 기본 호퍼 필드를 구성하는 데 사용되는 필드를 정의합니다. 이 구성 후에는 이 항목의 뒷부분에 있는 호퍼 규칙 구성 섹션에 설명된 대로 호퍼 규칙을 구성해야 합니다. 다음 스크린샷은 호퍼 편집기를 보여줍니다. 다음 섹션에서 이에 대해 설명합니다.Name
매치메이킹에 세션을 제출할 때 사용되는 호퍼의 이름입니다. 이 이름은 매치 티켓 생성 중에 XblMatchmakingCreateMatchTicketAsync 메서드에 매개 변수로 전달된 값과 일치해야 합니다.Min/Max Group Size
호퍼의 세션에서 생성될 플레이어 그룹의 최소 및 최대 크기입니다. 매치메이킹 서비스는 최대 그룹 크기까지 가능한 한 큰 매칭 그룹을 만들려고 시도합니다. 그러나 최소 그룹 크기를 충족할 수 있는 충분한 플레이어를 모을 수 있는 경우 매칭된 그룹을 만듭니다.Should Rule Expansion Cycles
SHOULD 규칙의 경우, 성공적인 매칭이 발견되지 않으면 매치메이킹 서비스는 시간이 지남에 따라 검색 공간을 확장하고 제공된 매치메이킹 규칙을 완화하려고 시도합니다. 이 프로세스는 Should Rule Expansion Cycles 필드를 사용하여 지정된 대로 여러 사이클에 걸쳐 수행됩니다. 마지막 확장 사이클에서 SHOULD 규칙은 삭제되어 더 이상 티켓이 매칭되는 것을 방지하지 않습니다. 그러나 여러 티켓을 사용할 수 있는 경우 최적의 매치를 결정하는 데 여전히 사용됩니다. 숫자와 QoS 유형만 삭제되기 전에 확장됩니다. 자세한 내용은 이 항목 뒷부분에 있는 호퍼 규칙 구성 섹션을 참조하세요. Should Rule Expansion Cycles 설정 값을 늘리면 SHOULD 규칙 확장을 위한 더 많은 사이클이 제공됩니다. 그러나 이 증가는 매치메이킹 지속 시간도 증가시킵니다. 기본값은 3이며, 이는 일반적으로 대부분의 구성에 충분합니다.확장 사이클은 5초의 고정된 시간 간격으로 발생합니다. 마지막 확장 사이클에서 모든 SHOULD 규칙은 매치메이킹 시도의 나머지 부분에서 더 이상 고려되지 않습니다.
Ranked hopper
일반적으로 SmartMatch는 차단된 플레이어가 매칭되는 것을 방지합니다. Ranked Hopper가 선택된 경우, 플레이어가 이 시스템을 사용하여 더 높은 스킬의 플레이어를 피하지 못하도록 이 로직이 우회됩니다.호퍼 규칙 구성
이 섹션에서는 호퍼에 대한 규칙을 구성하는 데 사용되는 필드를 정의합니다.공통 규칙 필드
이 섹션에 정의된 필드는 모든 호퍼 규칙에 공통입니다.- Rule Name: 구성 목적으로 규칙에 대해 표시되는 친숙한 이름입니다.
-
Rule Type: 규칙 유형입니다. 옵션은 MUST와 SHOULD입니다.
- MUST 규칙은 성공적인 매치메이킹을 위해 충족되어야 합니다.
- SHOULD 규칙은 성공적인 매치를 찾기 위해 완화되거나 제거될 수 있습니다. 이 프로세스에 대한 자세한 내용은 이 항목의 앞부분에 있는 Should rule expansion cycles 섹션을 참조하세요.
-
Data Type: 매치메이킹 규칙 속성의 데이터 유형입니다.
가능한 값은 다음과 같습니다.
- Number: 간단한 32비트 숫자 값을 지정합니다.
- String: 최대 128자의 유니코드 문자열을 지정합니다.
- Collection: 문자열 배열을 지정합니다. 이 값을 사용하여 다운로드 가능한 콘텐츠(DLC), 분대 멤버십 또는 플레이어의 역할 기본 설정을 식별합니다.
- Quality of Service: 매치메이킹에 지연 시간 QoS 데이터를 포함시키기 위한 사용자 지정 데이터 유형을 지정합니다. 매치메이킹 호퍼당 이러한 규칙은 하나만 사용해야 합니다.
[!NOTE] 이 제한이 타이틀에 문제가 되는 경우, 개발자 계정 관리자(DAM)에게 문의하세요.
- Total Value: 제출된 매치메이킹 값을 합산하는 사용자 지정 데이터 유형을 지정합니다. 이 값을 사용하여 결과 합계가 특정 범위 내에 있거나 정확한 값인지 확인할 수 있습니다.
- Team: 매치메이킹 요청에 포함된 플레이어 팀에 대한 사용자 지정 데이터 유형을 지정합니다. 이 값을 사용하여 단일 매치 티켓 내의 플레이어가 여러 팀으로 분할되는 것을 방지할 수 있습니다.
데이터 유형별 규칙 필드
이 섹션에서는 일부 데이터 유형에는 적용되지만 다른 데이터 유형에는 적용되지 않는 규칙을 정의하는 데 사용되는 필드를 정의합니다. UI는 특정 규칙에 적용되는 데이터 유형을 명확하게 할 수 있어야 합니다.- Allow Wildcards: 속성을 매치 티켓에서 생략할 수 있는지 여부를 나타내는 값입니다. 생략된 경우, 이 속성 값과 관계없이 티켓은 다른 티켓과 호환됩니다.
-
Attribute Source: 데이터 유형 값의 원본입니다. 가능한 원본은 다음과 같습니다.
- Title provided: 데이터 값이 매치 티켓에 제출됩니다.
- User stat instance: 데이터 값이
UserStatistics서비스에서 자동으로 검색됩니다.
- Attribute Name: 속성 값 원본의 이름입니다. 매치 티켓의 속성 이름 또는 사용자 통계의 이름입니다.
- Default Value: 매치메이킹 요청에 대해 값이 지정되지 않았거나 사용할 수 없는 경우 데이터 유형의 기본값입니다. Allow Wildcards 필드가 선택되고 값이 지정되지 않은 경우 기본값이 적용되지 않습니다.
- Weight: 규칙의 중요도입니다. 가중치는 매치메이킹 및 규칙 확장 중에 어떤 규칙이 우선순위를 갖는지 나타내는 데 사용할 수 있습니다. 가중치 값은 양수여야 하며 기본값은 1입니다.
-
Flatten Method: Number 데이터 유형만 해당됩니다.
매치를 충족하기 위해 여러 값이 결합되는 방식을 나타내는 값입니다.
단일 매치 티켓의 여러 플레이어에 대한 여러 값 및 여러 티켓에 걸쳐 적용됩니다. 가능한 값은 다음과 같습니다.
- Min/Max: 서로 다른 매치 티켓의 여러 값 중 최솟값 또는 최댓값을 사용합니다.
- Average: 서로 다른 매치 티켓의 여러 값의 평균 값을 사용합니다.
- Max Diff: Number 데이터 유형만 해당됩니다. 규칙을 충족하기 위해 비교되는 두 값 사이의 허용 가능한 최대 숫자 차이입니다. SHOULD 규칙의 경우, 이 값은 규칙 확장의 시작점입니다.
-
Set Operation: Collection 데이터 유형만 해당됩니다.
설정된 값 그룹을 매칭할 때 수행할 작업입니다. 가능한 옵션은 다음과 같습니다.
- Intersection: 두 컬렉션을 서로 간의 교집합 양에 따라 매칭합니다. 이 설정은 유사하거나 동일한 컬렉션 값을 초래합니다.
- Difference: 두 컬렉션을 서로 간의 차이 양에 따라 매칭합니다.
- Role Preference: 역할 기반 게임 모드에서 플레이어의 역할에 대한 기본 설정을 기반으로 컬렉션을 매칭합니다.
- Target Intersection: Set Operation 구성의 일부입니다. 두 컬렉션이 매칭되기 전의 최소 교집합 또는 최대 차이입니다.
- Network Topology: Quality of Service 데이터 유형만 해당됩니다. QoS에 사용되는 네트워크 토폴로지입니다. 가능한 값은 Peer to Peer, Peer to Host 및 Client/Server입니다.
-
Maximum Latency/Scaling Maximum: Quality of Service 데이터 유형만 해당됩니다.
지정된 네트워크 토폴로지 내에서 성공적인 매치메이킹을 위한 최대 지연 시간입니다.
이 값은 Client/Server Quality of Service SHOULD 규칙을 사용할 때 (필수 지연 시간이 아닌) 배율 값으로 처리됩니다.
[!NOTE] 또한 기본 평판 규칙도 호퍼에 적용됩니다. 이러한 규칙은 제거할 수 없으며 매치메이킹 중 평판의 올바른 처리를 보장하는 데 사용됩니다.
- Allow Waiting for Roles: Collection Role Preferences 데이터 유형만 해당됩니다. 매치 서비스가 사용 가능한 모든 역할을 채우기 위해 매치메이킹 티켓을 보유하는지 여부를 지정합니다.
확장 델타
각 확장 세대에 대해 제출된 규칙을 얼마나 완화할지 나타내는 값입니다. 확장 델타는 Max Diff 값에 추가로 적용됩니다. 자세한 내용은 이 항목 뒷부분의 예제 1(규칙 확장)을 참조하세요. 확장 델타를 사용하여 여러 숫자 값을 다른 속도로 확장할 수도 있습니다. 확장 사이클 구성 설정은 모든 규칙에 적용되므로 이를 통해서는 불가능합니다. 대신 소수 확장 값을 사용하는 접근 방식입니다. 예: 0.4. 확장은 새 정수에 도달할 때만 발생하며, 이는 동일한 수의 확장 사이클에서도 서로 다른 확장 속도를 허용합니다.QoS 확장(peer-to-peer, peer-to-host)
피어 게임에 대한 QoS 유형 확장의 경우, 확장 델타를 구성할 수 없습니다. 대신 다음 확장 전략 중 하나를 사용해야 합니다.- MaxLatency가 256 미만인 경우 확장은 MaxLatency × Expansion Cycle에서 수행됩니다. 예를 들어, 초기 값이 200이면 첫 번째 사이클에서는 200이 사용되고 두 번째 사이클에서는 400이 사용됩니다.
- MaxLatency가 256 이상인 경우 확장은 50에서 MaxLatency - 256까지 선형적으로 확장됩니다. 예를 들어, 초기 값이 556이면 값은 사이클 수에 따라 50에서 300까지 선형적으로 확장됩니다. 즉, 6개 사이클을 선택한 경우 값은 50, 100, 150, 200, 250 및 300이 됩니다. 5개 사이클을 선택한 경우 값은 50, 112.5, 175, 237.5 및 300이 됩니다.
QoS 확장(client/server)
전용 서버를 사용할 때 확장은 상대적 기본 설정을 기반으로 합니다. 초기 확장 사이클에서는 가장 선호되는 서버만 고려됩니다. 시간이 지남에 따라 덜 선호되는 다른 서버가 사용됩니다. 적절한 확장을 보장하기 위해 Scaling Maximum이라는 MaxLatency와 유사한 값이 필요합니다. 여전히 허용 가능한 가장 큰 핑 시간으로 설정되어야 합니다. 그러나 이 값은 핑 시간에 대한 절대적 요구 사항을 제공하는 대신 플레이어가 제공하는 다양한 서버 핑 시간에 대한 상대적 척도를 제공합니다. 허용할 수 없는 핑 시간의 서버는 요청 목록에서 제거하여 제외할 수 있습니다. 이 항목의 맨 위로 돌아가기.예제 1(규칙 확장)
플레이어 레벨은 매치메이킹에 사용되며, 플레이어는 레벨의 근접성에 따라 느슨하게 매칭됩니다. 레벨 차이가 가장 적은 플레이어가 선호됩니다.- Player Level Rule
- Rule Type: SHOULD
- Data Type: Number
- Max Diff: 1
- Expansion Delta: 2
- Flatten Method: Average
- 이 차이 내에서 매치가 발견되면 플레이어가 매칭됩니다.
- 초기 매치가 발견되지 않으면 플레이어 레벨 값이 각 반복에 대해 2씩 확장됩니다(기본적으로 세 번의 반복이 있음).
예제 2(컬렉션 규칙)
이 게임은 플레이어에게 사용 가능한 세 가지 유형의 DLC를 릴리스합니다. 이 매치메이킹 규칙은 “DLC 전용” 게임플레이 매치메이킹에 적용되며, 플레이어는 다른 플레이어와 매치메이킹되려면 최소한 하나의 DLC를 소유해야 합니다.- Player DLC Rule
- Rule Type: MUST
- Data Type: Collection
- Set Operation: Intersection
- Target Intersection: 1
다음 표에서 컬렉션 값은 DLC 소유권을 나타냅니다. DLC를 플레이어가 사용할 수 있는 경우 값은 1로 설정됩니다. 그렇지 않은 경우 0으로 설정됩니다. |
이 예에서 목표 교집합이 2로 설정된 경우, 플레이어 1과 3은 교집합이 1뿐이므로 매칭되지 않습니다.
예제 3(이전 플레이어 회피)
타이틀은 가장 최근에 함께 플레이한 플레이어와 게임을 회피하는 것을 선호합니다.- Rule Type: MUST
- Data Type: Collection
- Set Operation: Difference
- Target Intersection: 0
SmartMatch 구성 중 팀 규칙 정의
팀 규칙 구성
Team Rule을 설정하려면 파트너 센터에서 하나를 만들어 시작합니다. 게임이 이 호퍼에서 매칭된 티켓으로부터 만들 것으로 예상되는 팀 크기를 입력합니다. 예를 들어 게임이 4대4를 예상한다면, 각각 최대 크기 4와 다른 이름을 예상하는 두 개의 항목을 만들어야 합니다. 최소 팀 크기도 있습니다. 팀에 더 적은 플레이어로 게임을 할 수 있는 경우 사용합니다. 그렇지 않으면 최소 및 최대는 동일한 값이어야 합니다.팀 규칙 사용
Team Rule이 구성된 후, 호퍼 내의 티켓은 분할을 일으키지 않고 그룹을 팀에 맞출 방법이 없는 경우 매칭되는 것을 방지합니다. 이 규칙은 결과 팀 할당을 members/constants/custom/matchmakingresult/initialTeam 아래의 대상 세션에 기록합니다.이는 단순히 제안된 할당입니다. 타이틀은 플레이어를 재배치하여 여전히 티켓이 서로 다른 팀으로 분할되는 것을 방지하면서 더 나은 게임을 만들 수 있음을 발견할 수 있습니다.
PreserveSession 필드가 always로 설정된 티켓으로 표시됩니다.
이러한 경우 팀이 이미 플레이어에게 할당되었기 때문에, 타이틀은 매치가 각 팀에 얼마나 많은 자리가 열려 있는지 알 수 있도록 현재 팀 할당을 지정해야 합니다.
각 플레이어가 속한 팀 이름을 제공하기 위해 각 플레이어는 팀 이름을 members/me/properties/system/groups 아래의 게임 세션에 기록합니다.
이 필드는 JArray입니다.
앞서 언급한 속성이 게임 세션에 기록된 후, 한 플레이어가 더 많은 플레이어를 찾기 위해 세션에 대한 티켓을 만듭니다.
티켓이 이행되면 매치는 참여하는 모든 플레이어의 제안된 팀을 다시 members/constants/custom/matchmakingresult/initialTeam에 기록합니다.
균등한 팀 선호
또한, 가장 큰 팀부터 매치가 이루어집니다. 이는 가상의 4대4 호퍼에서 4명 플레이어 티켓이 먼저 함께 매칭되며, 4명 티켓이 남지 않을 때까지 계속됨을 의미합니다. 그런 다음 3명 티켓이 계속되어 필요에 따라 단일 플레이어를 끌어들이는 방식으로 진행됩니다. 이러한 방식으로 유사한 크기의 티켓은 다른 규칙에 의해 방지되지 않고 존재하는 경우 일반적으로 서로 대결하게 됩니다.이는 Team Rule에 다른 규칙보다 상당히 강력한 우선순위를 부여합니다.