Hazelight Studios(헤이즈라이트 스튜디오)에서 제작한 잇 테이크 투(It Takes Two)는 분할 스크린 액션 어드벤처 플랫폼 협동 게임입니다. 이 게임은 엄청나게 다양한 콘텐츠와 독창적이며 재미있는 애니메이션 스타일로 다른 액션 어드벤처 게임과 차별을 두고 있죠. 이런 게임의 소리풍경을 개발하면서 가장 중요한 도전 과제는 바로 분할 스크린과 오디오가 미치는 영향이었습니다.

Hazelight Studio 분들이 잇 테이크 투의 오디오를 개발하면서 직면한 도전 과제와 기회에 대해 답변하는 시간을 가졌습니다. 오디오 팀의 필립 에릭손(Philip Eriksson, 리드 사운드 디자이너), 요아킴 에닉크 쥬버그(Joakim Enigk Sjöberg, 테크니컬 사운드 디자이너), 예란 크리스찬슨(Göran Kristiansson, 오디오 프로그래머), 앤 소피 몬쥬(Anne-Sophie Mongeau, 시니어 사운드 디자이너)가 분할 스크린, 믹스, 사운드 디자인, 성능, 음악에 대한 접근 방식에 대해 말해드립니다. 이 인터뷰는 고품질 오디오 경험을 전달함과 동시에 동일한 게임 유형의 오디오에 대한 새로운 표준을 제시하는 기술적인 솔루션을 조명합니다.

분할 스크린

잇 테이크 투에서 수직 분할 스크린을 다루기 위한 기술적인 솔루션을 간단하게 설명해주실 수 있나요?

필립: 저희는 시각적인 수직 분할 스크린을 다루기 위해 사운드 믹스도 두 부분으로 나눴습니다. 모든 사운드에 대해 좌측, 중앙, 우측 스피커를 기반으로 했고 후면 스피커보다 전면 스피커를 선호했습니다. 스크린 좌측에 해당하는 사운드는 좌측과 중앙으로 패닝해서 오른쪽 스피커에서는 아주 조금만 흘러나오도록 했죠. 플레이어의 움직임, 능력 사운드 및 음성에 이 방법을 적용했습니다. 환경음의 경우 4 채널로 구성해서 후면 스피커에서도 들리도록 했습니다. 캐릭터가 별도의 위치에서 서로 다른 환경음을 들을 경우 오른쪽 캐릭터의 환경음은 좌측, 측면, 후방 스피커에서 줄이고 그 반대의 경우도 마찬가지로 줄여서 항상 스크린 공간에 맞춰진 깔끔한 경험을 제공할 수 있도록 했습니다.

그림 1: 환경음 패닝

스크린이 중앙에서 분할되지 않은 경우에는 다르게 다루셨나요? 예를 들어 한 플레이어의 화면이 커지거나, 수평으로 분할되거나, 혹은 게임이 전체 스크린일 경우엔 어떻게 작업하셨나요?

요아킴: 지금까지 두 플레이어가 수직적 분할에서 동일한 스크린 공간을 차지하는 경우가 대부분이었고 저희도 이 부분에 기술적인 노력에 가장 많은 시간을 투자했습니다. 두 플레이어가 전체 스크린에서 동일한 뷰를 공유하는 상황도 게임에서 꽤나 많이 있었습니다. 이러한 씬에서 공간적 배치 프레임워크가 완전히 뒤집히지 않는 것이 관건이었죠. 시각적인 관점은 다르지만 오디오의 작동 방식은 플레이어가 알아차릴 수 없을 만큼 아주 약간만 변경되었습니다. 전체 스크린 섹션에서는 스크린 중앙을 기준으로 음원의 위치를 추적한 다음 수평선에 따라 알맞게 패닝하는 방법을 주로 사용했습니다. 이 방법은 종종 정신 없고 강렬하게 진행되는 게임플레이 섹션에서 선명도를 크게 향상시켜주는 스크린 공간 관리에 대한 저희의 기본 철학에 따른 것입니다.

예란(GÖRAN): 이 혼란함에 질서를 잡아준 기술적인 솔루션은 바로 필터링 플러그인이었습니다. 저희 필터링 플러그인은 채널별 바이쿼드(biquad) 필터이며 필터에 볼륨 페이더와 Q 값이 제공됩니다. 저희는 이 플러그인을 사용해서 각 채널을 분명하게 제어하고 플레이어가 죽거나 다시 스폰할 때에 활용했습니다. 믹스의 절반에 로우패스 필터로 스위핑하면서 멋진 효과도 제작했고 각 플레이어를 선명하게 구분할 수 있었죠. 게임 플레이의 제약으로 인해(예를 들어 오랫동안 생명력이 낮을 경우) 믹스의 절반에 로우패스를 사용하는 비슷한 효과를 적용할 수는 없었습니다. 효과를 너무 오래 적용하니 믹스가 좋지 않게 들리기 시작했거든요. 그래서 좀 더 강렬하고 짧은 죽음/리스폰 순간에만 이 효과를 사용했습니다. 다행히도 Wwise에 있는 기존의 코드베이스를 통해 플러그인의 기능을 쉽게 구현할 수 있었습니다.

완전히 공간화된 사운드(3D)의 경우는요? 두 플레이어가 음원을 기준으로 서로 다른 위치에 있을 경우 공간화된 사운드의 위치를 파악하는 데 있어 혼동을 어떻게 방지하셨나요? 

필립: 공간화된 사운드의 경우 2D 사운드보다 좀 더 까다로웠습니다. 게임 사운드를 제작하는 초기 과정에서 이 문제를 알게 되었지만 꽤나 늦게까지 해결 방법을 찾지 못했죠. 제일 간단한 예시를 들자면, 한 플레이어가 음원과 굉장히 가까이 서있지만 카메라가 음원을 등지고 있으며 다른 플레이어는 음원으로부터 멀리 떨어져 있지만 음원을 바라보고 있을 경우가 있었습니다. 이 경우 믹스가 합쳐지면서 사운드가 전면과 후면 스피커에서 모두 흘러나오게 되어서 사운드가 아주 넓고 크게 인지됩니다. 필요 이상으로 지나치게 말이죠. 저는 이것이 게임이 표현하려는 환상을 깨뜨린다고 생각했어요. 그 상태로 게임을 출시해서는 안된다고 생각했습니다. 패닝과 믹싱에서 저희에게 가장 확실한 규칙 중 하나는 음원이 시야 안에 있는 플레이어를 중시하는 것이었는데 이 문제의 경우 저희 규칙을 깨뜨렸기 때문에 뭔가 조치가 필요했습니다.

