Laser Matrix의 기술적 및 성능 문제 해결

마리우스 토르발드센, 마르틴 시베르트센, 그리고 신드레 아스킴 그론볼이 2016년에 몰입형 게임, XR 경험, 그리고 3D 시뮬레이션을 만들기 위해 Breach를 설립했습니다. 지난 9년 동안, 이 작업 의뢰 스튜디오는 XR 솔루션을 제공하면서 그들만의 게임도 개발했습니다. 2024년, 그들은 아이디어를 브레인스토밍하고 새로운 내부 프로젝트를 찾기 시작하면서 프로토타입을 만들기 시작했습니다. 하나의 게임 개념이 빠르게 제작에 들어가 레이저 매트릭스가 되었습니다.

이 제목은 피트니스, 재미, 그리고 미래 지향적인 도전이 충돌하는 혼합 현실 퍼즐 액션 게임입니다. 플레이어는 빛 기반 퍼즐을 해결하고, 이동하는 레이저를 피하며, 민첩성과 지혜를 사용하여 레벨을 잠금 해제할 수 있습니다.

오늘날, 팀은 레이저 매트릭스를 메타 퀘스트와 안드로이드 XR에 출시했습니다. 우리는 Breach의 엔지니어링 디렉터인 안드레아스 바이비와 게임 개발자 중 한 명인 조나단 요르겐센과 함께 앉아 두 플랫폼을 위한 게임 구축과 기술 및 성능 문제를 어떻게 극복했는지에 대해 논의했습니다.

레이저 매트릭스란 무엇인가?

안드레아스: 레이저 매트릭스는 VR에서의 움직임 액션 퍼즐 게임입니다. 매우 아케이드 같은 느낌이며, 당신의 거실을 빠르고 능숙하게 움직여야 하는 위험한 미로로 바꿀 수 있습니다.

메타 퀘스트와 안드로이드 XR의 구현 과정은 어떻게 진행되었나요?

안드레아스: 우리는 프로젝트 시작부터 메타 퀘스트와 안드로이드 XR을 동시에 구현하지 않았습니다. 프로토타입은 처음에 메타 퀘스트 전용으로 시작되었습니다. 우리는 이 플랫폼과 광범위하게 작업했기 때문에 빠르게 작동하게 만들었습니다. 안드로이드 XR은 우리가 이 프로토타입을 시작했을 때 존재하지 않았기 때문에 개발 과정 중에 포팅하게 되었습니다.

조나단: 우리는 Meta의 "빌딩 블록" 도구로 빠른 프로토타입을 시작했습니다. 개념을 검증하는 것이 더 편리해졌습니다. 결국 우리는 크로스 플랫폼 XR을 목표로 하고 게임을 더 플랫폼 독립적인 방식으로 구조화하기로 결정했습니다. 핵심 게임 플레이는 플랫폼 특정 기능에 의존하지 않기 때문에 크로스 플랫폼으로 전환하는 것이 쉬웠습니다.

OpenXR에서 핸드 트래킹을 구현할 때 어떤 단계를 거쳤나요?

조나단: 우리는 OpenXR 런타임에서 실시간 트래킹 데이터를 읽었습니다. 그 데이터는 추상화 계층을 통해 처리되어 원시 데이터가 손 메쉬에 적용되는 위치와 회전으로 변환됩니다. 이 손 메쉬는 Unity의 내장 상호작용 시스템과 인터페이스를 형성하며, 이는 손가락으로 무언가를 터치하는 것과 같은 일반적인 작업을 위한 유틸리티를 제공합니다. 그 후, 마지막으로 우리의 게임 플레이 레이어가 그 위에 추가됩니다.

모든 것은 그 원시 데이터에서 다층 추상화에 관한 것입니다. 많은 XR 게임은 종종 비슷한 요구 사항이 있으므로 가능한 한 안정적인 기존 솔루션을 사용하고 이를 깔끔하게 연결하려고 했습니다. 레이저 매트릭스의 경우 핸드 트래킹에 비표준적인 측면이 많지 않습니다.

팀이 직면한 기술적 도전 과제는 무엇이었나요?

안드레아스: 장면과 사용된 구성 요소에 관해서는 꽤 기본적인 OpenXR 설정입니다. 우리는 손이 트래킹을 잃거나 얻는 순간과 관련된 문제를 해결해야 했고, 그 프레임에서 다른 위치에 생성될 수 있었습니다. 어느 순간, 플레이어는 손 트래킹을 잃기 시작했고, 이는 그들이 생명을 잃게 만들었습니다.

조나단: 핸드 트래킹을 중심으로 설계하는 것은 더 큰 도전 중 하나였습니다. 손의 다양한 접촉 지점이 몇 가지 문제를 일으켰습니다. 버튼을 누르는 것과 같은 일반적이고 느린 UI 상호작용에는 더 간단합니다. 하지만 레이저 매트릭스에서는 몸과 머리를 계속 움직여야 하므로 카메라 기반 손 추적의 정확도가 떨어질 수 있습니다.

