다음을 통해 공유


서버 backfill 티켓 사용

때때로 서버에서 호스팅되는 게임은 추가 플레이어를 검색해야 합니다. 대부분 이 경우는 게임 진행 중 한명 이상의 플레이어가 연결을 끊을 때 발생합니다. 서버 backfill 티켓을 통해 게임 서버는 현재 플레이 중인 게임에 맞는 추가 플레이어를 검색할 수 있습니다.

서버 backfill 티켓은 여러 가지 면에서 일반 매치 메이킹 티켓과 다릅니다.

  1. 매치 중
    • Backfill 티켓은 서로 매치할 수 있습니다.
    • backfill 티켓은 검색할 때 우선 순위가 부여됩니다. 이렇게 하면 플레이어 기반의 조각화가 줄어 듭니다.
  2. 계약
    • ServerDetails 필드와 함께 backfill 티켓이 만들어질 수도 있습니다. 이렇게 하면 서버가 일치하는 플레이어를 어떻게 연결해야 하는지 나타내는 것을 허용합니다.
    • 팀 할당과 함께 backfill 티켓이 만들어질 수도 있습니다. 게임의 팀을 팀 정보와 함께 유지하도록 허용합니다.
  3. 대기 속성
  4. 소유권
    • backfill 티켓은 게임 유저가 아니라 서버가 소유합니다. 유저는 어떤 방식으로든 backfill 티켓을 보거나 상호 작용할 수 없습니다.

서버 backfill 티켓 생성하기

backfill 프로세스는 정규 매치 메이킹 티켓을 만드는 것과 비슷하지만 CreateServerMatchmakingTicket 호출과는 달리 CreateServerBackfillTicket 호출로 시작합니다. 게임 서버는 현재 호스팅하고있는 게임에 대한 모든 맴버의 정보를 제공해야 합니다. 이것은 이전 매치 결과에 반환된 속성을 저장함으로써 가장 효율적으로 수행됩니다. 이 속성들은 매치하기ReturnMemberAttributes 플래그와 함께 호출함으로 검색할 수 있습니다. 대안으로, 게임 서버는 유저에게 속성 정보에 관해 문의할 수 있습니다.

멤버들 외에도, 게임 서버는 2개의 추가 정보를 지정할 수 있습니다.

서버 세부 정보

이 구조는 매치하기 호출에서 반환된 구조와 동일하며, 서버가 연결에 필요한 모든 정보를 지정할 수 있습니다. backfill 티켓이 매치하면 매치 결과에서 GetMatch 을 호출하는 모든 플레이어에게 ServerDetails 구조가 반환됩니다. 이 구조의 모든 필드는 선택 사항입니다. 타이틀은 클라이언트가 게임 서버에 연결할 수 있는 충분한 정보를 제공하기 위해 이들 중 일부만 필요합니다.

참고 항목

IPV4Address 필드는 검증되지 않고 클라이언트에게 임의의 연결 문자열 정보를 제공하는 데 사용될 수 있습니다.

{
  "ServerDetails": {
    "IPV4Address": "123.234.123.234",
    "Ports": [
      {
        "Port": {
          "Name": "portname",
          "Num": 12345,
          "Protocol": "UDP"
        }
      }
    ],
    "Region": "EastUS"
  }
}

팀 지정

backfill 티켓을 팀과 함께 대기 목록에 제출하는 경우 각 팀원은 팀 ID를 사용하여 현재 해당 팀의 팀원임을 나타낼 수 있습니다. 이 멤버십은 매치가 반환될 때 보존됩니다. 팀 ID가 유저에 대해 지정되지 않은 경우 팀 ID가 모든 팀에 배치 될 수 있습니다.

{
  "Members": [
    {
      "TeamId": "red",
      "Entity": {
        "Id": "6570DE3537DC9DF6",
        "Type": "title_player_account",
        "TypeString": "title_player_account"
      },
      "Attributes": {
        "DataObject": {
          "Skill": 25
        }
      }
    }
  ]
}

backfill 티켓과 상호 작용하기

일단 생성되면, backfill 티켓은 규칙 기준을 충족시키는 정규 매치 메이킹 티켓을 찾기 시작합니다. backfill 티켓의 흐름은 유사한 API를 제외하고는 일반 매치 메이킹 티켓이 작용하는 방식과 동일합니다. 게임 서버는 GetServerBackfillTicket호출을 통해 티켓 상태를 확인할 수 있습니다. GetServerBackfillTicket호출을 통해 티켓을 취소할 수도 있습니다.

참고 항목

클라이언트는 backfill 티켓을 취소할 수 없습니다. 클라이언트가 4v4 매치에 있었고 상대 팀의 플레이어가 떨어졌다고 가정합시다. 클라이언트는 backfill 티켓을 계속 취소하여 해당 이점을 유지할 수 있습니다. 그러므로 이를 방지하기 위해 게임 서버만 backfill 티켓을 취소할 수 있습니다.

맴버십 제한 및 분실된 backfill 티켓 복구

정규 매치 메이킹 티켓과 마찬가지로 항상 유저는 대기 목록당 하나의 backfill 티켓에만 있을 수 있습니다. 이 제한은 클라이언트가 제어하는 일반 티켓과 별도로 추적됩니다.

게임 서버가 backfill 티켓을 만든 다음 충돌이 발생하는 경우 손실된 backfill 티켓의 사용자는 멤버십 제한으로 인해 다른 backfill 티켓에 제출할 수 없습니다. 게임 서버는 MatchmakingTicketMembershipLimitExceeded 오류와 함께 errorDetails 본문에 미해결 backfill 티켓이 있는 사용자 목록을 받아 해당 사항을 발견할 것입니다.

{
    "code": 400,
    "status": "BadRequest",
    "error": "MatchmakingTicketMembershipLimitExceeded",
    "errorCode": 2055,
    "errorMessage": "User is a member of too many backfill tickets.",
    "errorDetails": {
        "UsersExceedingMembershipLimit": [
            "title_player_account!562D72A5B184F612"
        ]
    }
}

게임 서버는 유저가 있는 모든 backfill 티켓을 제거하는 CancelAllServerBackfillTicketsForPlayer을 호출하여 이 상황에서 유저를 복구할 수 있습니다. ListServerBackfillTicketsForPlayer 또한 플레이어가 어떤 backfill 티켓을 발견했는지를 알 수 있는 방법으로 제공됩니다.

지역 선택 규칙과의 상호 작용

지역 선택 규칙은 일반적으로 티켓이 해당 속성에 대한 대기 시간 측정 배열을 지정하도록 요구합니다. 그러나 backfill 티켓은 특정 데이터 센터에서 이미 진행 중인 게임을 나타냅니다. 대기 시간 측정 배열 대신에 생성 요청은 ServerDetails 구조에서 지역을 지정해야 합니다. backfill 티켓과 일치하는 티켓의 경우 backfill 티켓에서 지정한 영역에 대해 허용되는 핑 (ping) 시간을 가져야 합니다.

팀 티켓 크기 유사성 규칙과의 상호 작용

팀 티켓 크기 유사성 규칙은 많은 수의 플레이어 그룹이 다른 대규모 그룹의 플레이어와 매치하게 합니다. 그러나 backfill 티켓에는 그룹으로 참가한 플레이어의 정보가 포함되어 있지 않습니다. 따라서 backfill 티켓을 매칭할 때는 티켓 크기 유사성 규칙이 무시됩니다.