PlayFab 사용: 모범 사례

아티클
07/11/2023

PlayFab의 사용량 기반 가격 책정 모델을 사용하면 타이틀의 실제 서비스 사용량에 대해서만 요금을 지불합니다. 하지만 이는 분명한 질문을 제기합니다. 필요한 모든 기능을 구현하면서 비용을 절감하기 위해 이 타이틀을 가장 잘 최적화하려면 어떻게 해야 하나요? 이 문서에서는 이러한 세부 사항을 자세히 살펴보고 미리 계획하는 데 도움이 되는 모범 사례에 대해 설명합니다.

타이틀을 개발 모드에서 라이브로 이동하기 전에 게임 관리자의 결제 요약 탭에서 미터 정보를 검토할 수 있습니다. 좋은 시작 방법은 별도의 타이틀로 실제 플레이어 활동에 대한 미터 사용량을 확인하여 주기적으로 미터를 확인하는 것입니다. 개발 모드에서 여러 타이틀을 사용할 수 있으므로 해당 사용량을 검사한 다음, 완료 후 해당 타이틀을 삭제하려는 개발 단계에 도달할 때 즉시 타이틀을 만들 수 있습니다.

이벤트, 프로필, 콘텐츠 및 구성, CloudScript, Insights 및 멀티 플레이어 서비스의 6가지 사용량 기준이 있습니다. 타이틀 최적화를 시작하는 가장 좋은 방법은 타이틀이 사용하는 각 미터를 살펴보고 시간이 지남에 따라 누적되는 방식을 확인하는 것입니다. 이를 통해 몇 가지 명확한 개선 사항을 신속하게 도출할 수 있습니다. 미터에 대한 자세한 내용은 가격 책정 미터를 참조하세요.

이벤트

PlayFab에는 PlayStream 및 원격 분석의 두 가지 이벤트 유형이 있습니다.

PlayFab은 PlayStream 이벤트를 처리하여 사용자가 정의한 PlayStream 작업을 트리거하는지 확인하고 사용자 구분을 업데이트합니다. 일부 PlayStream 이벤트는 인증 및 통계 업데이트와 같은 서비스 기능에 대한 호출의 결과로 자동으로 생성됩니다. 타이틀은 자체 사용자 지정 이벤트를 생성하여 이 기능을 확장할 수 있습니다.

원격 분석 이벤트는 PlayStream에서 처리되지 않습니다. 이러한 이벤트는 분석에 사용되며 데이터 웨어하우스로 바로 이동합니다. 원격 분석 이벤트는 PlayFab에서 자동으로 생성되지 않습니다. 타이틀에 의해 생성된 맞춤 이벤트입니다.

두 이벤트 유형 모두에서 데이터의 페이로드가 클수록 총 미터 사용량이 증가합니다. 필요한 데이터만 보내도록 하여 전체 사용량을 줄일 수 있습니다. 대략적인 지침은 지정된 이벤트가 이벤트 본문에 있는 데이터의 1KB마다 해당 미터를 1씩 증가시키는 것입니다.

사용량에 가장 적합한 이벤트 경로를 선택하려면 생성하는 각 사용자 지정 이벤트를 사용하는 방법에 대한 명확한 계획이 있어야 합니다. 타이틀의 오프라인 평가에만 필요한 이벤트는 원격 분석 경로로 이동해야 합니다. 원격 분석 이벤트에 대한 초과분 요금이 PlayStream의 절반 미만이므로 비용을 크게 줄이는 데 도움이 될 수 있습니다.

미리 빌드된 SDK 중 하나를 사용하는 경우 사용자 동작에 대한 일부 분석 데이터가 PlayStream 이벤트 모델 참조에 설명된 대로 자동으로 생성된다는 점을 기억해야 합니다. 선택적 이벤트를 해제하려면 PlayFab 게임 관리자에서 게임의 설정/데이터 수집 탭에서 분석 설정을 변경합니다. 마찬가지로 디버깅 중에 CloudScript 실행에 대해 "PlayStream 이벤트 생성" 옵션을 설정하는 것이 좋지만, 라이브로 전환하기 전에 이를 사용하지 않도록 설정해야 합니다. PlayStream 작업으로 CloudScripts가 트리거되면, 일부 동작을 디버그해야 하는 경우 나중에 언제든지 켤 수 있습니다.

프로필