요아킴: 여기서 저희는 특정한 리스너 설정으로 인해 두 가지 주요 문제점이 생긴다는 것을 보았습니다. 첫 번째 문제는 공간적 사운드의 위치가 지정되는 방식이었습니다. 공간적 음원과 가장 가까운 플레이어가 보통 가장 큰 출력을 믹싱하게 되기 때문에 이들의 관점이 스피커 배치에서 가장 큰 영향을 미치게 됩니다. 이 플레이어의 시야는 종종 디자이너가 그 당시 집중하고자 하는 것과 다를 수 있는데, 이 결과를 저희가 제어할 수 있는 도구가 없었죠.

두 번째 문제는 Wwise가 리스너를 위해 채널을 본질적으로 결합하는 방식이었습니다. 두 리스너에 의해 공간적 사운드 출력이 능동적으로 믹싱될 경우 신호의 양이 두 배가 됩니다. 따라서 한 플레이어에 의해 동일한 사운드를 들을 경우보다 출력 볼륨이 증가하게 되죠. 이 경우 채널별 신호의 양이 해당 음원에 대한 두 플레이어의 관계에 따라 달라지기 때문에 결과를 예측하기가 아주 어려워집니다. 

공간화된 이미터의 진폭에 대한 문제는 저희가 게임에 사운드를 구현하기 시작하자마자 분명하게 드러났습니다. 저희는 먼저 높은 계층의 Actor-Mixer에서 보충 게인과 연결되어 있는 아주 간단한 RTPC를 구현해서 문제를 해결해보려고 했습니다. 공간화된 사운드를 재생하는 모든 이미터에 대해 리스너와의 근접성을 추적하고 두 플레이어가 모두 범위 안에 있을 경우 이 RTPC는 거리에 따라 지속적으로 볼륨을 감소하도록 업데이트되도록 해서 두 배가 된 채널의 강도를 상쇄했죠. 이 방법은 '해결책'이라고 하기엔 너무 형편없었습니다. 그리고 리스너에 의해 조합되는 신호의 정확한 양을 실제로 예측할 수가 없기 때문에 진폭이 평평해지는 수준 낮은 결과를 얻게 되었습니다.

이 두 문제는 저희가 게임의 공간적인 믹스를 절대 제어할 수 없다는 것을 의미했습니다. 그래서 저희는 Wwise 로우 레벨을 살펴보고 잇 테이크 투에서 공간화된 음원을 처리하는 저희만의 규칙을 만들기로 했습니다.

그림 2 & 3: 한 음원, 두 리스너 라우팅

예란: Wwise 시스템에서 저희만의 규칙을 작성하기 전에 먼저 Wwise의 규칙을 알아야 했습니다. 단계별로 어떤 규칙이 존재하는지 살펴보고 무엇을 어디에서 변경해야 하는지를 살펴봤습니다.

이전에 말씀드린 것처럼 이 작업을 꽤나 늦게 시작했기 때문에 '어떻게 하면 프로젝트를 시간 안에 끝내면서 원하는 결과를 얻어낼 수 있을까'를 생각하며 접근했습니다. 설계 요구 사항을 요약하자면, 저희 목표는 신호의 배증을 방지하고 방향적 초점에 따라 신호를 고정해서 저희만의 Spatial Panning(공간적 패닝) 시스템을 만드는 것이었습니다. 

이를 염두에 두고 저희는 감쇠 범위 안에 있는 모든 리스너와 각 이미터에 대한 리스너의 상대적 방향을 알아야 했습니다. 신호 변경은 대부분 거리에 따라 스무딩(smoothing)하기로 했습니다. 하지만 대부분의 상황에서 회전 변경이 다소 제어되었으며 매끄러웠기 때문에 게임플레이가 방향적 신호 스무딩의 속도를 간접적으로 제어하도록 했습니다. 성능 저하 제한은 물론 원하는 형식으로 데이터를 얻기 위해서 저희는 Wwise 시스템에 꽤나 많은 흔적을 남기고 나서야 원하는 결과와 성능을 얻을 수 있었습니다.

그런데 이 Spatial Panning 솔루션이 아주 유용하긴 하지만 다른 문제를 야기하지는 않았나요? 만약 다른 문제가 있었다면, 어떤 것들이 생겨났으며 여러분이라면 어떤 방식으로 이 문제를 방지했을까요?

필립: 저는 플레이어가 정말로 귀 기울일 경우 이 문제 해결 방법에 의한 소리 차이를 들을 수 있으리라 100% 장담합니다. 하지만 이 방법은 부작용보다 해결해낸 문제가 훨씬 많아요. 저희 해결책은 후면 스피커에서 전면 스피커로 와야 하는 설정과 같이 움직이는 사운드에도 적용되기 때문에 이 전환이 매끄럽게 진행될 수 있도록 러프(lerp)를 만들어야 했습니다. 이럴 경우 플레이어가 아주 빠르고 크게 움직일 때 저희가 가능한 모든 시나리오에 대해 러프를 아주 조심스럽게 조정하더라도 러프가 느리게 느껴질 수 있습니다. 플레이어가 절대 한 음원만 단독적으로 들을 일이 없기 때문에 게임의 전체 믹스에서는 문제를 찾아내기가 아주 어렵게 됩니다.

요아킴: Spatial Panning 기능은 잇 테이크 투에서 찾은 문제를 해결하기 위해 특별히 직접 고안됐습니다. Spatial Panning을 포함하여 이 프로젝트 도중 최종 결과를 달성하기 위해 사용된 모든 방법은 모든 유형의 액션 지향 분할 스크린 게임에 완벽히 적합하도록 설계되지는 않았습니다. 대신 잇 테이크 투 게임의 경계 안에서 작동하도록 맞춤 제작되었습니다. 예를 들어, 이 게임의 게임플레이는 아주 선형적입니다. 플레이어는 항상 앞으로 전진하며 듣게 되는 모든 공간적 사운드는 이 여정을 위해 설계되었죠. 게임의 이런 문맥에서는 저희 해결책이 잘 맞았지만 오픈 월드 형식이나 두 플레이어 간의 관점이 비대칭적인 게임의 경우에는 이 해결책이 적합하지 않을 수 있습니다. 미래에 개발할 게임에서도 Spatial Panning 아이디어를 계속 사용할 수도 있겠지만 새로운 게임에서는 스크린 두 쪽을 합치고 관점을 타협하여 하나의 완전한 경험을 만들기 위해 무엇이 필요한지 재고해봐야 할 것입니다.

