Optimizing Deep Rock Galactic Survivor for mobile

복잡한 PC 게임을 모바일 플레이어에게 제공하려면 무엇이 필요할까요? 펀데이 게임즈 딥 록 갤럭틱: 살아남은 사람 이 게임은 탄막 슈팅 루프와 딥 록 갤럭틱 의 드워프, 직업, 무기, 그리고 땅 파기 메커니즘을 결합했습니다. 이식 전문 회사인 Piktiv의 과제는 GPU, CPU, 메모리 용량이 훨씬 적은 하드웨어에서 안정적인 프레임 속도를 유지하면서 수천 개의 적과 환경 요소를 동시에 시뮬레이션하는 것이었습니다.

모바일에서 그러한 경험을 제공하려면 적의 수에 따라 비용이 증가하는 시스템, 즉 경로 탐색, 물리 쿼리, 적 렌더링, 피해량 계산 및 환경 렌더링을 재작업해야 했습니다. 또한, 개발팀은 3GB 아이패드에 게임을 탑재해야 했고, 최신 플래그십 모델부터 몇 년 된 Android 기기까지 다양한 기기에서 실행되도록 지원해야 했으며, 활발히 개발 중인 PC 버전과의 일방향 병합도 유지해야 했습니다.

우리는 엔지니어링 매니저인 마커스 에켈룬드와 수석 엔지니어인 프레드릭 아케르블롬과 포팅에 대해 이야기를 나눴습니다. 딥 록 갤럭틱: 살아남은 사람 모바일 환경에 맞춘 맞춤형 솔루션과 파편화된 기기 환경에서 성능을 최적화한 방법에 대해 이야기합니다.

모바일 포팅을 진행하면서 가장 중요하게 생각했던 기술적 목표는 무엇이었습니까?

프레드릭 아케르블롬: 우리가 사전에 세웠던 기술적 목표의 상당수는 다음과 같았습니다. 이 앱을 모바일에서 실행할 수 있을까요? 그리고 얼마나 다양한 기기에서 작동시킬 수 있을까요? Apple 제품을 살펴보면, 실제로 배송 가능한 세부적인 사양이 그리 많지 않습니다. 가장 최신 제품들이 있고, 그 다음으로는 현재 시중에 나와 있는 많은 제품들을 포함하는 조금 더 넓은 범주가 있으며, 마지막으로 나머지 모든 제품들이 있습니다. 적어도 중간 범주에는 속해야 합니다.

우리가 겪었던 반복적인 문제 중 하나는 모든 기기가 4GB의 RAM을 탑재하고 있는데, 아이패드 한 대만 3GB라는 점이었습니다. 그래서 그것이 핵심적인 기술 목표가 되었습니다. 이 앱이 아이패드에서 오류 없이 실행될 수 있을까요? 우리에게 주어진 용량은 약 1,850MB였고, 그 한도를 초과하면 모든 게 끝장나는 상황이었습니다. 초기 작업의 상당 부분은 RAM을 최적화하는 데 집중되었고, 그 후에야 다양한 플랫폼에서 게임의 실제 성능을 더 자세히 살펴볼 수 있었습니다. 반면 Android 현재 약 9,000개의 다양한 기기가 있기 때문에 모든 것이 제대로 작동하도록 하는 것은 그 자체로 하나의 전문 분야입니다.

PC 에서 모바일 하드웨어로 전환하면서 겪었던 가장 큰 성능 병목 현상은 무엇이었으며, 어떻게 해결하셨나요?

FÅ: 특히 눈에 띄는 핵심 시스템 몇 가지가 있었는데, 그것들은 수천 개의 활성 객체를 보유한 시스템들이었습니다. 피해량 수치, 투사체, 게임 세계 자체, 그리고 생동감 넘치는 3D 적들.

예를 들어, 피해량 텍스트는 원래 TextMesh Pro 사용하는 GameObject였습니다. 하지만 화면에 적이 천 명이나 있을 때 수류탄을 던지면, 이제 모든 적에게 피해량이 표시되어야 합니다. 병목 현상은 텍스트 메쉬 생성 과정에서 발생합니다. 글꼴이 문자열을 시각적인 형태로 변환하도록 합니다.

결론적으로, 우리는 0부터 9까지의 숫자로 구성된 스프라이트 시트를 사용하는 일반적인 Unity 파티클 시스템을 사용했습니다.

ME: 또 다른 예로, 모든 적들의 경로 탐색에는 PC 에 내장된 NavMesh 시스템이 사용되었습니다. 또한 Unity 의 엔지니어 팀이 저희를 지원해 주었는데, 그중 한 명이 유동장 내비게이션을 사용하는 솔루션을 개발하기 시작했습니다. 다른 엔지니어는 물리 쿼리의 상당 부분을 최적화하기 위해 KD 트리 솔루션을 구축했습니다.