프로필은 인벤토리, 저장된 데이터 및 통계와 같은 일반적인 요소를 포함하여 사실상 "플레이어에 대한 모든 것"입니다. 또한 위에서 언급한 사용자 구분과 같이 PlayStream의 LiveOps 기능을 통해 고유한 환경을 구동하는 데 사용하는 메타 정보도 포함되어 있습니다. 또한 데이터 구현이 사용자 데이터와 사실상 동일하므로 타이틀 데이터, 카탈로그 및 스토어와 같은 일부 타이틀 수준 레거시 기능이 이 미터에 포함됩니다. 이 미터 집합은 플레이어에 대해 수행되는 작업뿐만 아니라 모든 플레이어 작업에 의해 구동되므로 최적화 계획이 가장 필요한 대상입니다.

가격 책정 미터에서 캡처한 사용량의 주요 기여 요인은 읽고 저장하고 쓰는 데이터의 양과 계량된 데이터를 생성하는 API를 호출하는 빈도입니다.

이러한 미터에서 "스핀"을 발생시키는 특정 API 호출에 대한 자세한 내용은 가격 책정 미터를 참조하세요.

사용 패턴이 유사하기 때문에 사용자 데이터 및 통계부터 시작하여 플레이어 인벤토리 관리에 대해 살펴보겠습니다.

데이터 및 통계

사용자 데이터 사용을 평가할 때 이벤트와 동일한 근사치 논리가 적용됩니다. 각 1KB마다 미터 수가 1씩 증가하지만 호출의 각 "요소"를 이 계산을 위해 고유한 것으로 간주해야 합니다. 사용자 데이터를 업데이트하기 위한 호출의 각 키 값 쌍은 별도로 계산됩니다. 읽기의 경우, 키 값 쌍의 수에 관계없이 이 1KB 계산이 반환된 총 데이터에 적용됩니다. 즉, 각 키 값 쌍 쓰기는 최소 1KB이므로 각각에 100바이트 키를 10개 쓰면 프로필 쓰기 미터는 10개 “틱”이 되지만, 읽기는 총 1KB이므로 10개 키를 읽으면 1개 “틱”이 됩니다. 사용량에 대한 자세한 내용은 가격 책정 미터를 참조하세요.

통계는 프로필을 업데이트하고 순위표에 영향을 미칠 수 있으므로 약간 더 복잡합니다. 일반적으로 업데이트된 각 통계는 전체 프로필 업데이트로 생각할 수 있지만 읽기는 각 호출에서 읽은 데이터의 총 크기를 기반으로 합니다. 스토리지는 GB(기가바이트)당 가격이 책정되고 통계는 일반적으로 각각 몇 바이트만 사용하므로 읽기 및 쓰기에 집중합니다.

총 데이터 크기가 중요하므로 최적화하는 것이 첫 번째 단계입니다. 다행히 항목에 대해 맞춤법에 맞는 텍스트 대신 열거형 또는 ID를 사용하거나, 대용량 데이터를 이진으로 압축하거나, 비트 필드를 사용하여 데이터를 더 작은 공간으로 압축하는 등 널리 알려진 다양한 기술이 있습니다. 이 작업이 완료되면, 다음 단계는 이러한 읽기 및 쓰기 호출을 수행해야 하는 시기를 신중하게 평가하는 것입니다.

PC 또는 콘솔 개발(특히 단일 플레이어 게임)을 하는 경우 이는 새로운 패턴일 수 있습니다. 그러나 이러한 환경에서는 중요한 시간에 성능이 저하가 발생할 수 있으므로 클라이언트 디바이스에서 리소스 적중 및 가비지 수집에 주의해야 합니다. 타이틀에서 클라우드에 있는 리소스를 사용하는 경우 성능 비용 외에도 각 리소스 적중에 실제 비용이 드는 것으로 간주하도록 논리를 확장해야 합니다.

읽기 및 쓰기의 최적 빈도를 어떻게 결정하나요? 데이터 및 통계를 더 자주 업데이트하려는 개발자의 가장 일반적인 두 가지 문제는 부정 행위로부터 보호하고 플레이어 간 상호 작용을 위해 또는 게임이 예기치 않게 종료되는 경우 데이터 손실을 방지하기 위해 서버 쪽에 적시에 정보를 저장하는 것입니다.

치트 보호

백 엔드 데이터를 지속적으로 업데이트하여 필수 보안을 유지해야 하는 것처럼 보일 수 있지만, 게임에서 세션에 대한 서버 권한 제어가 필요하지 않은 경우 자주 업데이트해야 하는 경우가 거의 없습니다. 시작할 때 기본적인 질문은 실제로 필요한 보안 수준입니다.