예란: 저희는 새로운 콘솔 출시 도중 게임을 출시해야 했기 때문에 새로운 콘솔에 관한 문제나 기능때문에 Wwise 버전을 자주 업데이트해야 했습니다. 따라서 Spatial Panning과 같은 저희 기능도 계속해서 제대로 작동하도록 유지해줘야 했죠. 이런 일들은 서드파티 소프트웨어를 사용할 경우 이미 예상할 수 있는 내용이지만, 도구를 제작하기 위해 (혹은 기존의 도구를 사용하기 위해) 기존의 소프트웨어를 변경할 때 가능한 한 변경 과정을 돕고 코드 베이스의 변경 사항을 명확하게 표시하기 위해 이 점을 염두에 두는 것이 좋습니다. 그러면 버전 간에 마이그레이션할 때 일을 줄일 수 있습니다.

믹스

잇 테이크 투의 믹스는 매우 뛰어나고 분할 스크린임에도 불구하고 계속해서 깔끔하고 명확하게 들립니다. 게임을 믹싱할 때 어떤 접근 방식을 사용하셨나요? 어떤 비전이 있었고, 이를 어떻게 실용적으로 적용하셨나요?

필립: 저희는 항상 새롭고 강렬한 것에 집중하면서 급격한 변화가 있는 흥미로운 믹스를 만들고 싶었습니다. 저희 게임은 꽤나 선형적이기 때문에 오픈 월드 유형의 게임보다 그런 믹스를 만들어내는 것이 더 쉬웠습니다. 플레이어가 공간에서 공간으로 이동하거나 주요 경로를 따라갈 때 저희는 항상 다가오는 흥미로운 사운드와 사건에 집중했습니다. 대부분 플레이어가 들어야 할 것과 듣지 말아야 할 것을 신중하게 선택하여 믹스를 결정함으로써 흥미로움을 만들어낼 수 있었죠. 오디오 팀은 스포팅(spotting) 세션과 효과음 제작에서부터 최종 믹스까지 의식적으로 흥미로움을 만드는 작업을 했습니다. 재밌는 사실 한 가지는, 게임이 설계된대로 작동하도록 믹싱하기 위해 저희도 두 플레이어가 필요했다는 것이었어요. 두 명이 함께 믹싱하니 믹싱 과정이 더 재미있었을 뿐만 아니라 항상 또 다른 귀로 들어주고 믹싱 결정을 의논할 사람이 있다는 점이 많은 도움이 되었습니다.

앤 소피: 분할 스크린은 몇 가지 믹싱 결정에서 아주 중요한 영향을 미쳤습니다. 예를 들면 저희는 항상 스크린을 두 개로 나눠서 어떻게 이 분할을 극복할 것인지를 고분군투하는 대신 분할 스크린을 활용해 현재 게임플레이에서 어떤 요소가 가장 중요한지를 믹스를 통해 강조하여 사운드를 서술적으로 사용하기로 했습니다. 차근 차근 중요한 요소 하나에 집중해서 플레이어가 어떤 것에 집중해야 할 지를 말해줬죠. 이 전략은 서사적인 장면이나 전투 혹은 빠르게 진행되는 시퀀스에서 특히 중요했습니다. 때로는 이로 인해 들릴 것과 들리지 않아야 하는 것을 과감하게 선택해야 하기도 했지만 궁극적으로 믹스의 명확도와 일정함에 큰 도움을 주었습니다.

재생 구성에 따라 다른 믹스를 전달하는 것을 고려해보셨나요? 예를 들어 각 플레이어에 서로 다른 헤드폰 믹스를 제공한다던지 혹은 로컬 멀티플레이어 모드(같은 장치로 플레이)나 네트워크 상 멀티플레이어 모드를 사용하느냐에 따라 다른 믹스를 제공하는 것을 생각해보셨나요?

필립: 오디오 제작 초반에 이 생각을 해봤습니다. 그리고 몇 가지 아이디어가 있었어요. 한 아이디어는 자신이 플레이하지 않는 다른 캐릭터의 움직임 소리와 음성을 낮추는 것이었습니다. 또 다른 아이디어는 다른 플레이어가 듣게 되는 세계 사운드를 뮤트하는 것이었죠. 하지만 플레이어의 경험을 상상해봤을 때 두 아이디어 모두 별로 좋지 않았습니다. 어떤 캐릭터를 플레이하든 게임이 시각적으로 똑같았기 때문에 사운드도 똑같이 다루는 것이 논리적으로 느껴졌습니다. 또한 서로 다른 모든 종류의 믹스를 유지하려면 작업량이 더 늘어났을 것입니다. 저희는 두 플레이어가 모두 동일한 소리 풍경 안에 있고 스크린을 공유할 때 좋은 소리를 경험할 수 있도록 했습니다. 특히 잇 테이크 투의 경우 어떤 플레이를 하든 소리풍경이 공유되어야 한다고 생각해요.

HDR

잇 테이크 투에서 Wwise HDR을 사용하셨나요? 프로젝트의 요구 사항에 적합하면서 분할 스크린을 가장 잘 뒷받침하는 전략은 무엇이었나요?

필립: 네, Wwise HDR을 사용했습니다. 아주 쉬운 결정이었죠. 저희는 HDR을 사용해서 믹스를 깔끔하게 만들어주고 들리지 않는 사운드를 컬링(culling)하여 게임을 최적화하는 도구로 사용하고 싶었습니다. 이전에 있었던 EA DICE 출시작에서 HDR을 사용해왔기 때문에 Wwise HDR에 익숙해지기 위해 어느 정도 시험을 해봐야 했습니다. 그 중 몇 가지 팁과 전략을 설명해드릴게요.

• 사운드를 노멀라이즈하세요.
• 여러 종류의 사운드에 사용할 보이스 볼륨 값에 대한 안내서를 만드세요. 혹은 믹스에서 어떤 사운드가 가장 중요한지를 선택하세요 (항상 가장 큰 소리가 중요한 것은 아닙니다. 가장 흥미로운 사운드가 중요할 때도 있어요).
• 거리 감쇠를 제외하고 보이스 볼륨 값이 고정적으로 유지되도록 해보세요. 예를 들어 보이스 볼륨값에 랜덤 LFO RTPC를 적용하지 마세요. 적용할 경우 사운드가 다른 사운드를 시간에 따라 다르게 덕킹해서 (혹은 다른 사운드에 의해 덕킹되어서) 원치 않은 결과를 얻을 수 있습니다.
• 일반적인 믹싱에서 모든 가변 볼륨에 보충 게인을 사용하세요.
• 동일한 효과음에 여러 레이어를 사용할 경우 각 보이스의 보이스 볼륨값이 서로 다를 수 있기 때문에 함께 재생되는 레이어도 덕킹될 수 있다는 점을 기억하세요. 함께 재생되어야 하는 레이어에 같은 보이스 볼륨값을 설정하고 보충 게인을 사용하여 이 레이어 간의 패닝을 믹싱하는 것이 좋습니다.
• 보이스 볼륨이 HDR 창 범위의 최소값보다 작게 설정될 경우 해당 사운드가 컬링될 확률이 높습니다 (가상 보이스 작동 방식에서 컬링하도록 설정된 경우). 의도적으로 사용할 수는 있지만 주의하셔야 합니다.