FÅ: 적 캐릭터 렌더링의 경우, 화면에 동시에 수천 개의 스킨드 메시 렌더러가 표시되는데, 이는 제대로 작동하지 않습니다. 알고 보니, 이 적들은 거의 모두 하나의 애니메이션만 가지고 있어서 실제로 여러 애니메이션을 지원할 필요는 없었습니다.

대신, 이 시스템은 애니메이션의 각 키프레임을 텍스처에 저장하는 방식을 사용합니다. 우리는 모든 프레임을 그런 식으로 처리하고, 모든 프레임은 GPU의 셰이더를 통해 정점 애니메이션 처리되므로 실질적으로 CPU 부담이 없습니다.

단일 정적 메시와 텍스처로 베이킹하는 것은 큰 개선이었고, 모든 객체가 동일한 재질을 가진 동일한 메시이기 때문에 GPU 인스턴싱 과 같은 작업도 가능하게 해줍니다.

유동장과 KD-트리는 내부적으로 어떻게 작동하며, 무엇을 대체했습니까?

FÅ: 흐름장은 경로 탐색에 드는 비용이 어디에 있는지를 반대로 나타낸 것입니다. 일반적으로 20~30개의 에이전트가 환경을 탐색할 때는 해당 환경의 메시를 생성하고 각 에이전트가 자체적인 경로 탐색을 담당하도록 합니다. 수천 개의 에이전트가 생기면 비용이 에이전트 수에 비례하여 증가하는 경향이 있기 때문에 상당한 병목 현상이 발생합니다.

레벨 전체에 격자를 만든 다음 목표 지점에서 시작하면 주변의 모든 타일이 목표 지점을 가리키는 화살표를 그립니다. 한 걸음 앞으로 나아가서, 이미 화살표가 있는 가장 가까운 대상을 향해 다시 화살표를 가리키고, 전체 영역을 모두 커버할 때까지 계속 진행하세요. 따라서 에이전트 한 명당 비용이 드는 대신, 경로 탐색을 원하는 영역의 크기에 따라 비용이 결정됩니다.

그 제한을 더 세밀하게 조정할 수도 있습니다. 우리는 적들의 위치를 ​​기준으로 계산합니다. 따라서 모든 적과 플레이어를 포함하는 경계 상자를 생성하고, 그 내부 공간만 업데이트합니다.

공간 쿼리를 위해 KD 트리를 사용했습니다. 넓은 방에 가운데를 가로지르는 선을 그으면 갑자기 두 개의 공간으로 나뉘게 됩니다. 쿼리하기 쉬운 트리 구조를 생성합니다. 여기 한 점과 반지름이 있습니다. 그 범위 안에 있는 값을 모두 알려주세요.

그렇게 하면 수류탄이 여기서 폭발했고 이 원 안에 있는 모든 적을 찾아야 하는 것과 같은 복잡한 물리 쿼리를 많이 대체할 수 있을 것입니다. 결과적으로 완벽하게 맞아떨어졌는지는 잘 모르겠습니다. 왜냐하면 KD 트리를 자주 재구성해야 하기 때문입니다. 적들이 끊임없이 움직이기 때문에 KD 트리를 자주 재구축해야 합니다.

모바일 기기 전반에 걸친 테스트 및 튜닝은 어떤 방식으로 진행하셨나요?

FÅ: 우리가 초기에 했던 일 중 하나는 게임이 원활하게 실행될 수 있는 기기를 정하는 것이었습니다. 최소한 30fps는 나와야 하는 비교적 저사양 기기였죠.

우리는 다양한 시나리오를 설정할 수 있는 자동 성과 측정 시스템을 구축했습니다. 우리는 총 6가지 시나리오를 실행했습니다. 딥 록 갤럭틱: 살아남은 사람 . 우리는 이 측정 모드에 맞춰 게임을 특별히 개발할 수 있으며, 기기에서 게임이 시작되는 즉시 특정 생태계에 진입하여 6가지 시나리오를 실행할 수 있습니다.

한 가지 방법은 플레이어가 가만히 서 있는 상태에서 천 명의 적이 플레이어를 향해 움직이는 상황을 만드는 것이고, 다른 방법은 적 500명을 생성하고 플레이어에게 모든 무기를 장착하여 모든 방향으로 자동 사격하는 것입니다. 그렇게 하면 전반적인 상황을 파악할 수 있고, CPU, GPU, 메모리 등 측정 가능한 모든 것을 측정합니다. 우리는 모든 생태계를 대상으로 테스트를 진행하여 특정 생태계에서 성능 문제가 발생하는지 확인합니다.