일부 게임, 특히 게임 내 광고를 통해 수익을 창출하고 순위표가 없는 게임의 경우 부정 행위는 별로 중요하지 않습니다. 이 경우 데이터의 보안은 실제로 문제가 되지 않으므로 클라이언트가 전송하는 데이터를 신뢰하는 것이 실행 가능한 접근 방식인 경우가 많습니다. 부정 행위 행위를 식별하고 처리 방법을 결정하려면 플레이어의 이벤트, 데이터 및 통계를 검토하는 프로세스를 구현하는 것이 좋습니다.

경쟁의 무결성을 지원하거나 전체적인 플레이어 환경을 보호해야 하는 다른 게임의 경우 더 강력한 보안이 중요합니다. 특정 요구 사항에 따라, 특정 접근 방식을 사용하면 이러한 상황에서 데이터 읽기 및 쓰기 빈도를 줄일 수 있습니다.

게임이 실시간이 아닌 경우 권장되는 한 가지 방법은 일정 기간(종종 게임의 "라운드"이며 몇 분 정도 소요됨) 동안 플레이어의 게임에 대한 정보를 집계한 다음, 해당 데이터를 유효한지 여부를 결정하는 스크립트로 보내는 것입니다. 평가할 주요 요소는 게임에 따라 다르지만 고려해야 할 일반적인 개념의 몇 가지 예는 다음과 같습니다.

마지막 세션 보고서 이후의 기간과 클라이언트가 최신 세션에서 재생되었다고 말하는 기간은 얼마인가요?
플레이어가 등록한 점수는 무엇이며, 레벨, 장비 등을 고려할 때 해당 플레이어에게 적합한가요?

서버 권한이 있는 플레이어 상태를 자주 업데이트해야 하는 등 실시간 요구 사항이 더 많은 게임의 경우, PlayFab에 저장된 데이터에 대한 잦은 업데이트보다 더 나은 해결 방법은 호스트된 게임 서버를 사용하는 것입니다. 해당 모델에서는 세션을 시작할 때 플레이어와 서버를 연결합니다. 서버는 플레이어의 서비스에서 필요한 모든 데이터를 읽은 다음, 시간이 지남에 따라 해당 플레이어에 대한 시뮬레이션 상태를 호스트하며, 클라이언트는 필요한 속도로 데이터를 서버와 교환합니다. 그런 다음 서버는 세션이 끝날 때 또는 세션이 특히 긴 경우 몇 분마다 플레이어에 대한 최신 데이터로 PlayFab의 "장기 스토리지"를 업데이트합니다.

실시간 멀티 플레이어 게임에서 사용되는 모델입니다. 서버 권한 점검이 필요한 단일 플레이어 타이틀에 유효한 기술이기도 하지만, 해당 빈도가 플레이어당 1분당 몇 번만인 경우 Azure Functions CloudScript가 더 나은 옵션이 될 수 있습니다. 총 CloudScript 비용은 쉽게 계산할 수 있습니다. 실행당 최소 128MB 및 100ms와 스크립트에서 사용하는 다른 서비스 API 호출에 대한 일반 계산을 포함하여 소비한 총 기가바이트 초입니다. 예를 들어, 총 메모리 사용량이 스크립트 코드와 스크립트의 가변 사용량 사이인 250MB인 경우, 1GB/s에 액세스하려면 해당 스크립트를 4초(여러 사용자 간에) 동안 실행해야 합니다. 또한 해당 스크립트 코드 내에서 엔터티 개체, 타이틀 데이터, 사용자 데이터 등을 읽거나 쓰는 경우 각 호출이 프로필 미터에서 수행하는 스핀을 계산해야 합니다. 호스트된 게임 서버 비용은 실행 중인 서버 수에 따라 달라지며 차례로 한 번에 서버에서 호스트할 수 있는 플레이어 수에 따라 달라지므로, 손익분기점이 둘 사이의 위치를 결정하는 것은 반드시 간단한 것은 아닙니다. 그러나 스크립트를 높은 빈도로 호출해야 하고 매번 서비스에서 데이터를 읽고 써야 하는 경우 게임 서버 솔루션이 더 나은 방법일 가능성이 높습니다.

데이터 타임라인

프로필 쓰기 속도가 높은 개발자들의 일반적인 주제 중 하나는 플레이어가 진행 상황 손실을 염려한다는 것입니다. 플레이어가 게임을 저장하기 전에 종료하고 다음에 게임을 플레이할 때 로컬 상태를 사용할 수 없거나, 해당 상태가 장치 간에 이동해야 하는 경우, 플레이어에 대한 PlayFab에 저장된 상태 정보를 가능한 한 최신 상태로 유지하려고 합니다.