안드레아스: 게임 플레이 외의 UI에서는 레이캐스팅을 사용하는 대신 손가락으로 터치해야 하는 버튼을 구현했습니다. 우리의 경험상, 손 추적을 통한 레이캐스팅은 훌륭한 게임 경험을 제공하기에 충분히 정밀하지 않으므로, 이것이 도움이 되었습니다.

조나단: "평면 화면" 게임의 경우, 개발자는 마우스, 키보드 및 컨트롤러와 같은 입력 방식의 사용을 제한할 수 있습니다. XR은 다릅니다. 왜냐하면 게임은 결코 당신의 물리적인 손을 진정으로 멈출 수 없기 때문입니다. 예를 들어, 레이저 매트릭스 메뉴의 버튼은 꽤 평평하며, 버튼을 통해 손을 쭉 찌를 수 있습니다. 이것은 반드시 설계해야 하는 상호작용이 아니며, 실제로 어떤 일이 발생해야 하는지 불분명합니다. 유효한 버튼 누르기인가요? 일반적으로, 더 전통적인 사용자 인터페이스 패턴을 XR로 변환할 때 따르는 몇 가지 흥미로운 의미가 있습니다.

팀이 어떤 성능 관련 문제를 겪었나요?

안드레아스: 우리의 주요 성능 문제는 그래픽 측면에 있습니다. 처음부터 투명성 오버드로우의 균형을 찾는 것이 중요합니다. 이것은 현재 게임 디자인에서 가장 큰 도전 중 하나입니다. 왜냐하면 이러한 상자에 대해 윤곽선만 사용한다면, 위아래를 바라볼 때 그 위치를 볼 수 있고 무언가와 비교할 수 있기 때문입니다. 하지만 정면을 바라보며 벽과의 거리나 손을 닿지 않고 얼마나 멀리 뻗을 수 있는지를 이해하려고 할 때는 더 어렵습니다.

사용자가 전체 미로를 동시에 볼 수 있고 전략적인 위치 결정을 내릴 수 있도록 하려면, 투명성 솔루션이나 대안이 필요하며, 둘 다 GPU 집약적입니다.

조나단: 우리의 일부 솔루션은 게임의 최종 비주얼에 영향을 미쳤습니다. 예를 들어, 게임 영역의 외부 노란색 테두리를 변경했습니다. 예전에는 전체 벽면을 덮고 있는 투명한 노란색 색조가 있었지만, 우리는 그것을 가장자리로만 줄이고 완전히 투명한 그라디언트로 바꾸었습니다. 게임 경계는 플레이할 때 항상 보이기 때문에, 이는 오버드로우 호출 수를 지속적으로 줄였으며, 이는 프레임 시간의 주요 원인 중 하나였습니다.

우리는 또한 플레이어가 게임에서 이동할 때 피하려고 하는 빨간 레이저 큐브를 살펴보았습니다. 그들은 표면에 정사각형 그리드 패턴이 있습니다. 우리는 노란색 경계 큐브와 같은 접근 방식을 적용하여 오버드로우를 다시 줄이려고 했습니다. 그리드 셀의 가장자리만 완전히 렌더링되기 때문에, 우리는 셀을 더 크게 만들어 평균적으로 더 많은 표면이 완전히 투명해지도록 했습니다.

로드와 관련된 성능 문제도 있었습니다. 레벨이 시작될 때마다 큰 스파이크가 발생했습니다. 처음에는 일반적으로 레벨 로딩과 관련이 있다고 가정했습니다. 레이저 매트릭스 레벨을 로드하는 것은 많은 다양한 요소를 생성해야 함을 의미합니다. 그러나 범인은 음악이었습니다. 프로파일링을 통해 시스템이 각 레벨마다 오디오를 다시 로드한다는 것을 발견했습니다. 우리는 음악을 애플리케이션과 함께 미리 로드하도록 구성했으며, 이는 스파이크를 눈에 띄지 않게 만들었습니다.

안드레아스: 우리의 성능 문제 중 일부는 프로토타입을 프로덕션 게임으로 전환했기 때문입니다. 시스템을 다시 작성했어야 했습니다.

어떤 Unity 도구와 기능이 빌드 중에 중요한 역할을 했나요?

안드레아스: Unity의 장점은 하나의 자산과 하나의 코드를 만들고 시작부터 여러 플랫폼에서 작동하게 할 수 있다는 것입니다.

VFX 그래프는 예술적으로 재능이 없는 우리의 제품 소유자가 시각 효과가 어떻게 보일지 구상할 수 있게 해주었기 때문에 훌륭했습니다. 그곳에서 우리의 기술 아티스트와 개발자가 그것을 다듬었습니다.

