인디 개발사 Bit Dragon이 Hyper Jam의 크로스 플랫폼 플레이를 구현한 방법

안녕하세요. 저는 멜버른에 본사를 둔 스튜디오 비트 드래곤(Bit Dragon)의 공동 설립자 조디 홀(Geordie Hall)입니다. 신시사이저 음악과 함께 다이내믹한 특전 뽑기 시스템을 갖추고 빠른 속도로 진행되는 최초 타이틀의 아레나 격투 게임 하이퍼 잼(Hyper Jam)이 PC, PS4, Xbox One을 통해 2월 13일에 출시된다는 사실을 전해드리게 되어 매우 기쁩니다.

비록 저희는 작은 규모의 팀이지만 저희가 공개하는 게임은 로컬, 초대, 크로스 플랫폼 매치메이킹(로컬 플레이어 추가) 방식으로 즐길 수 있습니다. 이 게임을 만드는 동안 정말 놀라운 것을 배웠고, 저희 팀은 거의 해보지 않은 방법이 없을 정도로 많은 시도를 해야 했습니다. 저는 하이퍼 잼 제작에 언리얼 엔진을 선택해 정말 다행이라고 생각합니다. 언리얼 엔진은 프로그래머 셋으로 구성된 소규모 팀도 이렇게 뛰어난 멀티 플레이어 게임을 만들 수 있게 해 주는 툴이니까요.

보세요! 진행 속도가 이렇게나 빠르다니까요!

크로스 플레이를 구현하기 위한 여정

많은 인디 멀티 플레이어 게임처럼 저희 게임 역시 피어 투 피어 방식의 서버를 사용하는 비밀 로비 방식에 집중해 온라인 실험을 진행했습니다. 하지만 더 나은 넷코드를 생각하다 보니 비교를 위한 전용 서버를 만들기로 했습니다. 처음 테스트 플레이를 했을 때 게임이 호주의 인터넷에서도 정말 괜찮은 성능을 보인 것에 저희 모두가 감동했습니다. 일단 크로스 플랫폼 공개를 염두에 두자 전용 서버 비용을 더욱 합리화할 수 있었을 뿐 아니라, 가능성이 있는 크로스 플레이 매치메이킹을 시도해 볼 가치를 느꼈습니다.

크로스 플랫폼 매치메이킹이 갖는 큰 장점이 몇 가지 있는데, 그 중 가장 큰 장점은 매치메이킹에 참가하는 플레이어가 많다는 것입니다. 대규모 게임이라면 대기 시간을 줄여 플레이어 환경을 개선하는 게 중요하지만, 소규모 게임에서는 매치를 기다리다 실망만 하는 경우가 많습니다. 매치메이킹 참여자를 공유하면 플랫폼의 평이 좋지 않아 단일 플랫폼의 사용자가 없는 경우의 위험도 줄일 수 있습니다. 이는 나쁜 평가로 인한 효과를 상쇄하고 게임의 생명력을 길게 하죠. 크로스 플랫폼 파티를 지원하는 데 성공한다면, 게임 참여자를 크게 확보하는 겁니다!

그럼 인디 게임에서 크로스 플레이를 어떻게 달성할까요? 온라인 서비스 경험이 처음이라면 매우 가파른 학습 곡선을 보이겠지만 생각하는 것 이상의 고비를 넘어야 할 겁니다. 다행히 많은 회사가 온라인 게임 서비스를 통합하고 배포하기 위해 노력하고 있기 때문에 점점 더 쉬워질 겁니다! 심지어 에픽 역시 내년 중 개발자들이 선택할 수 있는 옵션 중 하나인 크로스 플랫폼 온라인 서비스 툴(suite of cross-platform online services)을 공개할 예정이니까요.

저희처럼 멀티 플랫폼 온라인 게임을 개발했다면 저희가 크로스 플레이를 어떻게 구현했는지 설명한 이 글을 통해 크로스 플레이를 시작해 보세요.

전용 서버