많은 게임의 경우 서비스에 대한 정기적인 업데이트 하트비트(예: 15분마다)를 통해 이 문제를 해결할 수 있습니다. 그러나 해당 빈도를 늘리거나 줄이는 추가 논리를 포함하는 것도 도움이 될 수 있습니다. 예:

손실이 없도록 플레이어가 중요한 작업을 적극적으로 수행하는 경우, 즉시 쓰기가 필요하고 타이머를 다시 설정하는 "중요 업데이트" 재정의를 포함합니다.
플레이어 입력 없이 게임이 계속 진행되는 경우 오랫동안 입력이 없으면 하트비트 기간을 연장하는 것이 좋습니다. 이는 플레이어가 밤새 게임을 자주 실행하는 유휴 게임에 특히 중요합니다.
플레이어가 사용자 메뉴의 버튼과 같이 직접 업데이트를 강제할 수 있는 방법을 제공하세요. 그러나 이 경우 클라이언트 장치에서 PlayFab으로 실제로 호출되는 속도를 조절하여 해당 버튼을 반복해서 누르는 플레이어가 매번 호출을 생성하지 않도록 해야 합니다.

다음에 게임을 플레이할 때 클라이언트에게 상태 정보가 있는 경우, 로컬에서 타임스탬프와 서비스의 데이터를 비교하고 사용할 항목을 결정하거나 플레이어에게 선택할 옵션을 제공할 수 있습니다.

플레이어의 프로필 정보는 단순히 그 이상과 관련이 있을 수 있습니다. 일부 게임에서 비동기 친구 상호 작용, 챌린지 등을 통해 플레이어 경험에 직접 영향을 주거나 경쟁에 영향을 줄지 여부를 교차 플레이어에게 쿼리하는 데 필요할 수 있습니다.

경쟁의 경우 순위표는 서비스에 대한 단일 호출을 통해 다른 플레이어(종종 현재 플레이어의 점수에 근접한 플레이어)에 대한 정보의 하위 집합을 공유하여 긴장을 생성하는 이상적인 방법입니다. 프로필 보기 제약 조건을 사용하여 통계 및 태그와 같은 다른 프로필 요소를 반환할 수 있으므로 이와 같은 다른 플레이어에 대한 풍부한 정보 집합을 표시할 수 있습니다. 그러나 프로필 읽기 수가 급속히 증가하고 비용이 늘어나므로, 순위표의 모든 플레이어 목록을 반복하지 않고 각 플레이어의 추가 정보를 읽는 것이 중요합니다.

세션에서 직접 플레이어 간 데이터를 사용하는 게임의 경우, 로컬 플레이어가 상호 작용하는 몇몇 특정 플레이어에 대한 정보만 읽는 것이 가장 좋습니다. 실시간 작업 게임의 경우 이 작업은 일반적으로 세션을 호스트하는 서버에서 수행됩니다. 다른 게임(예: 플레이어가 서로의 베이스를 공격할 수 있는 게임)의 경우, 가장 일반적인 방법은 해당 모든 데이터를 로컬 장치로 읽거나 로컬 플레이어가 알고 있어야 하는 다른 플레이어 데이터의 하위 집합만 로컬 플레이어에게 보내는 것입니다. 전자를 수행하는 게임은 서버 쪽 논리를 사용하여 클라이언트가 보내는 최종 결과를 평가합니다. 후자를 수행하는 게임은 로컬 플레이어가 액세스 권한이 있어야 하는 경우 더 많은 데이터로 세션 과정 동안 데이터를 반복적으로 업데이트합니다. 그러나 그런 경우에도 서버 쪽 논리를 사용하여 최종 결과를 평가합니다. 다시 말하지만, 스크립트를 통해 또는 호스트된 서버에서 이 작업을 수행할지 여부를 결정하는 티핑 포인트는 빈도입니다. 1분에 몇 번 이상 걸리는 경우 해당 데이터가 필요한 세션 부분에 호스트된 서버를 사용하는 것이 좋습니다.

경제 및 인벤토리

인벤토리와 경제는 일반적으로 다른 접근 방식이 필요합니다. 플레이어가 실제(금액) 또는 인식된(가상 통화 또는 소모성 컨테이너) 값을 포기할 경우 해당 트랜잭션이 적용될 것이라는 기대를 암시합니다. 앱에서 바로 구매하는 게임의 경우, 실제 통화로 플레이어가 구매하기 위해 프로필 미터를 증가시키는 데 드는 비용은 많지 않습니다. 많은 유형의 게임에서 인벤토리 업데이트는 전체 사용량이 크게 증가하는 것을 걱정하지 않을 정도로 드물게 발생합니다. 그러나 인벤토리 업데이트(게임 내 수익 창출이 없는 경우에도)가 더 빈번한 게임의 경우, 비용을 절감할 수 있는 최적화 요령이 있습니다.