또 다른 흥미로운 점은 리스너가 두 개일 경우 동시에 HDR 인스턴스도 두 개가 된다는 것입니다. 따라서 한 리스너가 보이스 볼륨이 큰 사운드 옆에 서있고 다른 리스너가 감쇠 범위 밖에 있을 경우 합산된 HDR 덕킹은 두 리스너가 음원에 가까울 때보다 더 적습니다. 이 작동 방식이 좋을 수도 있지만 원하는 결과가 아닐 수도 있죠.

그림 4: Voice Monitor를 사용한 HDR 시각화

RVB/Worldizing

잇 테이크 투의 리버브와 일반적인 세계는 아주 현실적이고 몰입적입니다. 어떤 종류의 리버브를 사용했나요? 또한, 현실감 높은 환경을 만들기 위해 어떤 해결책을 개발해야 하셨는지요?

필립: 잇 테이크 투 오디오의 방향을 제시해 준 주요 핵심은 바로 플레이어가 몰입할 수 있는 환경을 만들고 세계가 사운드에 반응하도록 해서 두 요소가 서로 연결되도록 하는 것이었습니다. 저희는 청소기 호스, 유리 병뿐만 아니라 만화경 세계 레벨에서 사용한 요상한 리버브 효과와 같은 창의적인 환경을 만들고 싶었습니다. Wwise RoomVerb 플러그인을 사용해보려고 했지만 충분하지 않았기 때문에 더 창의적일 수 있는 컨볼루션 리버브만 사용하도록 했습니다. 저희는 채찍이나 폭죽과 같이 다른 환경을 사용한 임펄스 반응을 수도 없이 녹음하고 수면 아래와 상상의 공간을 위해 설계된 임펄스를 제작했습니다.

이런 컨볼루션 리버브뿐만 아니라 다양하게 설계된 리플렉션 꼬리를 재생할 수 있도록 'Environment Type(환경 유형)' 시스템을 만들었습니다. 이 리플렉션 꼬리는 대부분 폭발음과 무기에 사용했지만 긴 꼬리를 사용하여 사운드의 크기와 라우드니스를 뒷받침해줄 수 있는 몇몇 다른 소리에도 사용했습니다. 사실 발자국 소리의 경우 작은 공간과 큰 공간을 위한 두 가지 버전의 꼬리를 베이킹했습니다.

더욱 현실적인 세계를 만들기 위해서 저희는 레이캐스트를 사용하여 캐릭터와 반사적인 표면 사이의 거리와 표면의 유형을 계산하는 런타임 딜레이 시스템을 제작했습니다. 이 시스템은 보다 고정적인 리버브와 미리 베이킹된 리플렉션에 근사하고 다양한 리플렉션을 추가해서 아주 미세한 차이에도 세계가 빠르게 반응하도록 만들어주었습니다.

그림 5: 컨볼루션 리버브의 레벨 전용 임펄스 반응 설정

요아킴: 재생되는 사운드에서 환경적 효과를 시뮬레이션하는 시스템을 설계할 때 효과의 스펙트럼이 미리 결정되어있어야 하는지 혹은 동적이고 일시적인 결과로 런타임때 일어나야 하는지를 생각해보는 것이 좋습니다. 리소스와 기술적/창의적인 여건과 최적의 결정에 따라 두 특성 사이에서 알맞은 지점을 찾아보세요. 잇 테이크 투 환경 시스템의 근본적 기반을 예로 들자면, 저희는 컨볼루션을 통한 리버브 구현을 지향했습니다. 런타임 때에 신호를 이러한 버스에 동적으로 라우팅하기는 하지만 효과 단위 자체의 특성은 신중하게 미리 설계되어서 특정 유형의 주변 환경을 렌더링하죠. 플레이어가 세계 안에서 이동함에 따라 위치를 모니터링하고 이를 기반으로 리버브 버스로의 라우팅을 관리하는 것 외에 리버브의 소리 자체는 굉장히 결정적입니다.

반면, 일단 두껍고 안정적인 리버브를 갖게 되면 게임에서 수집된 모든 방식의 데이터(예: 벽으로의 거리, 플레이어 주변 물질, 주변 오브젝트와의 관계)에 의해 구동되는 실시간 계산에 의해 프로그래밍된 가변 딜레이 라인을 사용하여 초기 리플렉션의 물리적 현상을 나타내는 작업을 시작할 수 있었습니다.

미리 결정되었거나 게임이 실행되면서 구성된 결과를 사용하든 상관 없이 모든 종류의 시스템에는 저마다 장점과 단점이 있습니다. 하지만 이 시스템을 결합하면 디지털 세계를 실제처럼 전달할 수 있는 결과를 만들어낼 수 있죠.

예란: Wwise에 있는 딜레이 플러그인은 아쉽게도 가변적인 딜레이 시간, 즉 RTPC를 통한 런타임에서의 딜레이 시간 변경을 지원하지 않습니다. 저희는 초기 리플렉션 시스템에 이 기능이 꼭 필요했어요.

처음 프로토타입할 때 저희는 Pure Data를 사용했습니다. 또한 엔진에서 모든 것을 시도해보기 위해서 현재는 중단된 Heavy 컴파일러를 사용한 Pure Data 패치로부터 Wwise 플러그인을 만들었습니다. 하지만 모든 플랫폼에서 지원되지는 않기 때문에 아마 오늘 바로 사용하기에 무리가 있을 겁니다.

먼저 저희는 테이프 딜레이를 사용해봤지만 딜레이 시간을 업데이트할 때 피치가 변경되더군요. 가변 딜레이 시간이 있는 딜레이 라인도 사용해봤지만 딜레이 시간을 업데이트할 때 클릭 소리와 같은 결함이 있었습니다. 하지만 잠재적인 결과를 보여주고 계속해서 자체적인 Wwise 플러그인을 만드는 데에는 충분했습니다. 