전용 서버는 크로스 플레이의 중요한 전제 조건이라고 할 수 있습니다. 만약 피어 투 피어 방식의 리슨 서버를 사용한다면 리슨 서버를 호스트로 하여 다른 플랫폼에 연결할 수 없다는 걸 이미 아실 겁니다. 각 플랫폼은 플랫폼의 NAT 횡단을 처리하는 고유의 넷드라이버를 가지고 있습니다(예를 들어 SteamNetDriver는 스팀 소켓(Steam Socket)을 처리합니다). 하지만 크로스 플레이를 구현하려면 각 플랫폼을 싱글 서버에 연결한 뒤 동일한 언어로 "대화"해야 합니다(예를 들면 표준 IpNetDriver를 사용할 수 있습니다). 만약 (저희처럼) 프라이빗 매치에서는 여전히 리슨 서버를 사용하고 싶다면, 런타임에 사용하는 넷드라이버를 변경해야 합니다.

이미 알고 있는 플레이어 간 프라이빗 매치에는 P2P가 좋은 대안이지만 매치메이킹 방식에서는 다음과 같은 단점 때문에 좋은 선택이라고 할 수 없습니다.

• QoS가 괜찮은 경우에도 우수한 플레이어 경험은 호스트 인터넷 연결에 의존
• 클라이언트 예측 격투 게임에서 고려해야 할 호스트 우위
• 호스트 마이그레이션의 어려움. 호스트 마이그레이션이 되지 않는다면 다른 참가자의 게임 내용도 망칠 수 있음
• 호스트를 신뢰할 수 없어 랭크 모드를 배제해야 함

전용 서버가 있다면 이 모든 문제를 해결할 수 있지만, 호스트 비용이 가장 큰 단점이라고 할 수 있습니다. 인디 게임으로서는 증가하는 비용을 합리화하기 어려울 수 있지만, 크로스 플랫폼 공개를 결심한 뒤에는 투자도 결정할 수 있었습니다.

기존에 리슨 서버만 사용해 왔다면 전용 서버가 두려울 수 있지만 사실 어렵지 않습니다. Windows와 Linux 중 어디에나 서버를 구축할 수 있지만, Linux 인스턴스가 Windows 인스턴스보다 저렴하기 때문에 Linux 빌드를 구축하는 데 시간을 투자하는 것이 효과적입니다. 다행히 언리얼 엔진 4를 사용한다면 이 모든 게 어렵지 않습니다! 크로스 컴파일 툴 체인 설치(install the cross-compile toolchain) 를 완료했다면 Linux를 대상 플랫폼으로 선택할 수 있습니다. 클랭은 전통적으로 VC++보다 까다로웠지만 점점 유사해지고 있습니다. 플러그인이 Linux를 지원하는지도 확인해야 하며 전용 서버에서는 위젯이나 사운드 등을 실행하지 않으므로 코스메틱 오브젝트를 제외한 게임 플레이 로직을 유지해야 합니다.

기본적으로 전용 서버는 헤드리스(headless)로 실행되어 간단하게 파일에 로깅합니다. 하지만 "-log" 인수를 추가하여 로그 창을 시작할 수도 있습니다. 이는 개발 중에 매우 유용할 수 있습니다. 전용 서버는 CI(Continuous Integration) 파이프라인에 통합하기가 매우 쉽습니다. UAT 인수 하나만 추가하면 되니까요! Linux 서버를 테스트하는 경우 로컬 VM 또는 EC2 인스턴스를 사용할 수 있지만 대부분의 개발 테스트에는 Windows 서버만 있어도 충분합니다. PIE에서 전용 서버를 사용할 수도 있는데, 이는 블루프린트 디버깅에 적합합니다.

클라우드 호스팅

전용 서버 바이너리를 확보하고 넷코드가 잘 실행되면 클라이언트가 서버에 연결할 수 있도록 서버를 호스팅해야 합니다. 아마존 게임리프트(Amazon GameLift), 구글 클라우드(Google Cloud), 컴퓨트/쿠버네츠(Compute/Kubernetes), 플레이패브(PlayFab) 등 호스팅 옵션은 다양합니다. 여기서 주목해야 할 점은 비용, 스케일 그리고 지원입니다.