가장 좋은 방법은 문자 그대로 인벤토리를 합리적으로 유한한 인벤토리로 생각하는 것입니다. 예를 들어, 증분(또는 "유휴") 게임에서는 플레이어가 획득하는 각 리소스를 아이템으로 생각하여 플레이어가 다른 리소스를 구매할 때마다 총 수를 증분할 수 있습니다. 하지만 플레이어가 이 작업을 수행하는 빈도를 계산할 때 해당 모델은 빠르게 중단됩니다. 즉시 세션에서 미터를 수백 또는 수천 번 누르는 각 플레이어를 처리해야 합니다. 이와 같은 상황에서는 해당 요소를 사용자 데이터로 간주하고 위의 프로필 섹션의 권장 사항을 사용하여 서비스로 업데이트하는 것이 좋습니다.

인벤토리 업데이트 속도가 더 높은 게임의 경우 데이터 타임라인에 대한 질문으로 돌아갑니다. 예를 들어, 액션 게임은 플레이어가 가지고 있는 글머리 기호 수를 추적할 수 있지만, 특히 게임 상태가 호스트된 서버에서 관리되는 경우 트리거가 발생할 때마다 해당 글머리 기호의 "스택"에 대한 백 엔드 데이터를 업데이트할 필요가 없습니다. 스택형은 항목의 많은 가상 인스턴스를 개수가 포함된 단일 실제 인스턴스로 나타낼 수 있으므로 성능 및 비용상 이점을 제공합니다. 종종 시간이 지남에 따라 항목 스택에 대한 변경 내용을 집계하고 세션이 끝날 때 또는 세션 전체에서 주기적으로 업데이트할 수 있습니다. 스택을 업데이트할 때는 플레이어 아이템 관리 - 아이템 사용 수정을 호출하여 스택에 추가하기 위해 각각 처리하고 정리해야 하는 항목의 N 인스턴스를 추가하는 대신 스택 수를 변경할 수 있는지 여부를 확인하는 것이 좋습니다.

기본적으로 수집 가능한 카드 게임과 같은 특정 게임 장르는 플레이어 인벤토리를 약간 더 높은 속도로 업데이트해야 합니다. 하지만 여기에서도 인벤토리 변경 내용을 집계하고 프로필 미터의 총 사용량을 줄일 수 있는 기회가 있습니다. 예를 들어 드롭 테이블을 사용하는 게임에서는 여러 드롭 테이블 각각에서 하나 이상의 "끌어오기"가 있는 컨테이너를 사용하는 디자인이 많습니다. 일반적으로 이러한 끌어오기 작업이 가끔씩만 수행되는 경우 증분 비용은 문제가 되지 않을 정도로 적습니다. 그러나 플레이어가 해당 컨테이너를 많이 수집하고 짧은 시간 내에 배수를 열 수 있는 경우 "N개 열기" 또는 "모두 열기" 옵션을 제공할 수 있습니다. 이 경우 Azure Functions를 사용하는 PlayFab CloudScript 또는 사용자 지정 게임 서버를 사용하여 드롭 테이블 집합에 대해 플레이어 아이템 관리 - 임의 결과 테이블 가져오기를 쿼리하거나 인벤토리 항목을 생성하지 않고 플레이어 아이템 관리 - 임의 결과 테이블 평가를 호출합니다. 그런후 필요한 경우에만 인스턴스를 추가한 다음 나머지의 항목 스택 수를 업데이트하여 플레이어 인벤토리를 훨씬 더 효율적으로 업데이트할 수 있습니다.

콘텐츠 및 구성

프로필이 주로 플레이어에 관한 경우 콘텐츠 및 구성은 주로 타이틀에 관한 것입니다. 푸시 알림, 전자 메일 서비스 및 타이틀 뉴스와 같은 여러 타이틀 수준 구성 요소가 모두 이 미터에 포함되어 있습니다. 또한 엔터티 파일 사용량을 추적하는 데 사용되는 미터입니다. 마찬가지로 CDN 파일 업로드 및 다운로드를 위한 URL 요청은 이 미터에서 추적되지만 CDN 비용은 별개이며 CDN(Content Delivery Network)에 설명된 대로 다운로드한 총 기가바이트에 따라 청구된다는 점을 명확히 하는 것이 중요합니다. 콘텐츠 및 구성 읽기와 스토리지 미터의 계산은 데이터 크기를 기반으로 한다는 점에서 프로필 미터와 유사하지만 분명히 단위는 1KB보다 훨씬 큽니다. 콘텐츠 및 구성 쓰기 미터의 경우 쓰기 작업의 총 수만을 기반으로 하며 각각 미터를 1씩 증분합니다.

