순위표 참조 아키텍처
이들 참조 아키텍처는 순위표 사용 사례와 다양한 대안을 포함하는 구현을 설명하며, 개발자가 자신의 클라우드 솔루션을 설계하여 게임 디자인에 완벽하게 맞는 모든 제어 및 사용자 지정을 구현할 수 있도록 합니다.
팁
즉시 사용할 수 있는 순위표 솔루션을 찾고 있는 경우 PlayFab은 순위표 지원이 포함된 클라우드 연결 게임을 빌드, 출시 및 확대하기 위한 완전한 백엔드 플랫폼입니다.
순위표 디자인
순위표를 정의할 때 고려할 수 있는 다양한 변수가 있습니다. 예를 들어 다음을 고려해야 합니다.
- 지리: 플레이어가 위치한 실제 위치입니다. 대륙, 지역, 국가 등 원하는 만큼 세밀하게 지정할 수 있습니다. 예: 프랑스, 중국, 미국, 북아메리카, 아시아, EMEA.
- 플랫폼: 게임이 플레이되는 디바이스 또는 서비스입니다. 둘 이상의 플랫폼을 결합하는 순위표를 사용하는 것도 고려할 수 있습니다. 예: Xbox, PlayStation, PC, iOS, Android, 모바일, 콘솔.
- 모드: 게임 플레이를 변경하고 다른 게임 메커니즘의 작동 방식에 영향을 주는 고유한 구성입니다. 예: 솔로, 듀오, 스쿼드, PvE, PvP, 캠페인.
- 난이도: 사용자가 선택한 챌린지입니다. 예: 쉬움, 보통, 어려움.
- 옵션: 플레이어가 선택한 개별 옵션입니다. 예: 캐릭터(인간, 차량), 아이템(무기, 도구), 설정(수동 또는 자동 전환).
- 레벨: 게임 내 레벨 또는 스테이지입니다. 예: 레벨 2-1, 트랙 3.
- 통계: 플레이어가 사용량 또는 동작에 따라 생성하는 개별 값입니다. 예: 점수, 승수, 패수, 수집된 코인.
플레이어 인증 및 ID
이 참조 아키텍처는 플레이어 인증 또는 플레이어 ID를 다루지 않습니다. 두 가지 모두 독자를 위한 연습입니다.
PlayFab은 여러 형태의 인증을 제공하므로 여러 디바이스에 걸쳐 플레이어를 추적할 수 있습니다.
- 게스트 로그인을 위한 장치 ID
- 사용자 이름/암호
- Google 계정
- GameCenter 계정
- Facebook 계정
- Steam 계정
- Kongregate 계정
- Twitch 계정
- 기타 oAuth 공급자
- Android 장치 ID
- 사용자 지정 플레이어 ID
크기 및 복잡도
순위표는 점수를 기반으로 플레이어 순위를 결정하는 매우 간단한 시스템에서 시작하여 여러 통계, 옵션, 레벨, 플랫폼 등의 조합을 추적하여 크기와 복잡도를 늘릴 수 있습니다. 예를 들어 플랫폼, 지리, 모드, 레벨 및 통계 변수가 결합된 순위표를 가정해 보겠습니다. 그러면 "프랑스(지리)에서 Xbox One(플랫폼)을 사용하는 플레이어의 플레이어 대 플레이어(모드) 레벨 3(레벨) 점수(통계)"와 같은 값을 사용하여 게임 시나리오에 있는 플레이어의 순위를 지정할 수 있습니다. 이 데이터를 추적하면서 지리 필터를 제거하여 거주 위치에 관계없이 모든 플레이어의 순위를 설정할 수 있습니다.
다른 예에서는 시스템, 레벨 및 통계 변수를 결합한다고 가정합니다. 그러면 "PC(시스템)에서 경쟁하는 플레이어가 트랙 Nürburgring(레벨)을 완주하는 데 걸린 시간" 등 레이스 게임 시나리오에서 플레이어의 순위를 지정할 수 있습니다.
물론 특정 게임에는 플레이어 간 순위를 지정하는 더 많은 방법이 있을 수 있습니다. 제공된 샘플 구현은 위의 변수 중 몇 가지만 사용하는 출발점입니다. 이 사용 사례에서 플레이어의 점수는 두 가지 변수 플랫폼 및 레벨을 기반으로 순위가 결정됩니다. 각 플랫폼의 플레이어가 각 레벨에서 최고 점수를 위해 경쟁합니다. 여기에서 게임의 필요에 맞게 자유롭게 수정하세요.
데이터 새로 고침
오래된 데이터를 사용하는 순위표는 순위표가 아예 없는 것만큼 나쁠 수 있습니다. 그러나 비용 문제 때문에 데이터를 빈번히 새로 고치지 않을 수는 있습니다. 1분에서 심지어 1시간까지 순위를 재계산할 새로 고침 간격을 시도해 보세요. 경우에 따라 하루에 한 번 새로 고치는 것도 무방할 수 있습니다. 그러나 순위표 데이터를 실시간(근 실시간)으로 새로 고쳐야 하는 경우에는 이 참조 아키텍처가 적합합니다.
내 주변 플레이어
사용자가 순위표 어디에 있는지 표시하는 것이 모범 사례입니다. 그러면 플레이어가 자신의 위 또는 아래에 누가 있는지, 어디까지 순위를 올릴 수 있는지 알 수 있습니다. 이는 플레이어에게 게임 상위 랭커만 표시하여 순위를 올리려는 의지를 꺾지 않으면서 얼마나 쉽게 순위를 올릴 수 있는지 보여주기 때문에 보다 참여적인 플레이어 기반에 기여할 수 있습니다.
부정 행위 방지
일부 플레이어가 순위표에 가짜 점수를 삽입하려고 시도할 수 있으며, 이는 커뮤니티에 부정적인 영향을 줄 것입니다. 부정 행위를 어렵게 만들기 위해 다음과 같이 몇 가지 조치를 시도할 수 있습니다.
- 클라이언트와 클라우드 간 통신을 암호화하여 패킷 스니핑을 방지합니다.
- 원격 분석을 추가하고 서버 쪽에서 사용하여 점수가 적절한지 확인합니다. 이상적으로는 자동으로 확인하여 즉각적으로 부정 점수를 감지해야 합니다. 두 가지 간단한 확인은 다음과 같습니다.
- 플레이어가 표시된 시간에 레벨을 완료하는 것이 현실적으로 가능한가요?
- 플레이어가 얼마나 자주 점수를 제출하나요?
- 잘못된 점수를 삭제하면 안 됩니다. 대신, 의심되는 점수를 제출한 플레이어와 점수를 함께 표시합니다(잘못하여 선의의 사용자에게 악영향을 줄 수 있으므로 신중해야 함). 이후 확인된 선의의 플레이어가 순위표에 액세스하면 잠재적으로 부정 행위로 표시되지 않은 점수만 검색합니다. 부정 행위 플레이어가 순위표 보기 요청을 제출하면 잘못된 점수만 검색합니다. 이는 부정 행위 플레이어에게 가짜 점수 삽입이 실패했다는 직접적인 피드백을 제공하지 않아 해당 시도가 성공한 것으로 믿게 만든다는 아이디어입니다.
참조 구현 세부 정보
순위표 정보를 저장할 데이터베이스를 선택할 때 가장 먼저 관계형 또는 비관계형(NoSQL) 데이터 구조 중 무엇을 사용할지 결정해야 합니다. 다음과 같은 몇 가지 차이점을 염두에 두어야 합니다.
| 관계형 | 비관계형 | |
|---|---|---|
| 준비 | 데이터의 구조/스키마를 미리 결정해야 합니다. 나중에 변경할 경우 중단 요인이 될 수 있습니다 | 필요한 최소 구조 |
| 엄격성 | 모든 데이터는 동일한 구조를 사용해야 합니다. | 각 데이터 항목은 고유한 구조를 가질 수 있으며 나중에 새 필드를 쉽게 추가할 수 있습니다. |
| 기본 저장소 모델 | 테이블 기반 | 문서 저장소, 그래프 데이터베이스, 키-값 저장소 또는 와이드 컬럼 저장소 |
| 확장성 | 수직 확장 가능 - 서버 CPU, RAM 또는 스토리지 증가 | 수평 확장 가능 - 분할 또는 서버 추가 |
다양한 저장소 모델에 대한 자세한 내용은 올바른 데이터 저장소 선택 설명서를 참조하세요.
마지막으로, 각 대안에 대한 개인 전문 지식이 고려할 사항입니다. 알려진 경로를 선택하면 전혀 새로운 문제들을 해결하고 새 모범 사례 및 개념에 익숙해지는 데 걸리는 시간을 절약할 수 있습니다.
다음은 간단한 순위표 사용 사례를 시작하는 두 가지 구현 방법입니다.
- 비관계형(NoSQL): 소규모에는 Azure Cache for Redis를 사용하고 대규모에는 Azure Cosmos DB를 사용합니다.
- 관계형: 소규모에는 Azure SQL Database 또는 MySQL을 사용하고 대규모에는 Azure SQL Database를 사용합니다.