플레이어 수요에 따라 서버 크기를 늘리거나 줄일 수 있어야 합니다. 피크 시간대를 제외하면 최대한 작게 유지하는 것이 이상적입니다. 이러한 시스템 대부분은 특정 IP가 할당된 가상 머신을 사용할 것이며 각각 다른 포트에서 수신 대기하는 N개의 서버 프로세스를 실행합니다. 서버 관리자는 각 서버 프로세스에 게임 세션을 할당하고 어떤 세션이 사용 중인지 추적합니다. 인스턴스의 유휴 서버 프로세스 수가 특정 임계 값 아래로 떨어지면 시스템이 또 다른 VM을 가동시켜 N개의 게임 세션을 추가합니다. 스케일링 시스템은 지능적으로 새로운 세션을 할당하여 스케일 다운을 허용하고 리소스를 효율적으로 사용해야 합니다(5개의 게임 세션을 5대의 기기에 분산시키고 싶지는 않을 테니까요).

대부분의 제공 업체는 여러 개의 무료 단계가 있어 자유롭게 실험하고 다양한 구성을 시도해 보며 감각을 익힐 수 있습니다.

인디 게임에서 비용은 항상 중요하며 서버 비용을 낮추기 위해 감당할 수 있는 추가 작업과 비용 사이에서 균형을 찾아야 합니다. 스케일 비용을 계산할 때 주로 사용하는 수식은 "서버당 플레이어 x 인스턴스 당 서버 x 동시 플레이어 수"입니다. 게임리프트 요금 안내 페이지에서는 전형적인 플레이어 수요 곡선과 이것이 온종일 필요한 인스턴스 수에 어떤 영향을 미치는지 보여 줍니다. 그러나 인디 게임에서는 이러한 수치가 높아 보일 수 있습니다.

CPU와 메모리에 맞춰 게임을 최적화하면 각 인스턴스에 맞는 서버 수를 늘릴 수 있으므로 비용을 낮출 수 있습니다. 네트워크 트래픽에 요금이 부과될 수 있으므로 넷코드 최적화는 게임 플레이에도 도움이 되지만 실제 서버 요금도 개선할 수 있습니다!

새로운 플레이어를 참가시키기 위해 모든 지역에서 최소 하나의 인스턴스를 실행하기를 원하겠지만, 가용성 요구 사항에 따라 추가 확장을 위해 클라우드 서비스 제공자가 갑자기 종료할 수 있지만 할인율은 높은 스팟/프리엠티브 인스턴스를 활용할 수도 있습니다.

출시 전 예상 플레이어 수를 고려한 예상 비용을 예측하여 서버 비용과 가치를 따져 보는 것도 좋은 생각입니다. 출시 후에도 이에 대한 월간, 연간 평가를 계속해야 합니다. 때로는 (P2P로 다시 전환하고) 서버를 종료하는 것도 고려하는 것도 좋습니다.

CI 파이프라인이 이미 있는 경우 클라이언트 빌드와 함께 게임 서버 업로드도 자동화할 수 있습니다. 야간 빌드를 테스트를 실행할 수 있는 옵션이 있다면 상당히 유용할 수 있습니다. 그러나 호스트의 저장 공간 제한 등에 유의해야 합니다.

출시 전이라면 비용과 수요를 감안해 서버를 호스팅할 지역을 선택하는 것도 어려울 수 있습니다. AWS와 구글 클라우드는 전 세계에 걸쳐 폭넓은 서비스를 제공하며, AWS의 경우 최근 중국에서도 게임리프트를 시작했습니다. 매치메이킹 중계자에 플레이어 대기 시간 데이터를 전달하면 플레이어 수요 발생지를 더욱 분명히 파악할 수 있으며 일부 서버에 적합한 지역을 확인할 수 있습니다.

트래픽이 "가장 잘" 처리되도록 하기 위해 출시 전 오버 프로비저닝을 원할 수도 있습니다. 출시일이 다가오면 지원도 중요할 것입니다. 분명 이상이 발생하여 최대한 많은 도움이 필요할 것이기 때문입니다. 아마 지금 제가 처한 상황일 겁니다!

매치메이킹

게임 수신을 기다리는 확장 가능한 전용 서버군을 준비했다면 실제로 플레이어를 매칭하는 방법이 필요합니다. 대부분 플랫폼은 퍼스트파티 매치메이킹 API가 있지만, 크로스 플레이를 위해서는 서버 관리자와 통신을 할 수 있는 중앙형 매치메이킹 방법이 필요합니다.