조나단: Shader Graph는 게임 제작에 매우 유용한 도구였습니다. 게임의 3D 요소 대부분은 순수 셰이더입니다. 몇 개의 큐브, 손, 버튼을 제외하면 이 게임에는 실제 3D 모델이 거의 없습니다.

XR 디바이스 시뮬레이터도 많이 사용되었습니다. XR에서 작업할 때, 테스트는 장기적으로 신체적으로 힘들고 고된 작업이 될 수 있습니다. 모든 단계 – 일어나는 것, 헤드셋 착용, 이동 등 – 사이에 시간이 정말 많이 소요됩니다. 시뮬레이터를 설정하고 마우스 입력을 사용하여 상호작용을 자극함으로써 많은 시간과 불만을 절약했습니다.

안드레아스: 처음부터 XR 디바이스 시뮬레이터를 사용할 수 있었기 때문에, 더 쉽게 독립적으로 테스트할 수 있는 방식으로 새로운 기능을 개발하고 싶었습니다. 이로 인해 처음부터 더 모듈화되고 테스트 가능한 시스템을 작성하게 되었고, 이는 코드 품질도 향상시켰습니다.

조나단: Unity Profiler는 성능 스파이크의 원인을 감지하는 데도 중요한 역할을 했습니다. 예를 들어, 제가 언급한 오디오 로딩 문제와 관련하여, Profiler는 스파이크를 식별하고 그 정확한 시간에 발생한 호출을 파악하는 데 도움을 주었습니다. 이런 종류의 정보는 일반적으로 솔루션을 구현할 때 어디서 시작해야 할지에 대한 명확한 힌트를 제공합니다.

Unity 6에서 어떤 새로운 기능이나 업데이트가 가장 유익했나요?

조나단: 우리는 꽤 많은 타겟을 위해 빌드를 하고, 다양한 맥락에서 작업합니다. 크로스 플랫폼으로 이동할 때, 플랫폼별 기능과 서비스에 대해 서로 다른 구성의 빌드가 필요합니다. 그래서 Unity 6에서 빌드 프로필을 가질 수 있는 능력 덕분에 이러한 다양한 플랫폼에 맞게 빌드를 조정할 수 있었습니다. 이 작업을 수동으로 수행하는 것은 지루하고 오류가 발생하기 쉽습니다.

어떤 주요 성능 벤치마크가 있었나요?

조나단: 우리가 성능 문제를 지적했을 때, 이는 특히 멀미 때문에 XR에서 큰 문제이며, 평균 fps를 측정하고 프레임 드롭을 찾았습니다. 편안함에 대한 명확한 목표가 있습니다.

다양한 큐브 셰이더의 임계값을 조정함으로써 약 10%의 fps를 얻었습니다. 우리는 게임을 테스트 환경에서 최대한 많은 큐브를 그리는 방식으로 프로파일링했습니다. 이것은 테스트를 위한 매우 고정되고 신뢰할 수 있는 맥락을 제공했습니다.

안드레아스: 성능을 위해, 우리의 하드 리미트는 Meta Quest 2에서 72 fps, Meta Quest 3에서 90 fps입니다. 우리는 평균 프레임 속도 목표에 도달하고 있지만, 유저가 더 낮은 결과를 얻는 상황을 만들 수 있습니다. 이것은 최악의 상황에 처할 수 있는 매우 특정한 경우입니다.

조나단: 프로젝트와 팀 차원에서, 지난 몇 달 동안 우리의 반복 시간이 훨씬 더 효율적으로 변했습니다. 회사의 품질 보증 프로세스를 성숙시켰고, 이를 자동화 스택에 연결하여 피드백 및 수정 주기가 매우 빨라졌습니다. 우리는 문제를 빠르게 해결할 수 있어 작업의 백로그가 쌓이거나 통제 불능 상태가 되지 않습니다.

팀이 개발 중에 다르게 했으면 좋았던 것이 있나요?

안드레아스: 우리는 OpenXR을 좀 더 일찍 사용하기 시작했어야 했습니다. 프로젝트 초기에 우리는 플레이 영역의 형태와 크기를 정의하기 위해 Meta의 룸 마크업 기능을 사용할 계획이었습니다. 작동했지만, 우리가 찾고 있던 게임플레이 기능을 제공하지 않았고, 아직 좋은 해결책이 없는 디자인 문제를 열어주었습니다. 우리는 룸 스캐닝 논의 중에 이를 깨달았습니다. 우리는 그 시스템을 더 일찍 폐기했어야 했습니다. 너무 오랜 시간 동안 해결하려고 했기 때문입니다. 또한, 돌아보면 프로토타입 코드가 프로덕션 코드로 발전한 후, 시스템이 더 이상 디자인에 도움이 되지 않는 것을 인식했더라면 시간을 절약할 수 있었을 것입니다.

Unity로 제작된 프로젝트에 대해 더 읽으려면 리소스 페이지를 방문하세요.