참고로 엔터티 파일 시스템은 타이틀, 그룹 또는 개별 플레이어와 연결되었는지 여부에 관계없이 대용량 데이터에 권장되는 서비스입니다. 플레이어당 대용량 데이터 저장을 사용하는 게임의 경우, 엔터티 파일 시스템이 일반적으로 더 비용 효율적이지만, 이 업데이트의 빈도는 추적되는 사용량에 영향을 줍니다. 업데이트해야 하는 빈도에 대해 필요한 파일 수를 최적화하는 것이 가장 좋습니다.

콘텐츠 및 구성 미터에서 비용을 최적화하려면 가장 중요한 것은 타이틀이 거의 변경되지 않는 자체 구성 데이터를 요청해야 하는 빈도입니다. 주로 게임 밸런스/튜닝 데이터, 도전 과제 정의, 지역화 데이터 등 모든 사용자 간에 동일한 게임의 다양한 측면을 관리하는 데 일반적으로 사용되는 타이틀 데이터입니다.

CloudScript를 사용하는 게임의 경우, 스크립트 호출마다 이 타이틀 수준 데이터에 종속성이 있는 경우 해당 데이터를 스크립트에 직접 "만드는" 것이 좋습니다. 스크립트 자체에서 하드 코드된 데이터로 정의하거나 캐싱 수단으로 정적 변수를 사용하여 VM(가상 머신) 인스턴스당 한 번씩 서비스에서 정보를 읽는 간단한 방법으로 이 작업을 수행할 수 있습니다. 이렇게 하면 지정된 VM에서 스크립트를 처음 실행할 때 타이틀 수준 데이터가 로드되고 후속 실행 시 해당 VM에서 다시 사용됩니다. 여기서 유의해야 할 세 가지 사항: 첫째, 스크립트는 여러 사용자가 사용하므로 실행 사이에 개별 사용자에 대해 일관된 것으로 간주해서는 안 됩니다. 둘째, 단일 플레이어가 각 호출에 대해 서로 다른 컴퓨터에 충돌할 수 있으므로 데이터 처리를 상태 비저장으로 간주해야 합니다. 마지막으로, 해당 데이터의 사용 기간을 추적하고 주기적으로 다시 로드하여 최신 버전인지 확인해야 합니다.

CloudScript

이는 PlayFab 서비스의 주요 "확장 조인트" 중 하나로, 클라이언트 장치 또는 서버에서 서버 권한 논리를 실행하거나 PlayStream 규칙(예: 플레이어가 세그먼트에 입장할 때)을 통해 트리거할 수도 있습니다. 사용자 지정 게임 서버 호스팅과 달리, 실행당 최소 128MB 및 100ms로 스크립트가 실행되는 기가바이트 초(GB/s)에 대해서만 요금을 지불합니다. 따라서 스크립트가 스크립트 코드와 데이터 사이에 총 250MB의 공간을 사용하는 경우, 1GB/s에 이르려면 여러 실행에서 총 4초를 실행해야 합니다.

CloudScript에 대한 사용 사례는 일반적으로 플레이어를 대신하여 조치를 취하는 것을 중심으로 진행되므로, 프로필 및 콘텐츠/구성 미터에 대한 마지막 두 섹션에서 최적화에 대해 고려해야 하는 대부분의 사항을 다루었습니다. 그러나 타이틀에 대한 총 실행 횟수는 CloudScript 사용량 계량의 일부로 추적되므로, 플레이어별로 CloudScript를 호출해야 하는 빈도를 검토하는 것이 중요합니다. 일부 게임의 경우, CloudScript에 대한 반복 호출에서 데이터 저장소를 관리하지 않고 호스트된 게임 서버를 사용하여 활성 플레이어를 위해 "최신" 데이터 저장소를 사용하는 것이 훨씬 더 비용 효율적일 수 있습니다.

인사이트

이 미터는 이벤트 수집 및 내보내기부터 이벤트 기록 검색 및 데이터 탐색기 쿼리까지 PlayFab 서비스의 모든 분석 기능과 연결됩니다. 여기에 있는 사용량은 처리된 이벤트가 필요한 속도, “최신” 상태(게임 관리자의 쿼리용)로 호스트할 이벤트 데이터의 양, 데이터에 직접 연결하는 데이터 탐색기 쿼리 또는 시각화 소프트웨어를 통해 서비스를 사용하여 데이터를 평가하는 데 사용하는 양에 따라 영향을 받습니다. 이 미터는 게임 내 활동(이벤트) 및 게임 외 활동(분석)의 영향을 받습니다.