호스팅과 마찬가지로 게임 백엔드에도 호스팅, 매치메이킹, 클라이언트 제공 SDK를 제공하는 완전 통합 솔루션부터 서버와 매치메이킹은 제공하지만 인증 및 클라이언트 통신을 처리하기 위해 자체 백엔드가 필요한 공급자에 이르기까지 다양한 옵션이 있습니다.

적어도 하나의 클라이언트는 특정 파라미터를 바탕으로 매칭하기 위해 백엔드와 통신할 수 있어야 합니다. 백엔드는 각 플랫폼의 인증 토큰을 사용해 요청을 인증하고 이를 매치메이킹 풀에 추가합니다. 매치가 발견되면 매치메이커는 게임 세션을 서버에 할당하고 각 클라이언트에 서버의 IP와 포트를 안내하며 서버에 참가를 허용해야 하는 플레이어를 비롯해 팀 또는 게임 유형 등 매치메이킹에 유용한 데이터를 전달해야 합니다.

다양한 옵션을 평가할 때는 현재 요구 사항만이 아니라 추가하면 좋은 기능을 배제하지 않도록 미래 가능성까지 생각하는 것이 좋습니다. 다음과 같은 내용을 생각해 볼 수 있습니다.

• 매치메이킹은 규칙 기반입니까 로비 기반입니까?
• 시간이 지남에 따라 규칙을 완화할 것입니까?
• 대기 시간 정보를 고려할 것입니까?
• 동시에 여러 게임 유형에 대한 대기열을 허용할 것입니까?
• 매치메이킹에서 파티를 지원할 것입니까?
• 크로스 플랫폼 파티입니까?
• 여러 명의 로컬 플레이어를 지원합니까?
• 팀플레이를 지원합니까? 파티가 팀을 구성할 수 있습니까?
• 플레이어가 대기 중 게임 내에서 다른 행동이 가능한 비동기 매치메이킹을 지원합니까?
• 플랫폼 간 동시 매칭에 제한이 있습니까? (결국 "아니요!"가 될 것입니다.)
• 회피 또는 차단 목록이 필요합니까?
• 스킬 기반 및 또는 랭킹 모드가 가능하도록 영구적인 플레이어 데이터에 액세스해야 합니까?
• 다른 사용자가 진행 중인 경기에 참여할 수 있도록 다시 채우기를 지원합니까?

지금 구체적인 조언을 제시한다 해도 금방 구식이 될 것입니다. 그러나 언제나 최고의 조언은 최대한 빨리 시작하라는 것입니다.

매치메이킹 기능을 평가할 때는 플레이어 ID, 친구, 프레즌스, 파티, 리더보드, 분석 등 백엔드 제공 업체가 제공하는 각 지원 사항을 살펴보십시오. 백엔드 제공 업체를 사용하기로 했다면 이런 서비스 품질이 차이를 결정할 수 있습니다. 이런 요소는 게임에 통합되는 데 시간이 걸립니다. 나중에 바꾸기 어려운 일은 서두르지 않는 게 좋을 것입니다! 이미 일부 분야에서 특정 공급자를 사용하고 있지만 매치메이킹에서는 다른 공급자를 사용할 수도 있습니다. 온라인 서비스는 필연적으로 여러 부분으로 나뉘며 어디에서 소스를 얻을지는 당신에게 달려 있습니다.

버전 관리 및 네트워크 호환성

전용 서버가 있고 크로스 플레이를 시작한 뒤라면 클라이언트 또는 서버의 버전 관리와 버전 관리가 매치메이킹에 미치는 영향을 생각해야 합니다. 이 분야는 아직 괜찮은 통합 솔루션을 보지 못한 분야기 때문에 직접 해결책을 생각해야 할 수 있습니다.

네트워크 호환성을 손상시키는 업데이트를 릴리스해야 하는 경우 어떻게 할까요? 클라이언트 업데이트 없이 새로운 네트워크 호환 서버 빌드를 릴리스할 수 있습니까? 특정 플랫폼에 대한 크로스 플레이를 중단해야 하는 경우 다른 플랫폼은 특정 버전을 사용해야 합니까?