결국에는 바이큐빅 보간(bicubic interpolation)을 사용하는 분수 딜레이 라인을 사용하여 딜레이 시간을 변경할 때 일어날 수 있는 노이즈를 매끄럽게 해줬습니다.

그림 6: Hazelight의 자체적인 Wwise 플러그인인 ‘Haze Delay’은 분수 딜레이 라인을 사용하여 딜레이 시간 변경을 매끄럽게 해줍니다

분할 스크린의 경우 동시에 처리해야 하는 컨볼루션 리버브와 인스턴스가 꽤나 많아질 수가 있습니다. 딜레이도 마찬가지죠. 이 시스템에 성능 문제는 없었나요? 있었다면 어떻게 해결하셨나요?

필립: 두 캐릭터가 서로 다른 환경 구역에 있거나 최악의 경우 서로 다른 환경 구역 간의 페이드 구역에 있을 학률이 굉장히 높았습니다. 그럴 경우 동시에 캐릭터 사운드만 해도 네 개의 컨볼루션 리버브로 믹싱되죠. 또한 저희는 서로 다른 환경 구역에 있는 사운드가 해당 구역의 리버브로 믹싱되도록 하기 때문에 동시에 리버브 인스턴스가 많아질 수 있습니다. 런타임 딜레이 시스템의 경우 좀 더 간단했습니다. 딜레이가 캐릭터 주변으로만 이루어지기 때문에 딜레이 인스턴스가 총 4개가 됩니다 (캐릭터 당 두 개씩).