결국 Insights에 대한 비용은 플레이어로부터 얻는 이벤트 데이터의 양과 해당 데이터에 대해 수행하는 분석 처리량에 따라 달라집니다. 모범 사례 측면에서 위의 이벤트에 대한 조언은 전자에 적용되지만 후자의 경우 두 가지 방법으로 비용을 제어할 수 있습니다. 첫째, 가장 간단한 방법은 타이틀에 대한 게임 관리자의 Insights 관리 탭에서 총 스토리지를 설정하여 PlayFab에서 보유하는 총 이벤트 데이터의 양을 제어하는 것입니다. 그런 다음, 동일한 탭에서 타이틀의 성능 수준을 설정할 수 있습니다. 이는 타이틀에 할당된 총 CPU 리소스 양과 이벤트 기록의 쿼리에 대해 "최신"으로 저장된 데이터의 양을 결정합니다. 각각에 필요한 정도는 데이터 분석 팀 구성원의 요구 사항에 따라 달라지므로, 설정이 무엇인지 파악하기 위해 데이터 분석 팀 구성원과 함께 이를 검토하는 것이 가장 좋습니다.

Insights 및 사용 방법에 대한 자세한 내용은 PlayFab Insights란?을 참조하세요.

Insight 모범 사례에 대한 자세한 내용은 모범 사례 및 FAQ를 참조하세요.

멀티 플레이어 서비스

가격 책정은 완전히 변경되지 않으므로 이 방법이 가장 간단합니다. 즉, 호스트된 멀티 플레이어 서버 및 Party 서비스는항상 사용량에 따라 요금이 청구되었습니다.

특히 호스트된 게임 서버의 경우, 가능한 한 많은 플레이어를 지원하기 위해 지정된 시간에 실행해야 하는 서버 코어 수를 최적화하여 비용을 최소화할 수 있습니다.

이 서버에서 ping 시간 저하가 중요한 경우 서버를 실행할 지역을 선택할 수 있습니다. 대부분의 게임에서, 플레이어의 최대 집중은 특정 주요 지역으로 제한되지만, 플레이어 수가 광범위하게 분산되어 있는 경우(특히 소규모 게임인 경우) 플레이어 근처의 모든 지역에서 서버를 실행하는 비용과 플레이어가 적은 지역의 플레이어 하위 집합에서 ping 시간이 길어지는 영향을 고려해야 합니다. 한 가지 지원 방법은 QOS 서비스를 사용하여 플레이어를 배치할 지역을 선택한 다음, 한 지역에서 플레이해야 하는 최소 플레이어 수에 대한 컷오프를 결정하는 것입니다.

비용을 소진하지 않고 개발을 진행할 수 있도록 호스팅 서비스에서 상당한 무료 서버 시간을 제공하며, 모든 개발 모드 타이틀에는 Party 서비스가 무료입니다. 또한 Microsoft Party 서비스는 Xbox Live로 로그인한 플레이어는 무료로 사용할 수 있으며, Standard, Premium 및 Enterprise 계층의 타이틀의 경우 추가 비용 없이 연결, 음성 및 Cognitive Services(음성 필사 및 번역)을 제공하므로 CVAA(21St Century Communications and Video Accessibility Act) 규정 준수에 도움이 됩니다.

라이브 게임 관리

미터의 기본 사항을 다루지만 타이틀이 라이브 상태가 되면 어떻게 생각해야 하나요? 플레이어 커뮤니티를 관리하는 데는 주로 분석(위 섹션에서 Insights) 및 콘텐츠 및 구성 업데이트가 포함됩니다. 또한 대부분의 게임은 게임 자체와의 정상적인 상호 작용 이외의 플레이어와 소통해야 합니다. 재참여 캠페인(플레이어가 돌아오도록 유도하기 위해)부터 메타 게임 활동에 대한 커뮤니티 보상, 게임 밖의 커뮤니티 작업에 대해 플레이어에게 감사하는 것까지, 요즘은 LiveOps 기술을 사용하여 플레이어의 높은 참여를 유지하는 것이 일반적입니다.