클라이언트 업데이트가 모든 플랫폼과 지역에 진행되기까지 시간이 걸릴 수 있으므로 플레이어가 아직 업데이트를 사용할 수 없는 경우를 대비해 이전 서버를 즉시 중단하지 않는 경우도 있습니다. 업데이트가 사용 가능한 경우에도 매치 중 업데이트가 진행되면 곤란할 것입니다.

원활한 업데이트 환경을 만드는 일이 어렵지는 않지만 사전에 여러 가지를 고려한 계획이 필요합니다. 저희는 이전 서버를 유지하여 플레이어가 매치를 완료할 수 있도록 업데이트 창에서 이전 버전과 신규 버전의 매치가 가능하도록 설정했습니다. 클라이언트가 직접 업데이트를 확인할 수 있도록 하여 (또한 신규 매치 시작 전 업데이트를 적용하여), 충분한 배포 시간이 지난 뒤 기존 서버를 종료하고 기존 클라이언트의 요청을 거부합니다. 만약 서버 전용 패치를 배포해야 하는 경우 매치메이커는 신규 매치를 신규 패치군으로 전달하고 기존군의 모든 매치가 완료되면 백그라운드에서 이를 종료할 수 있습니다.

특히 기존 릴리스 분기에서 수정이 있으면 클라이언트 및 서버 빌드의 네트워크 호환성을 테스트하는 것도 중요합니다. 만약 블루프린트 네이티브화 기능을 사용한다면 비 네이티브 클라이언트에서 네이티브 클라이언트로 연결할 때(예: PIE 또는 진행 중 쿠킹) 호환성 문제가 발생할 수 있습니다. 에디터에서 테스트하는 동안 "Net GUID 불일치" 오류를 피하고 싶다면 net.IgnoreNetworkChecksumMismatch CVar를 1로 설정하십시오.

관련 팁으로는 에디터에서 네트워크 드라이버 시간 초과 한곗값을 늘리기 위해 TimeoutMultiplierForUnoptimizedBuilds 구성 변수를 확인하라는 것입니다. 연결 시간제한과 "지연" 한곗값이 상대적으로 짧기 때문에 에디터에서 테스트할 때는 로딩 또는 컴파일에 예상보다 시간이 오래 걸리는 경우 종종 시간제한이 발생할 수 있습니다. 네트워크 게임을 개발하는 경우 이미 여러 개의 PIE 창과 다중 프로세스 PIE를 사용하고 있을 것입니다. 그러나 다른 엔진의 기능과 비교해 이런 기능이 얼마나 대단한지 알아두는 것도 좋을 것입니다.

플랫폼 요구 사항

크로스 플랫폼 개발을 통해 배웠겠지만, 게임이 온라인인 경우 플랫폼마다 특정 요구 사항이 있을 수 있습니다. 크로스 플레이의 관점에서 플레이어의 네트워크 표시(또는 비표시), 플레이어 이름 삭제, 충돌 처리, 플레이어 권한 확인, 기타 플랫폼 관련 API 호출 등이 포함될 수 있습니다.

초기에 각 플랫폼과 대화하여 이러한 요구 사항을 구현하는 데 필요한 모든 정보를 얻고 일정에 문제가 생기는 불쾌한 상황을 피하십시오.

크로스 플레이를 고려해 보세요!

인디 멀티 플레이어 게임은 어려울 수 있지만 크로스 플레이는 매치메이킹 풀을 확대하고 크로스 플랫폼 투자 수익을 높일 수 있는 방법의 하나입니다. 독립 스튜디오로서는 힘든 과제처럼 여겨질 수 있지만 게임의 큰 셀링 포인트가 될 수 있으며 게임 서비스 제공 업체가 성숙하고 플랫폼이 더욱 개방되면 이 작업이 더욱더 쉬워질 수 있습니다.

이 글이 여러분의 게임에서 크로스 플레이를 고려하는 데 도움이 되었으면 좋겠습니다!

하이퍼 잼은 Steam, PS4, Xbox One에서 이용하실 수 있습니다!