Unity Profiler는 CPU 성능 감사를 위한 주요 도구 중 하나였으며, 특히 초기 단계에서 쉽게 개선할 수 있는 부분과 가장 큰 성능 향상을 찾고자 할 때 유용하게 사용했습니다.

Addressables 모바일 환경의 콘텐츠 및 메모리 사용량 관리에 어떻게 도움이 되었습니까?

FÅ: Addressables 영역은 iPad의 3GB 메모리 제한을 충족하는 데 중요한 역할을 했습니다. 일반적으로 우리는 초반에 비교적 간단해 보이는 것들부터 먼저 분리해냈습니다. 예를 들어, 서로 다른 생태계에서는 동시에 두 개 이상의 생태계에 있을 수 없으므로 모든 그래픽 요소와 설정을 분리해서 사용할 수 있습니다.

Addressables 이전에는 완전히 동기식이었던 것에 비동기적 동작을 도입하며, 전체 시스템을 비동기식으로 재구축하는 것은 게임의 특성에 따라 상당히 큰 아키텍처적 과제가 될 수 있습니다. 하지만 이 경우에는 우리에게 적합한 선택이었습니다.

모바일 버전의 성공 여부를 측정하기 위해 어떤 성능 지표를 추적하셨나요?

FÅ: 우리의 목표 대부분은 성과와 관련된 것이었습니다. 이 모델들에서는 30fps를 목표로 하고 있으며, 플래그십 모델에서는 60fps를 기대합니다.

~ 안에 딥 록 갤럭틱: 살아남은 사람 벌레를 죽일 때마다 파란색의 반짝이는 큐브들이 튀어나오는데, 이 큐브들을 주워서 레벨업을 할 수 있습니다. 자동 측정 시나리오 중 하나에서 10초 동안 약 4,000개의 오류가 발생했는데, 이로 인해 초기에 성능에 심각한 악영향을 미쳤습니다. 초기 최적화 작업을 마친 후에는 더 이상 측정할 수 없었습니다.

적의 움직임과 물리 엔진을 최적화함으로써 프레임 속도(fps)의 최저치도 크게 향상되었습니다. 그것은 유동장으로 발전했고, 또한 10개 또는 15개의 종속성을 가진 긴 Burst 작업 체인으로 이어져, 모든 적들을 이동시키는 역할을 담당하게 되었는데, 이 모든 것은 일반적인 물리 시스템 외부에서 이루어졌습니다.

이 게임은 레벨을 절차적으로 생성하므로 1층과 모든 벽은 개별 오브젝트로 구성됩니다. 항상 같은 각도의 탑다운 카메라를 사용하기 때문에, 사물을 볼 수 있는 영역을 쉽게 계산하고, 해당 영역 내의 모든 객체를 모아서 자체 배치 그리기 명령을 통해 렌더러로 보낼 수 있습니다. 이는 GPU와 CPU 모두에게 큰 개선이었는데, 왜냐하면 모든 드로우 콜을 개별적으로 전송하는 것은 CPU에 상당한 부담을 주었기 때문입니다.

PC 게임을 모바일로 이식하려는 개발자들에게 가장 중요한 팁은 무엇인가요?

ME: 만능 해결책 하나를 찾는 것보다는, 다양한 시스템 간의 협력이 항상 중요합니다.

FÅ: 다양한 구성 요소로 데이터를 넣고 빼는 데 드는 비용은 매 프레임 수천 개의 엔티티를 처리하게 되면 실제로 상당한 금액이 되기 시작합니다. 데이터를 네이티브 컨테이너에 모두 저장하고 전체 프로세스에서 동일한 네이티브 컨테이너를 사용하는 방식으로 관리할 수 있다면 상당한 이점을 얻을 수 있습니다.

ME: 이 프로젝트에서 얻은 또 다른 교훈은 다음과 같습니다. 게임 개발이 완료되었는데, 나중에 생각해 보니 Unity 용 ECS 나 DOTS( 데이터 지향 기술 스택 ) 시스템을 사용해서 개발했어야 했다는 생각이 들었다고 가정해 봅시다. 게임 전체를 완전히 변환하고 다시 작성할 필요는 없습니다. 저희는 Burst 컴파일러와 대부분의 네이티브 데이터 유형만 사용하고 있습니다.

딥 록 갤럭틱: 살아남은 사람 Steam, Xbox , 앱 스토어 및 Google Play 에서 이용 가능합니다. Unity 블로그 와 리소스 허브 에서 Unity 개발자들의 더 많은 이야기를 확인해 보세요.