이에 대한 한 가지 핵심은 비용을 절감할 뿐만 아니라, 논리가 신속하게 처리되도록 잘 정의된 그룹으로 효과적으로 분할하는 것입니다. 예를 들어, 플레이어가 일정 기간 동안 플레이를 중지한 후 플레이어가 다시 참여하게 됩니다. 이를 위한 좋은 방법은 경과된 여러 사용자 시간 프레임(3일, 7일, 21일 동안 플레이하지 않은 플레이어)을 정의하는 것입니다. 각각에 대해 간단한 "우리는 당신이 그리워요" 메시지로 시작하여 "여기에 약간의 무료 금/에너지/기타가 있습니다” 메시지로 절정에 이르는 재참여에 대해 다른 접근 방식을 취할 수 있습니다(물론 플레이어의 계정에 자동으로 추가하는 것과 함께). 각 항목에 대해 권장되는 방법은 플레이어가 게임을 플레이하기 위해 마지막으로 로그인한 시간을 기준으로 1시간 창을 정의하는 것입니다. 이렇게 하면 마지막 플레이 시간을 대상으로 할 뿐만 아니라, 최대한 효율적으로 작업을 수행할 수 있도록 세그먼트의 플레이어 집합을 최소화합니다. 각 세그먼트에서 1시간마다 한 번씩 실행되는 예약된 작업을 사용하여 메시지를 보내고 플레이어 인벤토리에 아이템 또는 VC(가상 통화)를 추가합니다.

요약

궁극적으로 PlayFab과 같은 백 엔드 서비스의 사용을 결정하는 것은 게임에 필요한 기능입니다. 실제로 이러한 기능에 대해 어떤 요구 사항이 있는지에 대한 전반적인 질문으로 요약됩니다. 보안, 데이터의 시간 표시 막대, 플레이어 상호 작용/경쟁 수준 또는 완전히 다른 항목의 우선 순위를 지정하든, 백 엔드 데이터와의 더 높은 수준의 상호 작용으로 푸시할 수 있는 여러 가지 요인이 있습니다. 신중하게 이러한 요구 사항을 살펴보고 어려운 요구 사항과 그렇지 않은 것을 파악할 수 있다는 것은 게임의 다른 코드를 최적화하는 것과 매우 비슷합니다. 리소스 사용률이 높은 위치를 신중하게 살펴보고 실제로 필요한지 또는 사용량을 줄이기 위해 해당 논리를 다시 디자인할 수 있는 방법이 있는지 결정하는 것이 중요합니다.

플레이어 간 상호 작용이 실시간 이루어지는 경우 상호 작용의 복잡성에 달려 있습니다. 이와 같은 게임의 대부분은 시뮬레이션 상태를 관리하고 세션이 끝날 때(또는 세션이 긴 경우 몇 분마다) 백 엔드 데이터만 업데이트하는 호스트된 서버가 가장 적합한 솔루션입니다. 그러나 공동 작업 게임이나 친구와만(또는 상대 ) 플레이한 게임과 같이 상호 작용이 완전히 신뢰할 수 있는 경우가 많기 때문에 치트 인센티브가 최소화됩니다. 다른 플레이어도 세션의 데이터를 확인해야 하는 방법에 대한 최소한의 요구 사항만 있으므로 두 플레이어가 각 세션 후에 보고서를 제출하기만 하면 서버 쪽 검사에서 두 보고서를 비교할 수 있습니다.

실시간 요구 사항이 없는 모든 게임의 경우 플레이어가 실제로 최신 정확도를 필요로 하는지를 파악합니다. 강력한 커뮤니티 상호 작용이 있는 매우 경쟁적인 게임에서는 매우 적합할 수 있습니다. 하지만 많은 게임의 경우 몇 분이 지난 정보는 플레이어 환경에 영향을 주지 않습니다.

전망

서비스로서 PlayFab은 계속 발전하고 있으며, 필요한 기능을 제공하는 서비스를 사용하는 동안 비용을 관리에 도움이 되도록 설명서를 계속 업데이트할 예정입니다. 이를 개선할 수 있는 방법에 대한 제안이나 생각이 있는 경우 기본 사이트에서 연락처 양식을 통해 언제든지 팀에 문의하세요. 염두에 두고 있는 기능을 최적화하는 방법에 대한 피드백이나 PlayFab 사용에 대한 일반적인 기술 질문이 있는 경우, 커뮤니티 포럼을 통해 또는 유료 서비스 계층에 있는 경우 PlayFab 게임 관리자에서 티켓을 제출하여 지원 팀에 문의할 수 있습니다(타이틀의 아무 페이지에서나 오른쪽 상단 모서리에 있는 ?를 클릭하세요). 개발자 커뮤니티와의 파트너 관계를 통해 지속적으로 성장하고 요구 사항을 미리 파악하는 데 필요한 피드백을 제공하므로 여러분의 의견을 항상 환영합니다!