요아킴: 잇 테이크 투에서 리버브 버스는 세계에서 구분된 공간에 존재하며 ('Ambient Zones’, 환경 구역) 플레이어가 해당 구역에 있을 경우에만 작동하기 위해 활성화됩니다. 마찬가지로 플레이어가 특정 구역 안에 더 이상 없을 경우 해당 리버브 센드는 컬링되며 버스가 비활성화 상태로 돌아갑니다. 게임플레이 도중 플레이어는 크로스페이드하는 리버브 인스턴스를 따라 계속 이동해서, 플레이어가 다음 환경으로 갈 때 자연스럽게 전환된 다음 더 이상 현재 플레이어로부터 입력 신호를 받지 않을 때 비활성화됩니다. 이 시스템은 잠재적으로 아주 다른 위치에 있는 두 플레이어를 지원하면서 최대한 긴밀하게 연결되어 있지만, 그럼에도 불구하고 세계 안의 다른 사운드와 함께 플레이어의 위치에 따라 7~8개의 고유한 컨볼루션 리버브 버스가 있는 것이 드문 일은 아닙니다. 또한 개발 도중 Audiokinetic이 컨볼루션 리버브 효과에 자체적인 성능 최적화를 출시해줘서 정말 감사했죠!

예란: 저희가 처리 작업을 줄이기 위해 실행했지만 리버브에 큰 영향을 주었던 작업은 바로 비활성화된 오브젝트를 컬링하여 처리되는 활성화된 오브젝트을 제한하는 것이었습니다. 예를 들면 아무 사운드도 재생하지 않거나 범위 밖에 있는 오브젝트 말이죠.

뿐만 아니라 필요할 경우 데이터만 업데이트하도록 했습니다. 예를 들어 딜레이 시스템의 경우 비동기적인 레이캐스트를 사용했고 데이터가 충분히 변경되었을 경우에만 딜레이 플러그인을 업데이트했습니다. 그래서 가능한 경우 가변 딜레이 라인의 변경을 감소했지만 현재 프레임에서 모든 변경 사항이 실행되는 것을 포기해야 했습니다.

성능

리버브를 제외하고, 분할 스크린 게임의 경우 항상 동일한 게임의 두 인스턴스가 평행적으로 실행됩니다. 이로 인한 성능에 관한 주요 문제는 없었나요? 가장 걱정되었던 부분은 무엇이었으며 어떻게 해결하셨나요?

필립: 이 부분은 물론 전체 오디오 제작 기간 동안 항상 저희가 염두에 두었던 부분입니다. 그래야 한다고 생각해요. 훌륭한 사운드를 가진 게임을 만든 후 제작 마지막 시기에 와서야 공들였던 멋진 작품을 모두 최적화하는 것은 참 슬픈 일입니다. 저희는 초반부터 데이터를 모니터링하면서 정상 범위 내에 있도록 했습니다. 레이어가 꼭 필요한 경우에만 사운드 디자인에 레이어를 사용했고 신중하게 믹싱을 결정했으며 HDR을 사용하여 불필요한 사운드를 제거(혹은 컬링)했습니다. 이러한 작업이 창의적으로 장애물이 되지는 않았지만 가끔 항상 듣기 좋으면서도 최적화된 사운드를 위해 설계 기술을 조절해야 하기도 했습니다. 또한 저희는 HDR, 재생 제한, 가상 보이스 작동 방식 및 재생 우선 순위 등 모든 Wwise 기본 최적화 시스템을 할용할 뿐만 아니라 저희만의 최적화 시스템을 함께 활용했습니다.

요아킴: 게임에서 거의 대부분 여러 사운드를 동시에 재생하는 것이 CPU를 가장 많이 사용합니다. 잇 테이크 투와 같은 분할 스크린도 분명히 예외가 아니죠. 보이스와 버스 제한이 기본적으로 제한해주긴 하지만 HDR의 훌륭한 기능 덕분에 설정한 볼륨 한계점 아래의 사운드를 컬링해서 믹스를 깔끔하고 동적으로 만들 수 있었을 뿐만 아니라 게임플레이 도중 중요하지 않은 사운드의 처리해야 하는 부담을 완화할 수 있었습니다.

잇 테이크 투는 필요와 요구 사항 및 강약점이 다른 다섯 가지 플랫폼에서 출시되었습니다. 저희는 플랫폼별로 Wwise의 계층 구조를 설정하는 대신 계속해서 최악인 부분을 찾아내고 모든 콘솔에서 작동하도록 만드는 방식을 사용했습니다. 모든 장치에서 작동하도록 계속해서 왔다갔다 작업해야 했던 것 중 하나는 어떤 종류의 사운드를 디스크에서 스트리밍해야 할지를 분류하는 것이었습니다. 이 부분이 저희 게임에서 성능에 즉각적인 변화를 주더군요. 이 작업은 마치 프로세서가 오디오 프레임에서 보내는 시간, 압축되지 않은 PCM 데이터가 RAM에 있는 시간, 하드 드라이브가 스트림하는 양의 퍼즐 조각을 맞춰나가는 것과 같았습니다.

Wwise에 Profiler말고 다른 아무 기능도 없었다고 하더라도 저는 여전히 Wwise를 사용했을 겁니다.

예란: 정확하게 말씀드리자면 저희는 게임의 두 인스턴스를 실행하는 것이 아니라 두 관점을 실행합니다. 청각적인 경험의 경우 적어도 두 개의 리스너가 항상 있죠. 그래서 음원이 하나더라도 신호가 두 리스너로 믹싱되었습니다.

요아킴이 앞서 말한 것처럼 저희는 동시 재생되는 사운드의 양뿐만 아니라 개별적인 복잡성을 주로 걱정했습니다. 일부 사운드는 여러 개의 RTPC와 리버브, 위치가 각 프레임에서 업데이트되어야 했기 때문에 각 오브젝트의 서로 다른 요구 사항을 명확하게 구분하기 위해서 저희는 수많은 설정과 사용하기 쉬운 빠른 실행법을 사용하여 개발 과정을 원만하게 만들어주었습니다. 예를 들어 단발성(Fire-Forget) 사운드의 경우 사운드의 지속 시간만큼만 활성화된 후 다시 다른 사운드가 재생되어야 할 때까지 비활성화됩니다. 대부분의 사운드가 비활성화될 수 있는 시기를 알기 위해서 저희는 청각적 경험이 계속 유지될 수 있도록 리스너의 이동 속도를 감안하기 위해 어느 정도 값을 메우고 감쇠 반경을 완전히 활용했습니다.

사운드 디자인

잇 테이크 투는 엄청나게 다양한 게임플레이가 특징이기 때문에 오디오를 제작하는 데에도 엄청나게 많은 양의 콘텐츠가 필요했을 것입니다. 이 많은 작업을 어떻게 감당하실 수 있었나요? 아웃소싱 회사와 함께 작업하셨나요?

필립: 저희는 Red Pipe Studios(레드 파이프 스튜디오)와 함께 작업했습니다. 그 분들이 모든 시네마틱의 사운드와 믹싱을 전달해주셨죠. 음악의 경우 작곡가 크리스토퍼 엥(Kristofer Eng)이 사내 작곡가인 구스타브 그레프버그(Gustaf Grefberg)와 함께 작업했습니다. 그리고 SIDE(사이드)가 모든 게임 내 보이스오버 녹음과 초기 편집을 담당했습니다. 그리고 Red Pipe가 Foley Walkers(폴리 워커스)와 함께 시네마틱의 폴리를 제공했고 저와 Ton & Vision(톤 앤 비전)의 패트릭 스트롬달(Patrik Strömdahl)이 수많은 폴리 녹음 세션을 진행했습니다.

솔직히 말해 저희는 잇 테이크 투 오디오를 제작하는 데에 충분한 시간을 가진 적이 전혀 없기 때문에 농담삼아 '한 번 통과면 그걸로 끝!'이라는 말을 하곤 했습니다. 사실이라고 해도 틀릴 것이 없었죠. 대부분의 경우 언제 다시 돌아가 더 작업할 수 있을지 몰랐기 때문에 한 번의 시도만으로 좋은 사운드를 만들어야 했습니다. 전 이게 건강한 마인드라고 생각해요. 좀 극단적으로 말하자면 첫 번째 레벨에만 공들여 다듬어진 사운드가 있는 것보다 전체 게임에 사운드가 있는 편이 나으니까요.

이런 접근 방식을 가지긴 했지만 저희는 처음부터 아주 높은 품질을 목표로 했습니다. 저희 스튜디오 매니저의 말을 빌리자면 '목표 수준을 아주 높게 잡아 못을 박고 어떤 일이 일어나더라도 이 못을 뽑지 않았다'라고 할 정도였죠. 저희는 그저 현존하는 가장 최고의 사운드를 가진 분할 스크린 게임을 만드는 것이 목표였고, 시간이 엄청나게 촉박하더라도 끝까지 이것을 목표로 했습니다.

마지막에 다시 돌아가서 몇몇 사운드를 추가하거나 확장하고 다듬을 시간이 조금 있었고, 저희는 게임이 저희 손을 떠나 소비자에게 출시되기 직전까지 최선을 다해 가장 멋진 사운드를 제작하도록 힘썼습니다.

앤 소피: 프로젝트의 전체 기간 동안 필립이 짠 계획이 정말 많은 도움을 주었습니다. 이 계획이 없었다면 전체 게임에 훌륭한 콘텐츠를 만드는 것이 불가능했을 거예요. 필립은 사운드 디자인 제작 및 구현, 기술적 시스템 개발 및 반복 작업과 컷씬 오디오 아웃소싱을 모두 포함하여 계획을 짰습니다. 각 레벨과 하위 레벨에 일정 기간의 시간을 할당했고 다듬기와 믹싱 작업에 일부 추가 시간을 감안해뒀죠. 할당해둔 시간을 쓰고 나면 저희는 바로 다음 작업으로 넘어갔습니다. 이 엄청난 시간적인 압박을 감안하여 저희는 첫 번째 작업에서부터 출시할 품질을 만들어내는 방식을 사용했습니다. 사운드 디자인의 품질뿐만 아니라 믹스도 마찬가지였죠. 저희 모두가 지속적으로 믹스를 책임지고 있었고, 게임에 새롭게 추가되는 모든 것들이 나머지 콘텐츠와 일정한 수준으로 유지되도록 했습니다. 마지막으로 저희는 창의성과 상상력을 최대한 이끌어내어 모든 오브젝트와 캐릭터에 생기를 불어넣어 줬죠! 수많은 콘텐츠를 만들어내는 것이 쉬운 일은 아니었지만, 이 프로젝트에서 가장 재미있었던 부분 중 하나이기도 합니다. 

음악

게임의 마지막 레벨이 음악 레벨인데, 사운드가 정말 훌륭했어요! 노래하는 능력을 어떻게 만들어내셨나요? 그리고 음악이 박자 맞추기를 통해 게임플레이를 이끌어가도록 한 건가요?

요아킴: 음악 레벨에는 어떤 모양이나 형태로든 배경 음악으로 제어되는 게임플레이 요소가 상당히 많습니다. 가장 먼저 우리는 메이(May)의 노래하는 능력을 찾게 됩니다. 플레이어는 이 능력을 사용하여 퍼즐을 풀고 레벨을 진행하게 되죠. 플레이어가 능력을 활성화할 때마다 메이는 현재 재생되는 음악의 템포와 장조에 맞춰 노래합니다. 저희는 보컬리스트가 MIDI 트랙을 템플릿으로 사용하여 음악에 멜로디를 노래하도록 해서 이 능력을 실현했습니다. 그런 다음 나중에 게임 엔진이 MIDI 데이터를 읽어서 시스템에게 정보를 전달할 수 있도록 마커로 파싱한 후 음원 파일 안에 새겨집니다.

게임플레이가 오디오 스레드에서 일어나는 이벤트와 동기화되도록 할 경우 잇 테이크 투는 두 플레이어가 같은 장치에서 로컬로 플레이하며 한 Wwise 인스턴스를 공유할 경우뿐만 아니라 네트워크를 통해 온라인으로 연결할 수도 있다는 점을 고려해야 합니다. 이 경우 게임의 두 인스턴스가 별도로 존재하기 때문에 Wwise의 인스턴스도 두 개가 되죠. 게임플레이 상태는 항상 두 게임 인스턴스 간에 통신됩니다. 하지만 두 Wwise 인스턴스의 경우 서로의 상태를 인지하지 못하며 로컬로 실행되는 사운드에 따라 작동할 뿐이죠. 오디오 스레드는 본래 고정된 속도로 실행됩니다. 하지만 메인 스레드의 한 프레임이 계산하는 데 몇 밀리세컨드만큼 더 걸릴 경우 양쪽에서 사운드가 다른 시간에 시작하고 중단될 수 있어요. 대부분의 게임플레이에서 이 영향은 아주 사소합니다. 두 플레이어가 자신에게 '알맞은' 것을 보고 듣게 되니까요. 하지만 이벤트가 한 쪽의 오디오 스레드를 통해 전달되기를 기다리고 양쪽 모두에서 이벤트가 발생하도록 하는 경우 타이밍이 아주 중요해집니다.

음악 레벨의 경우 저희는 이 문제에 부딪히게 됐습니다. 하지만 해결해야 할 다른 문제가 많았기에 여기에 힘쓰지 않기로 했죠. 그럼에도 불구하고 저희는 수많은 음악 콜백을 사용해서 배경 효과나 시각적인 '흥미 요소' 같이 타이밍이 완벽하지 않아도 되는 이벤트를 자유롭게 트리거했습니다. 이 콜백은 일어날 때마다 자유롭게 일어났고 음악적으로 일어나는 일에 시각적으로 동기화되도록 해줬습니다.

그래서 양쪽이 모두 재생되는 음악이 세계에 영향을 주는 것을 경험하게 했습니다. 다른 플레이어의 게임 인스턴스에서 내림박이 아주 아주 몇 밀리세컨드만큼 일찍 시작되어 플레이어가 죽는 이벤트가 트리거된다고 해서 화가 나는 사람은 없을테니까요.

Wwise

Wwise를 오디오 엔진으로 사용해서 득을 본 점이 있었나요? 그렇지 않았을 경우 어떻게 문제를 해결하셨나요?

필립: 잇 테이크 투는 제가 Wwise를 사용해서 제작한 첫 번째 게임입니다. 제가 생각하기에 Wwise는 소련의 자동차 라다(Lada) 같아요. 아주 긍정적으로 하는 말입니다. 그냥 계속 내달리죠! 물론 Wwise에 관한 기술적인 문제도 있었지만 완전히 막다른 길에 다다르는 일은 없었기 때문에 계속해서 작업을 진행할 수 있었습니다. 뿐만 아니라 저를 제외하고 저희 팀에 앤 소피와 요아킴을 포함한 Wwise 전문가가 참 많아서, 이 분들이 나머지 오디오 팀을 많이 가르쳐주고 가이드해줬어요. 그리고 Wwise를 사용하기 시작하는 것이 꽤나 쉬웠던 것 같습니다. 그래서 Wwise를 배우는 것이 아주 높은 산처럼 느껴지지 않았고 빠르게 배워서 바로 사용할 수 있었어요.

Wwise는 전세계 수많은 오디오 팀이 사용하는 도구입니다. 이 점은 아주 좋은 점이지만 한편으로는 Wwise가 한 팀 혹은 한 게임에 완벽히 맞춰진 특정한 작동 방식으로만 돼있지 않다는 것을 의미하기도 하죠. 저희의 경우 물론 대부분 분할 스크린을 다루는 것이 그랬습니다. 아주 분명한 예시 중 하나는 Balance-Fade (2D) 사운드를 중앙 채널로 라우팅하는 문제였습니다. 저희는 스테레오 능력 중앙 채널을 많이 사용하여 게임에서 사운드를 두 부분으로 나눌 수 있으면서도 두 부분 간의 중앙은 공유하여 스테레오 기능을 유지하고 싶었습니다. Wwise는 Balance-Fade와 또다른 중앙 백분율 전송을 지원하지 않았기 때문에 대신 수많은 보조 버스를 만들어서 중앙 채널로 보내는 방법을 개발해야 했습니다.

그림 7: 문제를 피해 작업하기 위해 중앙 채널로 전송할 보조 버스 만들기

요아킴: Wwise는 지속적으로 정말 안정적인 장치입니다. 그렇기 때문에 원치 않은 것이 생겨나거나 필요한 것과는 다르게 작동할 경우 이것도 아주 지속적이고 일정하죠! Wwise는 프레임워크로서 현대 사운드 엔진이 필요로 하는 수많은 기본 기능을 분명히 탑재하고 있습니다. 하지만 Wwise를 사용하여 환상적인 사운드를 가진 경험을 진지하게 개발하려는 모든 스튜디오를 위해 저는 제가 생각하는 Wwise에 존재하는 것과 그렇지 않은 것을 말씀드리고 싶어요. Wwise는 모든 사운드의 필요를 위한 최종적인 솔루션으로 제공되는 것이 아닙니다.

사실 그런 서드파티 도구는 어디에도 존재하지 않아요. Wwise를 비롯한 서드파티 도구들은 모든 게임플레이 상황과 기능에 대한 '준비된' 솔루션을 제공하는 것이 아니에요. 

대신 Wwise는 훌륭한 시작점입니다. 처음부터, 그리고 그 이후 작접 기간 동안 항상 시작점을 마련해주는 '상자'로 제공되며 거기에서부터 여러분만의 훌륭한 장치를 제작할 수가 있어요. 미리 조립되어 있는 부분에만 관심이 있다면 조만간 실망하게 될 것입니다. 이 부분들로부터 무엇을 제작할 수 있는지 흥미가 있다면 아마 만들 수 없는 것이 없을 것입니다. 

저희의 경우 필요에 맞게 Wwise의 기능을 확장하기 위해 딛었던 가장 큰 걸음은 공간화된 신호가 여러 리스너에 의해 처리될 때 이 신호가 조합되는 방법을 변경한 것입니다. Wwise에서 처음 두 리스너로 구성했을 때에는 결과가 만족스럽지 못했고 세계의 몰입도를 떨어뜨렸습니다. 초반의 많은 시험과 노력들이 부족했고 Wwise에서 제공하는 솔루션 하나가 모든 필요를 충족해주지 못했습니다.

다행히 Wwise의 아키텍처는 사용자가 커스터미이징할 수 있도록 설계되었습니다. 물론 사용자가 엔진 깊숙이 들여다볼 준비가 되어있다면 말이죠. 바로 이렇게 저희는 특정한 요구에 맞게 로우 레벨 시스템의 근본적인 것들을 변경하기 시작했습니다. 그렇게 해서 Wwise가 Hazelight를 만나 저희의 필요에 맞는 Spatial Panning을 만들게 되었습니다.

예란: 이 게임은 제가 오디오 프로그래머로서 작업한 첫 프로젝트이기도 하고 제작에 늦게 참여했기 때문에 Wwise의 오토메이션 도구를 제작하고 개선하는 것이 가장 먼저 집중한 작업 중 하나였습니다. 원하는 프로그래밍 언어로 Wwise의 저작 기능을 활용할 수 있게 해주는 WAAPI가 큰 도움이 되었죠. WAAPI는 기능이 완벽하지는 않지만 거의 대부분의 일반적인 기능은 존재하며 Audiokinetic이 계속해서 업데이트하고 개선하고 있죠.

저희가 제작을 시작했을 때에는 Unreal에 Event-Based Packaging(이벤트 기반 패키징)이라는 개념이 없었지만 사실 저희는 저희만의 버전을 이미 시작하고 있었습니다. 저희만의 이벤트 기반 뱅크 생성 통합이 있기는 하지만 여전히 .bnk와 .wem 파일을 사용할 때에는 Wwise에서 제공하는 생성 기능을 사용합니다. 이 기능은 결단적이고 성능이 좋았기 때문에 많은 도움이 되었습니다. 반복 작업으로 낭비되는 시간으로 인해 저희에게 꼭 필요한 기능 중 하나였죠. 

Wwise를 사용하여 분할 스크린 게임을 작업하는 또 다른 스튜디오에게 몇 가지를 추천해주신다면 무엇을 추천해드리고 싶나요?

필립: 패닝과 믹싱을 다룰 규칙을 만들고 이 규칙을 따르세요. 분할 스크린 게임을 만들 때에는 희생해야 할 것들이 생기기 마련입니다. 올바른 사운드를 우선순위에 두고 마지막에 대부분의 사운드를 좋게 들리게 만들어줄 규칙을 만들어야 해요. 이러한 결정을 만드는 것이 쉽지는 않지만 플레이어에게 명확하고 즐거운 경험을 선사하기 위해 꼭 필요한 일입니다.

요아킴: 최대한 빨리 게임의 시각적인 뼈대를 살펴보고 사운드 디자이너로서 어떤 요소가 중요한지 결정하세요. 기준이 되는 지점들을 찾아내서 해당 프레임에서 사운드의 위치를 지정할 때 공간적 일관성의 자료로 사용하세요. Wwise와 에셋을 제작하는 곳에서 모두 규칙과 계층 구조를 더 빨리 설립할수록 계속해서 수많은 변수가 생겨나는 분할 스크린 오디오를 관리하기가 더 쉬워질 것입니다. 마지막으로, 가능한 곳에서 모험 정신을 발휘해 보세요! 분할 스크린 오디오는 저희에게 가장 미지의 영역이었습니다. 다른 게임에서는 볼 수 없는 방식으로 사운드를 통해 새로운 이야기를 전달할 수 있는 가능성도 무궁 무진하죠.

예란: 오디오 프로그래머로서 저는 Wwise 소스 코드가 없었다면 어땠을지 상상되지가 않습니다. 그래서 코드베이스를 배워보라고 권해드리고 싶어요. 겁먹을 필요도 없습니다. 저희 Hazelight 사람들이 '어디 한 번 망쳐보자'라는 자세로 덤벼드는 것처럼요.

앤 소피: 패닝과 믹싱 규칙을 정하고 규칙을 지키라는 필립의 말에 동의합니다. 궁극적으로 사운드가 공간화되는 방식이 분할 스크린의 사운드를 정의하게 됩니다. 최대한 앞 부분에 최대한 일관적으로 이 비전을 구성하고 규칙으로 만들어내면 골치 아픈 일과 번거로움을 줄일 수가 있어요. 잇 테이크 투의 경우 저희에게 적합했던 믹싱 규칙의 예시는 완전히 공간화된 음원을 목표로 하지 않습니다. 대신 스크린 공간을 대부분의 소리풍경의 뼈대로 사용했죠. 이 규칙은 믹스를 명확하게 해주고 분할 스크린으로 인한 혼란과 플레이어와 카메라 각도에 대해 사운드가 재생되는 위치에 대한 혼란을 최소화해줬습니다. '스크린 공간을 뼈대로 사용한다는 것'은 의도적으로 수많은 사운드를 공간화하지 않고 (2D) 영화같은 선형 매체와 같이 좌측-중앙-우측 스피커에서 재생해서 최대한 정확하고 상세하게 시각적인 요소와 대응하도록 하는 것을 말합니다. 물론 캐릭터 자체에서 나오는 소리(폴리, 캐릭터가 운전하는 자동차, 플레이어의 능력)나 항상 시각적인 프레임 틀 안에 있는 사운드(예: 짧은 단발성 사운드)와 같이 공간화하지 않는 것이 타당한 사운드만 2D로 남겨뒀습니다. 따라서 선형적인 분할 스크린 게임의 경우 완전히 공간화하는 것보다 더 결정적인 사운드 디자인과 믹싱 접근 방식을 꼭 탐험해 보셨으면 좋겠어요.

Hazelight 오디오 팀이 계속해서 생겨나는 문제를 극복하고 성공할 수 있었던 이유는 팀 내에서 창의적/기술적 디자이너들 간의 지속적인 협업이었습니다. 실제로 사운드 디자이너, 작곡가, 테크니컬 사운드 디자이너, 오디오 프로그래머가 모두 자신만의 강점과 능력을 기여할 뿐만 아니라 서로의 지식에 의지하여 탄탄한 협업으로 최고의 수준을 이끌어낼 수 있었죠. 명확하고 쉽게 타협하지 않는 비전, 안정적이며 커스터마이징할 수 있는 도구의 사용, 현존하는 최고의 분할 스크린 게임 사운드를 만들고자 하는 욕망이 잇 테이크 투의 오디오 경험을 성공으로 이끌었습니다.