저희 Obsidian 오디오 팀은 Wwise와 Unreal을 사용하여 아우터 월드(Outer Worlds)의 사운드, 음악, VO를 제작한 방식을 두 편의 글로 심층적으로 알려드리려고 합니다. Wwise는 작업 과정에서 필수적인 부분이었으며, 저희의 창의적 열망을 현실화하는 데에 필요한 유연성과 기능을 제공해 주었습니다. 이 블로그 시리즈의 제 1부에서는 생물들의 소리, 음악, VO, AI 대사 (대화 소리), 공간화를 구현한 방식을 함께 살펴봅시다.
생물 소리
아우터 월드는 작은 것부터 큰 것, 적대적인 것부터 우호적인 것, 유기적인 것부터 무기적인 것까지 다양한 NPC 생물들로 가득 차 있습니다. 저희는 이 생물 오디오를 만드는 데에 신뢰성과 정서를 주요 목표로 잡았습니다. 모든 생물들이 청각적으로 믿을 만하며 아우터 월드의 세계에 있을 법하게 만들려고 노력했죠. 대부분의 경우 외계적이면서도 친숙한 소리를 만드는 것이 숙제였습니다. 그뿐만 아니라 저희는 이 생물들이 플레이어에게 효과적이며 감정을 일으키도록 했습니다. 때로는 어떤 생물의 주요 기능이 위험하고 위협적인 느낌을 주는 것일 수도 있고 어떤 때에는 편안하고 마음을 누그러뜨리는 것일 수도 있죠. 모든 경우에서 생물은 그들의 환경에 대한 이야기를 들려줄 수 있도록 설계되었습니다. 다음은 저희가 믿을만하고 효과적인 생물 오디오를 만들기 위해 사용한 몇 가지 방식입니다.
설계 전 고려 사항
생리학
먼저 각 생물의 생리학에 집중하여 생물 오디오 설계에 접근했습니다. 다시 말해 생물의 신체 구성과 구조를 고려했죠. 그런 다음 음원을 수집하고 편집할 때에 시도해볼 방향을 고안했습니다. 다음은 아우터 월드의 각 생물 소리 제작 방식을 결정할 때 초점이 된 몇 가지 내용입니다.
Mantisaurs(맨티사우루스)는 거대한 곤충이며 게임에서 가장 강력한 적들 중 하나입니다. 외골격은 비늘로 덮여 있으며 경련에 떨며 정신없이 움직이는 기괴한 아래턱뼈를 가지고 있어요. 그렇기 때문에 꽤액거리고 찰칵거리며 스타카토적인 요소를 많이 사용하여 소리를 설계했습니다.
Biped Robot(두발 로봇)은 거대하며 굉장히 튼튼한 양철 로봇입니다. 속도는 느리지만 아주 강력하며, 플레이어의 액션에 따라 친근하거나 적대적일 수 있죠. 이런 두툼한 제작 구조는 무겁고 금속적이며 합성적인 요소를 사용하도록 영감을 주었습니다.
Sprat(스프래트)는 아주 귀여운 움직임을 가진 작은 도마뱀 설치류입니다. 특히 플레이어에게 우호적이며 가끔 어떤 환경을 통해 플레이어의 길을 이끌어 주기도 하죠. 이러한 특징은 귀엽고 쾌활하며 호기심 많은 음성적 요소를 사용하는 데에 영감을 주었습니다.
호흡
생물의 음성을 현실적으로 만들기 위해 저희가 고려한 또 다른 점은 호흡 방식입니다. 일반적인 호흡에서는 공기를 많이 필요로 하는 발성 전후에 폐가 공기를 다시 채워야 합니다. 재충전은 들숨이고 배출은 날숨이죠. 저희는 공격음과 같은 큰 발성에 이 아이디어를 적용하여 큰 숨을 내쉬는 공격음이나 크게 움직이는 소리 전후에 가능할 때에는 언제든 들숨 소리가 트리거 되도록 했습니다. 이렇게 해서 우리에게 자연스럽게 익숙한 물리적인 현실감을 생물에게 줄 수 있었죠. 이 작업은 생물이 필요로 하는 것과 작동 방식에 따라 다양한 방법으로 성취되었지만 보통 여러 개의 Play Action, Blend Container, Sequence Container가 있는 오디오 이벤트와 애니메이션 내 별개의 이벤트를 사용하여 성취되었습니다. 다음은 아래에서 더 자세히 살펴볼 이 구현의 몇 가지 예시입니다.
들숨을 사용한 Canid(캐니드, 갯과동물) 공격음
들숨을 사용한 Primal(프리멀, 원시동물) 공격
움직임
생물들이 몸을 움직일 때 보통 들숨과 날숨을 리듬적으로 순환합니다. 저희는 이 부분을 생물의 움직임에도 포함하고자 했습니다. 이렇게 하면 리듬과 에너지를 전달하는 데에도 도움이 됩니다. 다음은 저희가 움직임과 호흡을 사용하여 생물에 자연스러운 리듬과 현실감을 더한 몇 가지 예시입니다.
Primal 걸음 리듬
Raptidon(랩티돈, 파충류) 달리기 리듬
Mantisaur 공격 리듬
구현과 튜닝
사운드 오브젝트 구조
저희는 Priority(우선 순위)와 Voice Limiting(보이스 제한)과 같은 중요한 매개 변수를 세부적으로 제어할 수 있도록 생물 Actor-Mixer를 생물 소리의 유형별로 구분했습니다. 또한 각 믹서에서 서로 약간 다른 Positioning 설정을 사용했습니다. 예를 들어 폴리(foley) 사운드는 상대적으로 감쇠 반경이 좁은 반면 생물의 전투 음성과 무기 소리는 좀 더 멀리서도 들려서 전투 도중 플레이어에게 올바른 피드백을 제공해 줍니다.
생물 무기 소리 Attenuation Shareset
저희는 다양한 사운드 오브젝트 컨테이너를 사용하여 생물 오디오를 트리거 했습니다. 저희는 Sequence Container, 시간 지연이 있는 Blend Container, 여러 Play Action이 있는 Event를 사용하여 큰 발성 후 들숨 소리와 같은 것을 구현할 뿐만 아니라 좀 더 소리를 많이 내는 일부 생물에게 음성적인 억양을 만들어주었습니다. 다시 말하지만 생물에 따라 다른 구현 방법이 필요했기 때문에 이러한 것들을 몇 가지 다른 방식으로 트리거하고 제어할 수 있었던 것이 아주 도움이 되었습니다. Wwise는 특히 이러한 것들을 아주 잘 제공해 주는 도구입니다.
이미터 경로 오토메이션(자동화)
아우터 월드에 있는 생물들은 근거리와 장거리에서 수많은 공격을 할 수 있습니다. 할퀴기와 같은 근거리 공격의 경우 Emitter Path Automation(이미터 경로 오토메이션)을 사용하여 스테레오 음장을 가로지르는 움직임을 주었습니다. 휘두르는 공격 사운드 오브젝트에 생물 팔다리 애니메이션을 따르는 간단한 경로를 만들었죠. 이렇게 작은 편집만으로 생물의 공격을 더 동적이고 현실적으로 만들 수 있었습니다.
사내 도구
저희 회사 내에서 직접 개발한 개발 도구도 아주 다양한 기능을 가지고 있는데, 저희는 이 도구의 일부를 활용하여 Chatter Event를 사용하여 생물 소리를 트리거 하였습니다. 이러한 이벤트는 캐릭터가 가질 수 있는 특정 AI 작동 방식과 상태 (개인 공간 입장, 조사, 대상 놓침, 대상 재획득 등)에 따라 트리거 됩니다. 이렇게 하면 특정 상태로 들어가거나 나올 때 해당 상태에 사운드 이벤트를 넣을 연관 애니메이션이 없더라도 생물 사운드를 트리거하도록 할 수 있기 때문에 사운드 디자이너에게 더욱 힘을 실어줍니다. 또한 시스템의 내장 우선순위와 각 이벤트나 그룹 레벨에 따라 지정될 수 있는 쿨다운 속성을 사용하여 각 생물에 대한 이벤트의 흐름도 제어할 수 있습니다.
생물 대화 이벤트
게임에서 로봇의 '개인 공간 입장' 대화 소리 이벤트
UNREAL ENGINE 4(언리얼 엔진 4): 애니메이션 타임라인 이벤트
저희는 꽤 일반적인 사용 방식인 생물의 다양한 동작에 맞는 오디오 이벤트를 트리거 하는 애니메이션 타임라인을 사용했습니다. 애니메이션 타임라인을 사용하여 저희는 대부분의 생물 소리뿐만 아니라 '생물 대화 소리(Creature Walla)'라는 개념도 구현했습니다. '멀리서 생물의 음성이 들린다면 근처에 생물이 있다'라는 것이죠. 거리에 따라 처리되는 생물의 목소리를 트리거 함으로써 저희는 방해받지 않은 보금자리에서의 생물을 시뮬레이션하고 환경음에 보탬이 될 수 있게 해주었습니다.
Creature Walla 이벤트는 적대적인 생물이 멀리 떨어져 있을 때 존재를 알리기 위해 대기(idle) 및 비전투 애니메이션에서 트리거 됩니다. 이러한 소리는 플레이어에게 생물의 위치와 해당 지역에 있는 생물의 일반 밀도에 대한 유용한 피드백을 제공해 주며 레벨의 환경음에 상황에 특정한 소리를 가미해 줍니다.
Creature Walla 사운드 이벤트의 재생은 거리 RTPC, Priority, Voice Limiting, Virtual Voice 작동 방식에 의해 제어되어 믹싱을 용이하게 해주며 보이스 개수가 너무 많아지는 것을 방지해 줍니다. 각 주요 생물류는 트리거 할 수 있는 두 세트의 Creature Walla 사운드를 가집니다. 저희는 이러한 오브젝트가 Physical Voice로 전달이 되도록 허용되는 거리와 우선순위 경계를 적극적으로 정의하여 어떤 사운드 오브젝트가 들리는지를 제어합니다. 'Walla' 오브젝트는 4000-6000 Wwise 단위 (40-60미터) 사이에서 들리며 'Ambient' 오브젝트는 6000-8000 Wwise 단위 (60-80미터)에서 들리죠. 4000 미만의 거리에서는 생물이 정확하게 보이며 플레이어가 잠재적으로 당면할 수 있는 범위에 있기 때문에 생물의 대기 동작 애니메이션과 동기화된 오디오에 의존합니다. 반대로 이러한 대기 애니메이션 오디오 이벤트는 코드와 Virtual Voice 작동 방식에 의해 점진적으로 추려집니다. 이렇게 하면 플레이어로부터 생물이 얼마나 멀리 떨어져 있는지에 상관없이 사운드 오브젝트의 한 하위 세트만 들리도록 할 수 있죠.
이러한 이벤트는 Probability(확률)와 Delay(지연)를 활용하는 여러 Play Action에 의존하여 자연 속 여러 생물 간의 '부르고 응답하기'를 시뮬레이션 합니다.
저는 Ableton Live 안에서 기본 변조기(modulator) 도구 (LFO와 엔벨로프)를 활용하여 기존에 설계한 생물의 음성을 사용한 새로운 에셋을 만들었습니다. 이 변조기는 음성 샘플의 피치와 진폭에 약간의 랜덤 변조를 지속적으로 적용합니다. 이와 함께 듀얼 프리페이더 잔향과 딜레이 리턴 트랙을 사용하여 각 생물에 맞는 원거리 음성을 아주 효율적으로 대량 제작할 수 있었습니다.
원거리 생물 대화 소리(Creature Walla) 처리 Ableton 효과 사슬
게임 내 생물 대화 소리(Creature Walla)
매개 변수와 믹싱
저희는 Wwise의 수많은 기본 매개 변수를 생물 소리에 사용하여 플레이어의 주의를 이끕니다. 이렇게 함으로써 플레이어에게 전송되는 오디오 피드백을 정제할 뿐만 아니라 특정 상황에서 믹스를 더욱 선명하게 만들 수 있었어요.
Listener Cone (리스너 원추형) 매개 변수는 플레이어 뒤에 있는 생물의 볼륨과 존재감을 약간 줄이기 위해 사용되었습니다.
Azimuth (방위각) 매개 변수는 플레이어의 근시에 있는 생물을 강조하고 플레이어의 좌우 끝에 있는 생물에 약간의 잔향을 더하는 데에 사용되었습니다.
Elevation (높이) 매개 변수는 플레이어보다 아주 위에 있거나 아래 있는 생물의 볼륨과 존재감을 감쇠하고 공간의 깊이를 증대하기 위해 약간의 잔향을 더하는 데에 사용되었습니다.
게임에 있는 수많은 다른 소리와 마찬가지로 생물의 소리도 게임에서 정의한 잔향으로 전송되어 환경에서 생물의 깊이감을 줍니다. 그뿐만 아니라 저희는 'Abbey Road(애비 로드)' 효과를 시뮬레이션할 수 있도록 게임에서 정의한 센드를 필터링합니다. 이 모듈레이션은 잔향 리턴 신호에서 과도한 주파수 증대를 방지하고 더욱 분명한 변조/원본 신호 믹스를 만들 수 있게 해줍니다. 이렇게 하니 생물 소리가 환경음에 더욱 자연스럽게 섞여지는 것을 느낄 수 있었어요.
음악
아우터 월드의 음악은 핼시언(Halcyon) 식민지와 그 환경을 지나가는 여정에 광대함과 경이로운 느낌을 제공함으로써 플레이어의 몰입감을 향상시키고 감정을 고조시키는 것을 목표로 합니다. 환경적이면서도 원치 않은 때에 너무 지나친 관심을 끌지 않도록 충분히 최소한으로 유지하는 단일하고 기억에 남을 만한 음악을 만드는 것이 저희의 의도였죠. 게임에서 거의 모든 주요 퀘스트 영역에는 해당 영역의 세계 구축과 숨겨진 이야기를 뒷받침하는 그 자체만의 탐험과 전투 음악이 있습니다. 탐험은 이 게임의 아주 큰 요소이며 플레이어가 대부분의 시간을 탐험하면서 보내기 때문에 음악 자체도 5~8분 정도로 긴 편입니다.
저희가 음악을 사용하여 감정적으로 마음을 사로잡은 방법을 다음 내용을 통해 살펴봅시다
- 특히 초반에서 순간에 따른 스크립팅을 많이 사용하여 전반적으로 주요 테마를 더하여 통일함
- 일부의 모듈식 및 반응적 음악
- 상호작용 음악 시스템 (예시를 통해 설명)
- Wwise에서 상호작용 음악이 구성된 방식
Interactive Music Hierarchy 구조
대부분의 경우 저희는 전체 게임에서 하나의 Switch 컨테이너와 하나의 State Group을 사용합니다. 하지만 추가적으로 상태, RTPC, Music Track 스위치를 사용한 경우도 꽤나 있었습니다. 알리(Ali)가 말하기를 State Group에 State가 203개나 있다고 하더군요. State는 두 개의 음악 유형으로 묶어질 수 있습니다:
- 기본 맵 음악 (예: 탐험 및 전투 음악)
- 스크립트 된 음악 (예: 나레이션이 시작되거나 플레이어 경험으로 인해 기본 음악을 덮어쓸 수 있는 음악)
플레이어가 언제든지 즉시 한 음악에서 다른 음악으로 전환할 수 있게 해야 했기 때문에 저희는 하나의 거대한 State Group과 하나의 마스터 Switch를 사용하기로 했습니다. 그리고 Wwise의 멋진 전환 효과 관리자를 사용해서 모든 전환 효과가 음악적으로 진행되도록 하고 싶었습니다. 전환 효과에 대해서는 조금 뒤에 더 살펴보도록 하겠습니다.
State에 대해 짧게 말씀드리고 싶은 부분이 있습니다. 203개의 State는 관리하기에 꽤나 많기 때문에 Wwise 에디터 안에서 탐색하기가 번거로울 수 있습니다. 일관적이고 읽기 쉬운 명명 규칙을 가지는 것이 핵심이에요. 저희 Obsidian에서는 레벨 디자이너가 고유의 숫자 식별자를 접두사로 사용하여 레벨을 표식 합니다. 저희가 대부분 음악을 레벨에 따라 묶기 때문에 (아래 설명 참고) 이 고유의 숫자 식별자를 State 이름으로 유지해서 쉽게 정리할 수 있었습니다. 그리고 음악 Switch에서 사용하지 않도록 설계된 State를 'makers'로 추가해서 한 레벨이 시작되고 끝나는 지점을 시각적으로 표시했습니다.
기본 상호작용 음악의 흐름
대부분의 경우 아우터 월드에 있는 음악은 아주 기본적인 방법으로 상호작용적이며, 주로 탐험과 전투 음악 사이의 간단한 전환 효과로 구성되어 있습니다. 또한 이 작동 방식은 원하는 대로 스크립트 된 음악을 트리거 하도록 조건적으로 덮어쓰일 수 있습니다. 플레이어가 주어진 맵으로 로드 할 경우 로딩 스크린 동안 레벨의 탐험 음악을 재생해서 플레이어가 기다리는 동안 먼저 분위기를 잡아줍니다. 플레이어가 맵 안으로 로드되면 전투나 스크립팅을 통한 덮어쓰기로 음악이 방해받기 전까지 계속해서 탐험 음악을 재생합니다. 전투가 끝나거나 스크립팅 된 음악이 끝나면 탐험 음악이 다시 재개됩니다. 플레이어가 맵에서 나가면 현재 음악이 페이드 아웃되며 주기가 다시 처음부터 시작됩니다. 기본 State 장치는 다음과 같습니다:
음악 관리자
음악 State 사이의 전환 효과를 안정적이고 체계적으로 관리하기 위해, 이 부분을 코드 방면에서 처리할 수 있는 솔루션이 필요했습니다. 저희 Obsidian의 아주 유능한 게임플레이 프로그래머 중 하나인 제러드 던(Jerad Dunn)은 게임과 Wwise 사이에 레이어로서 작동하는 간단하지만 강력한 음악 관리자 시스템을 제작하여 다음이 실행될 수 있도록 했습니다:
- 모든 기본 음악이 알맞은 시점에서 트리거 됨
- 스크립팅 된 모든 특수 덮어쓰기의 State가 지속적인 방식으로 저장됨
Obsidian에서 저희는 현재 게임 상태를 저장 파일에 저장하여 저장된 파일을 다시 로드 할 때 가져올 수 있도록 하는 것을 '지속성'이라는 용어로 정의합니다. 음악의 경우 저희는 이 지속성을 사용하여 기본 음악이 덮어쓰인 경우 플레이어가 게임을 저장하고 다시 로드 할 때에 계속해서 덮어쓰인 음악이 재생될 수 있도록 해줍니다.
또한 음악 관리자는 맵마다 탐색과 전투 음악 기본 세트를 정의하도록 해줍니다. 현재 아우터 월드에는 43개의 음악 세트가 있죠. 각 맵에는 데이터에서 정의된 탐험과 전투 음악 기본 세트가 있습니다. 그리고 조건적 덮어쓰기도 맵마다 정의됩니다. 덮어쓰기는 게임플레이 도중 언제든지 트리거 될 수 있으며, 기본 탐험>전투>탐험 전환 효과 작동 방식을 완전히 덮어씁니다. 조건적 음악이 활성화되면 플레이어가 전투를 시작하더라도 전투 음악이 트리거 될 수 없게 됩니다. 스크립팅 된 음악을 종료하려면 추가적인 스크립팅이 필요합니다. 그리고 관리자를 나가면 계속해서 탐험 음악이 재개되며, 전투 음악이 트리거 될 수 있는 상황이 오면 전투 음악이 시작됩니다.
다음은 데이터가 저장되는 방식을 보여줍니다. 아우터 월드는 Unreal 4를 사용하여 개발되었으며, 저희는 Data Asset을 사용하여 탐험과 전투 기본 음악에서 어떤 음악을 트리거 해야 할지를 표시해 주었습니다. 그리고 Data Asset을 사용하여 음악을 조건화하기도 했습니다. 다음은 저희 Music Gameplay Settings Data Asset과 일부 주요 기능에 대한 간단한 설명입니다:
- A - 맵의 기본 탐험 음악을 정의합니다
- B - 맵의 기본 전투 음악을 정의합니다
- C - 조건적 음악을 추가합니다. 이 부분은 사용자가 정의하며 순서를 재구성할 수 있는 배열입니다. 게임은 이 논리의 흐름을 배열의 맨 위에서부터 아래로 읽습니다.
- D - 조건을 정의합니다. Obsidian에서는 퀘스트의 상태를 추적하는 데에 사용할 수 있는 Global Variable을 호출하는 사용자 정의 조건을 사용합니다. 이 변수는 지속적으로 저장됩니다.
- E - 조건이 성립할 때 트리거 해야 할 음악을 정의합니다.
음악 시스템은 각 프레임에서 Data Asset에 열거된 Global Variable이 업데이트되었는지를 확인합니다. 변경된 것을 확인하자마자 이 시스템은 조건적 음악 배열에서 성공적으로 맞춰진 첫 번째 조건에 연관된 음악을 재생합니다. 음악이 실제로 트리거되는 시기는 Wwise에서 설정된 전환 효과 작동 방식에 의해 제어됩니다.
스크립팅 된 상호작용 음악 예시 A
이야기가 발전되는 게임의 서술적 맥락을 뒷받침하기 위해 저희는 조건화된 음악을 사용했고, 두 가지 방법 중 하나로 이렇게 하였습니다. 첫 번째 방법은 플레이어가 게임의 주어진 부분을 진행하면서 새로운 음악이 겹쳐 재생되도록 트리거 하는 간단한 순차적 이벤트로 구성되어 있습니다. 이 방법을 사용했을 때 시퀀스의 각 부분이 음악적으로 유기적이고 불투명한 방식으로 진행되도록 각별히 신경을 썼습니다.
이를 보여주는 한 가지 좋은 예시는 게임의 초기 시작 영역에서 플레이어가 미래의 우주선인 '디 언릴라이어블(The Unreliable)'을 발견하기 전까지의 부분입니다. 게임의 이 섹션은 꽤나 선형적이며, 게임의 흐름을 따라 중요한 순간에서 음악을 변경했습니다. 이러한 순간들을 아래 간단하게 요약해 보았습니다:
A.플레이어가 Emerald Vale(에메랄드 베일) 행성에 불시착하여 탈출 포드에서 나왔을 때
B.플레이어가 Guard Pelham(펠햄 경비원)과 대화할 때
C.플레이어가 도입부 동굴을 떠나 Marauder(마로우더)와 마주쳤을 때
D. 플레이어가 처음으로 'The Unreliable(디 언릴라이어블)'을 봤을 때
E.경로를 따라 이 시점에서 플레이어는
i.Unreliable로 들어가 조사를 진행하거나
ii.이를 무시하고 Emerald Vale을 탐험하기를 시작할 수 있습니다.
3단계까지에서 음악 스크립팅은 꽤나 간단합니다. 플레이어가 선형적인 경로 안으로 제한되기 때문에 스크립팅도 전반적으로 아주 선형적이기 때문이죠. 하지만 이제 플레이어가 무엇이든지 할 수 있으며 어떤 선택을 할지 모르기 때문에 상황이 좀 더 까다로워집니다. 그렇기 때문에 음악적으로 좋은 흐름을 유지하면서 플레이어의 선택을 다룰 방법을 결정해야 했습니다. 따라서 4단계에서는 플레이어가 알아차리지 못하게 음악이 자연스럽게 흐르도록 하기 위해 조금 더 복잡한 스크립팅이 필요했습니다.
다음은 플레이어가 Emerald Vale에 불시착하여 원하는 대로 세계를 탐험해볼 수 있기 전까지 음악의 흐름입니다. 그리고 다음에 있는 두 동영상은 게임에서 이 흐름을 보여줍니다.
Wwise 음악 전환 효과
저희는 Wwise 온라인 튜토리얼에서 설명한 음악 전환 효과 외에 특별한 작업을 할 필요가 없었습니다. 하지만 기본 전환 효과가 맵과 맵 사이에서 일정하도록 하면서 위에서 설명한 것과 같은 스크립팅 된 시퀀스에 맞춤화된 전환 효과를 만들 수 있는 유연성을 제공할 수 있도록 Interactive Music Hierarchy 안에서 전환 효과를 구성했습니다.
이전에 말씀드린 것처럼 저희는 전체 게임에서 단 하나의 Switch Container를 사용했습니다. 이 스위치 안에서 음악은 게임 기능 (예: 탐험, 전투, 스크립팅 된 부분, 전역적 등)에 따라 묶여진 Virtual Folder 안에 저장되었습니다.
Wwise는 Virtual Folder 간으로 전환할 수 있게 해줍니다. 이 Virtual Folder는 여러 음악을 위해 전환 효과 규칙을 맞춤화하지 않아도 될 경우에 아주 간편하게 사용할 수 있으며, 소비되는 시간이나 사용자 오류가 일어날 가능성을 줄여줍니다. 저희는 이 기능을 최대한 사용하여 버그 발생을 줄이고 맵과 맵 사이에서 전환 효과 작동 방식이 일정할 수 있도록 해주었습니다. 이 기능은 특히 Exploration (탐험, 아래 그림에서는 'Ambient'라고 되어있음)에서 Combat(전투)로, 그리고 Combat에서 Exploration으로 가는 기본 전환 효과에서 아주 유용했습니다.
맞춤 마커를 사용하여 다양성 높이기
저희가 시도했던 작은 것들 중 하나는 바로 Combat에서 Exploration으로 갈 때의 전환 효과가 반복적으로 들리지 않게 하는 것이었습니다. 그렇게 하기 위해서 저희는 Combat에서 전환할 때 Destination>Sync>Random Custom Cue 전환 효과 작동 방식을 사용했습니다.
Custom Cue는 Exploration 트랙의 뮤직 세그먼트에 있는 전략적 위치에 배치되어 전환 효과를 음악적으로 만들어줍니다. 음악이 페이드 인되지 않고 마치 내림 박자에서 다시 시작되듯이 들리는 것처럼 하는 것이 저희 목표였습니다 (하지만 게임에서 음악이 페이드 인 되는 부분도 종종 있습니다). 다행히 탐험 음악에 빈 부분이 많아서 음악의 시작점을 찾는 것이 크게 어렵지 않았습니다.
다음은 Emerald Vale에서 Exploration 음악에 사용된 Custom Cue와 오디오 예시입니다.
Combat To Exploration Music, Transition A |
|
Combat To Exploration Music, Transition B |
|
Combat To Exploration Music, Transition C |
|
이미터(Emitter)와 환경음
아우터 월드에서 저희에게 반드시 필요하다고 즉시 느낀 것은 바로 대량의 이미터를 제작하고 구현하는 것이었습니다. Obsidian은 플레이어가 이야기, 캐릭터, 세계에 완전히 몰입되는 것을 아주 중요시하는 게임을 만들기 때문에 저희도 세계의 환경 오디오를 현실적으로 만들어서 이 부분을 뒷받침하고 싶었습니다.
다음은 'Geothermal Plant' 레벨에 있는 Ak Ambient Object의 예시입니다:
세계를 더욱 현실적으로 만들어주기 위한 일부분으로 저희는 '이 세계가 실제로 어떤 소리를 가질까?'라는 질문을 해봤습니다. Halcyon의 던전, 집, 공장의 구석진 곳에는 항상 지저분한 기계들이 많이 있습니다. 저희는 이 기계가 마치 부분 부분이 떨어져 나가는 것처럼 느껴지도록 하고 싶었습니다. 그래서 기계가 아주 비효율적으로 작동되며 불순물로 가득 차고 부서지는 것처럼 느껴지도록 노력했어요. 그렇게 하기 위해서 저희는 대부분 Sanken CO-100k 마이크를 사용하여 Obsidian의 멋진 소품실에 있는 잡다한 물건과 철이 떨어지는 소리를 녹음했습니다. 이 마이크는 아주 높은 샘플 레이트로 녹음할 수 있고 고주파수가 감소하기 전까지 거의 2-3 옥타브 아래로 내릴 수 있게 해준다는 점에서 아주 훌륭해요. 이를 통해 저희 세계에 있는 기계에 풍부하고 그럴듯한 현실감을 더해주었고 세계가 가진 느낌에 더 잘 섞여질 수 있도록 할 수 있었습니다.
아우터 월드에서 오디오 이미터가 필요한지를 결정하는 작업은 아주 유기적이었습니다. 던전이나 마을 중 하나를 로드하여 돌아다니면서 어떤 것들이 플레이어의 몰입감을 높여주고 상세함을 최대한 높일 수 있는지를 살펴보았죠. 이렇게 해서 일부 영역의 씬에서는 수백개, 심지어는 수천개의 이미터가 생기게 되었습니다. 저희는 가장 크고 '가장 중요한' 이미터를 우선시했습니다. 이 방법때문에 나중에 프로젝트 후반부에서 플레이어 경험에 가장 역할이 컸던 이미터를 놓치는 슬픈 결말이 생겼지만요.
저희는 Wwise에서 대량의 이미터를 관리할 때, 저희는 이해하기 쉬우면서 동시에 '일반' 이미터에 비해 아주 특별한 처리가 필요한 극한의 상황에 필수불가결한 이미터에 유연성을 제공할 수 있는 방식으로 이미터를 묶어 넣었습니다. 이렇게 하기 위해 이미터에 Emitter_Small, Emitter_Medium, Emitter_Large, Emitter_Unique (돌이켜보면 1~2 개의 세분적인 크기의 유형으로 나누는 것이 좋았을 것 같네요)라는 4 개의 Actor-Mixer를 사용했습니다. 이렇게 해서 사운드를 제작하여 이 4 개의 Actor-Mixer 중 하나에 넣어 감쇠 반경과 RTPC 같은 속성을 그대로 이어받을 수 있었습니다. 한 가지 예외 사항이 있다면 바로 Emitter_Unique 안에 있는 사운드인데, 이 사운드에는 아주 특정하거나 불규칙한 감쇠 곡선이 필요했습니다. 이렇게 해서 Wwise에 넣었을 때 어떤 매개 변수가 사용될지 정확하게 알 수 있다는 데에 안심하며 사운드 디자인의 반복 작업을 빠르게 할 수 있었습니다.
저희는 기본 매개 변수인 Listener-Cone(리스너 원추형)과 Elevation(높이)을 이미터에 사용했습니다. 이것을 잘 보여주는 예시 중 하나는 저희 게임에 있는 작은 전기 스파크 VFX를 구현한 방식입니다. 이 VFX는 아주 자주 사용되며 시각적으로 꽤 강렬한 전기 충격음이 필요한 효과였습니다. 저희는 이 VFX에 연결한 사운드가 플레이어가 항상 듣게 되면서 거슬리기 시작할 수 있다는 것을 알았습니다. 그래서 'Listener Cone'이 있는 꽤나 급격한 RTPC 곡선을 추가해서 사운드의 볼륨과 LPF를 구동했습니다. 이렇게 하면 플레이어가 전기 스파크를 직접 보고 있을 때 꽤나 크고 존재감 있는 사운드를 듣게 되지만, 이미터에서 돌아서면 사운드가 거의 완전히 들리지 않게 되죠. '보이지 않는 것은 마음에서도 멀어진다'라는 철학이었습니다. 플레이어는 뒤돌아보면서 전기 스파크 소리가 들리지 않는 것을 알아차리지 못하겠지만, 이를 통해 저희는 믹스에서 공간을 좀 더 만들고 플레이어에게 사운드가 너무 반복적이지 않도록 해줄 수 있었습니다.
저희는 Wwise의 'Occlusion' 매개 변수도 이미터에 활용했습니다. 여러 개의 하위 버스로 Emitter Audio Bus를 나누어 넣었죠. 한 하위 버스는 차단이 완전히 일어나고, 한 하위 버스는 차단이 부분적으로 일어나며, 나머지 한 하위 버스는 차단이 일어나지 않습니다. 저희는 이 하위 버스를 사용해서 이미터와 리스너 (플레이어) 간에 문이 있을 때 사운드가 문을 통해 원래대로 들려야 할지, 감소되거나 조용해져야 할지, 혹은 완전히 뮤트 되어야 할지를 결정합니다.
아우터 월드 개발 도중 저희가 당면한 문제 중 하나는 전체 게임에서 일정하고 정확하며 적절한 시기에 이미터를 전달할 좋은 시스템을 만드는 것이었습니다. 저희 테크니컬 사운드 디자이너인 제릭 플로어스( Jerrick Flores)는 레벨에 어떤 고정적 메쉬가 있는지 식별한 후 해당 고정적 메쉬에 이미 게임 오브젝트에 지정된 특정 속성 (예: 올바른 Wwise 이벤트)이 있는 Ak Ambient Sound를 스폰 하는 도구를 제작해 주었습니다. 이렇게 해서 환경 이미터를 아주 빠르게 배치하고 사운드 디자인과 믹싱 요소를 반복 작업하는 시간을 더 확보할 수 있었어요. 이를 통해 개발 과정에서 수동적 구현에 집중하지 않고 플레이어의 경험을 더욱 고려할 수 있었습니다.
이전
이후
이전
이후
이런 방식으로 이미터를 제작하고 구현하고 나니 최적화와 성능 문제를 해결해야 했습니다. 첫 번째 문제는 Registered Object(등록된 오브젝트)의 개수였어요. 이미터 도구를 실행한 씬에 따라 이미터가 너무 많이 생기기도 하더라구요. 이미터 도구는 알 수 없는 지하에 배치된 고정적 메쉬나 땅으로부터 100피트만큼이나 떨어져 있어서 플레이어가 절대 닿을 수 없는 작은 전구를 구별해내지 못합니다. 그래서 이런 고정적 메쉬에도 올바른 이미터를 배치하게 되죠. 이미터 스포너 도구를 사용하고 난 후 저희는 가장 먼저, 제작된 모든 이미터를 확인하면서 불필요하거나 들리지 않을 것들을 삭제합니다. 이 작업 과정은 아주 길어지기도 하지만 저희 오디오 스레드의 측면에서 아주 도움이 됩니다. 그다음으로 저희가 해결해야 했던 문제는 바로 보이스 개수입니다. 원래 모든 이미터가 가상 보이스로 전송되었는데, 물리적 보이스만큼 비용이 크지 않더라도 수백 개의 보이스가 쌓이면서 비용도 점점 커지게 되죠. 저희는 레벨에서 Ak Ambient Sound 오브젝트에 정해진 반경 밖에 있을 경우 사운드를 '추려낼 수' 있는 기능을 얻기 위해 프로그래밍 면에서 필요한 지원을 열거했습니다. 이 Cull Radius는 플레이어가 반경 밖에 있을 경우 보이스를 가상으로 보내는 대신 멈춥니다. 이렇게 하면 레벨에 500개의 이미터가 있을 경우 10 개의 물리적 보이스와 490개의 가상 보이스가 생기는 대신 동시에 총 15-20 개의 보이스만 가질 수 있습니다. 이 기능으로 인해 큰 변화를 얻을 수 있었습니다.
저희 게임에서 환경음의 경우 플레이어에게 흥미롭고 세부적이며 믿을만한 분위기를 제공하면서 전체 게임에 맞게 충분히 모듈식으로 유지될 수 있도록 하고 싶었습니다.
게임의 모든 영역을 충분히 다루기 위해서 저희는 환경음을 Exterior Beds (외부 배경음)과 Roomtones(공간음)이라는 두 개의 주요 유형으로 나누었습니다. Exterior Beds는 지정된 영역 (Emerald Vale, Roseway, Monarch, Edgewater 등)에 따라 모두 고유하지만, 공간음은 게임의 모든 영역에서 공유됩니다. 저희는 게임에 존재하는 모든 표면 타입과 공간의 크기의 행렬을 만들어서 해당 영역의 배경음을 만들었습니다. 바로 다음과 같이 말이죠:
또한 저희는 각 공간음에 해당 공간음 타입에 해당하는 잔향/지연도 넣었습니다.
이를 통해서 게임에 있는 모든 실내 공간에서 이 공간음을 사용하면서 공간화와 크기를 알맞게 만들 수 있었죠.
그리고 제릭(Jerrick)은 레벨에 있는 모든 환경음 볼륨을 스캔하고 환경음 이벤트가 무엇인지에 따라 단발성 환경음 이벤트의 볼륨을 지정하는 도구를 만들었습니다. 즉, 특정 공간음과 항상 함께 재생되는 다수의 이벤트가 있었죠. 예를 들어 'amb_roomtone_wood_medium'은 항상 'amb_os_small_wood_creak' 'amb_os_bathroom_misc', 'amb_os_small_lightbulb', 'amb_os_small_buzz', 'amb_os_small_pipe_pressure'라는 단발성 이벤트를 사용합니다.
저희는 이 '기본 레벨'의 단발성 사운드에 전용 Ak Ambient Sound 오브젝트를 붙여서 보완합니다. 이 오브젝트를 여러 단발성 사운드가 있는 던전에서 사용하여 더 위험한 느낌을 주는 등 특정 감정을 일으켰습니다.
그런 다음 'Listener with Automation 3D position(3D 위치 오토메이션을 사용하는 리스너)' 설정을 사용하였는지 확인하고, 스테레오 음장에서 이 사운드가 재생될 곳으로 랜덤화된 한 경로만 사용했습니다. 또한 'Hold Listener Orientation(리스너 방향 유지)'을 활성화해서 플레이어가 뱡향을 틀면 단발성 사운드가 알맞게 패닝 되도록 해주었습니다. 이렇게 해서 플레이어를 환경 안으로 더 깊숙이 이끌고 주변에서 일어나는 모든 것들이 실제로 세계 안에서 일어나는 것처럼 만들 수 있었습니다.
다음은 전체 환경음과 단발성 오디오가 작동하는 제작 블록입니다! 이 방식을 통해 저희는 레벨을 열고 '플레이어가 여기 있을 때 어떤 감정을 느끼도록 해야 할까?'라는 질문을 할 수 있었습니다. 그런 다음 한 이벤트씩 해당 분위기를 제작하기 시작할 수 있었죠. 정말 자유로웠고 재미있는 접근 방식이었습니다. 게임의 공간을 더욱 현실적으로 만들어 주는 데에 이것이 정말 큰 역할을 했다고 생각해요.
환경음을 현실적으로 만들어주기 위해 한 마지막 작업은, 문을 통해서 Exterior(실외) → Interior(실내)로 전달되는 환경음을 시뮬레이션 할 방법을 찾는 것이었습니다. 현재 저희 시스템은 외부 볼륨에서 내부 볼륨으로 전환하자마자 내부 환경음을 페이드 아웃하고 내부 공간음을 페이드 인 하기 때문에 이 시뮬레이션이 불가능했죠. 외부 환경음이 페이드 아웃된 후 실내로 아무 소리도 새어 들어오지 않았기 때문에 문이 열린 공간에서 몰입감이 깨졌습니다. 저희는 환경음의 축소된 버전 (적용 가능할 경우 대화 소리도 포함)을 재생하는 이미터를 배치해서 문제를 해결했습니다. 이 사운드가 문에 의해 완전히 차단되도록 해서 문을 닫았을 경우 외부 소리가 멀어지는 것처럼 만들었습니다.
VO & 대화 소리
아우터 월드는 RPG 게임이기 때문에 오디오 측면에서 VO Chatter 시스템이 아주 중요했습니다. 이 시스템은 다양한 대사와 다양한 성우들에 의해 녹음된 수많은 캐릭터로 인해 엄청난 양의 VO가 담겨 있습니다. 아우터 월드에는 대화 소리 VO와 연관된 이벤트에 대해 총 3만 4천 개가 넘는 음원 파일이 있습니다.
이 모든 VO를 책임질 대화 소리 시스템을 설립할 때, 대화 소리를 통해 성취하려는 목적이 무엇인지 결정하는 것이 중요했죠.
마침내 저희는 대화 소리가 '게임 설계의 의도를 표현한 것'이라는 철학에 도달했습니다. 다시 말해, 대화 소리의 주요 목적은 연관된 게임플레이 상황을 뒷받침하기 위한 것이라는 뜻이죠. 이는 대사를 쓰는 측면에서 전투 도중 쉽게 이해할 수 있도록 간소화하면서 동시에 세계 구축을 충분히 유지하여 대화 소리가 세계에 알맞게 녹아들도록 해야 함을 의미했습니다. 구현의 경우 저희는 이벤트 우선순위 시스템을 만들어서 우선순위가 높은 이벤트가 현재 재생 중인 우선순위가 낮은 이벤트를 방해할 수 있도록 (혹은 새롭게 트리거되는 것을 막을 수 있도록) 해주었습니다. 이를 통해서 더 중요한 게임플레이 사건이 일어나지 않는 한 대화 소리가 방해받지 않고 재생되도록 할 수 있었죠.
이 철학은 게임에 있는 동반자의 대화 소리 제작 과정에도 큰 역할을 했습니다. 저희는 VO 연기 측면에서 현재 게임플레이의 상황인: 'Out of Combat(전투 종료)', 'Stealth(은둔)', 'In Combat(전투 중)'을 표현하여 대화 소리를 더욱 현실적으로 만들고자 했습니다. 따라서 특정 대사는 재생될 수 있는 상황이 제약적이며 어떤 대사는 이 상황에 따라 VO의 연기가 달라지도록 했습니다. 이렇게 해서 상황에 관여 받지 않는 게임플레이 상황에 연결된 이벤트에도 동일한 대사를 상황에 맞추어 사용해서, 캐릭터들이 더욱 세계에 존재하는 것처럼 느껴지도록 만들었습니다. 유효한 이동 명령을 확인하는 동반자의 소리도 이제 반응적인 것처럼 들리게 되었죠.
세계 안을 걸어 다니면서 주변 광경을 구경하면서 Felix에게 가서 좋은 경치를 가서 구경해보라고 한다면요? 'On the move.'
경비원이랑 무서운 총을 겨눠가면서 싸우는 도중 Felix에게 뒤에 가서 숨으라고 한다면요? "ON THE MOVE!!"
경비원이랑 무서운 총을 겨눠가면서 싸우는 도중 Felix에게 뒤에 가서 숨으라고 한다면요? "ON THE MOVE!!"
저희는 게임 측면에서 플레이어의 상황 (플레이어가 처한 상태)에 맞게 조건적으로 대사를 재생하여 이 반응적인 대화를 만들어낼 수 있었습니다. 플레이어의 상황에 맞게 이러한 동반자 이벤트를 재생하니 플레이어가 현재 게임플레이 측면에서 무엇을 하고 있는지를 반영하며 심리적 상태를 다시 한번 뒷받침할 수 있었습니다. 그래서 플레이어가 은둔 중일 경우 동반자는 속삭이는 목소리로 말하며, 전투가 끝났을 경우 원래 목소리로, 전투 중일 경우 외치는 소리로 말하게 됩니다.
마지막으로 이러한 상황 간의 차이점을 극대화하기 위해서, 상황에 따라 VO를 올바른 발성 수준으로 재생하는 데에 집중했습니다. 따라서 음성을 '강도' 척도별로 구성하여 대상과의 거리를 척도로 삼아 대사가 얼마나 크게 발성되어야 하는지를 정했습니다. 이 방식은 특히 다양한 강도의 음성이 모두 일어나고 있는 전투 도중에 가장 잘 드러납니다.
Intensity 1(1 ft.) |
|
Intensity 2(2-3 ft.) |
|
Intensity 3(3-5 ft.) |
|
Intensity 3.5(7-10 ft.) |
|
Intensity 4(10-15 ft.) |
|
Intensity 4.5(15 ft.+) |
|
Intensity 5(20 ft.+) |
|
중심적으로 이 에셋의 전반적인 게인은 비슷하지만 추가로 합쳐진 발성 강도를 통해서 상황과 VO가 게임 설계의 의도를 뒷받침하도록 해줍니다. 이 모든 것들이 합쳐져서 플레이어가 게임플레이의 반복 구간을 진행하면서 대화를 통해 게임 설계가 의도한 바를 플레이어에게 지속적으로 전달할 수 있습니다.
이제 저희가 모든 VO를 구현한 방식을 살펴봅시다 (다시 말씀드리지만 대화 소리에 총 3만 4천이 넘는 VO 대사가 들어 있으며 모든 대화를 포함할 경우 5만이 넘습니다). 핵심적으로 저희 사내 개발 도구는 외부 음원을 통해 Wwise와 게임과 상호 작용했습니다.
전반적으로 각 시스템은 다음의 역할을 합니다:
|
게임 코드 |
Wwise |
|
|
게임 측면에서, 저희는 VO를 재생하고자 할 때 다음 작업을 실행하는 VO 플레이어가 있습니다 (이미지 아래에서 단계 별로 설명됨):
1. 게임에서 이벤트가 일어나면...
2. 다음 작업을 실행하는 VO Player를 사용합니다.
3. 캐릭터와 말하는 대사에 따라 인스턴스를 가져올 Sound Event 풀(여러 Sound Event의 모음)을 선택합니다.
4. 선택된 풀에서 사용 가능한 다음 Sound Event의 이름을 가져옵니다.
a. 이 Sound Event는 Wwise External Source가 있는 일반 Sound Voice를 재생합니다. 상황에 따라 감쇠 곡선이 달라져야 하기 때문에, Sound Voice와 Sound Event를 이 방법으로 나누었습니다.
5. 해당 Sound Event Name을 VO Player로 전달합니다.
6. 제작된 wem 파일 경로 (이미 단계 1과 2 사이에서 게임 코드에 의해 결정됨)로 알맞은 AkExternalSourceInfo 오브젝트, 콜백에 필요한 정보, 코덱 정보를 생성합니다.
7. 가져온 Sound Event를 게시하고 새로 생성된 AkExternalSourceInfo 오브젝트를 전달합니다.
헬멧에 따른 런타임 VO 처리
저희는 프로그래밍 팀과 함께 캐릭터가 머리에 장착 중인 장비에 따라 캐릭터에 음성 처리 효과를 동적으로 적용하는 시스템을 구현했습니다. 이 시스템은 언제든지 플레이어와 동반자에게 적용될 수 있는 수많은 갑옷 구성을 효율적으로 반영하기 위해 고안되었습니다. Unreal에서 저희는 어떤 헬멧 아트 에셋이 어떤 음성 처리와 연결되어야 하는지를 지정할 수 있었습니다. 저희는 게임플레이 태그 시스템을 사용하여 이 헬멧 (그리고 마스크) 에셋을 Wwise에서 만든 RTPC와 연결했습니다. 저희는 최종적으로 HelmetArmor, HelmetMask, HelmetScience, None이라는 총 4 개의 다른 RTPC를 사용했습니다. 캐릭터가 현재 어떤 타입의 헬멧을 착용하고 있을 경우, 이 캐릭터는 Wwise로 현재 착용 중인 헬멧과 상응하는 RTPC의 값 1을 전송합니다. 이 매개 변수 데이터가 Wwise로 전송되면 저희는 이 매개 변수를 사용하여 해당 캐릭터의 VO에 다양한 처리를 적용합니다.
Unreal 데이터와 RTPC 정의
Wwise의 Voice Actor-Mixer 계층 구조 안에는 다양한 기본 효과가 상위 Voice 믹서에 장착되어 있습니다. 이 효과는 저희가 Unreal에서 생성하고 이름을 지정하고 지정한 매개 변수에 의해 구동되며 변조됩니다. 저희는 런타임 VO 처리의 기본 역할을 할 몇 가지 Effect 공유세트(ShareSet)를 설계했습니다. 모든 처리 스타일 (Science, Mask, Helmet)은 동일한 기본 효과 (Parametric EQ, Flanger, Guitar Distortion)를 공유하지만 RTPC를 사용하여 각 Effect Shareset를 부가적/가감적으로 변조와 재조합을 해서 다양한 느낌의 효과를 만들어냅니다. 저희는 다음 세 가지 스타일의 음성 처리를 지원합니다:
HelmetArmor: 중~대형 플라스틱/철 헬멧 (강력한 파라메트릭 EQ 머플링 효과, 중간 세기의 기타 디스토션, 약간의 플랜저)
HelmetArmor 경비원 VO 처리
HelmetMask: 중~대형 플라스틱/철 마스크 (중간 세기의 파라메트릭 EQ 머플링 효과, 약간의 기타 디스토션)
HelmetMask 아군의 VO 처리
-HelmetScience: 소~중형 천/플라스틱 마스크 (중간 세기의 파라메트릭 EQ 머플링 효과)
HelmetScience 행상인 VO 처리
None: 처리되지 않음
Voice Actor-Mixer 효과
Actor-Mixer 매개 변수
각 RTPC는 캐릭터가 현재 장착한 헬멧 스타일에 따라 1 (활성화) 혹은 0 (비활성화)의 불리언(boolean) 값을 Unreal에서 Wwise로 전송합니다. 그런 다음 각 Effect Shareset에서 RTPC를 사용하여 매개 변수가 변조되어 효과음을 다양한 방법으로 변경합니다. 이 작업은 다양한 효과에서 조합적으로 진행되어 다양한 합성 처리 효과를 생성합니다. 예를 들어 HelmetArmor가 활성화되었을 경우 저희는 기타 디스토션과 플랜저 효과를 더욱 구동하며 고유의 Parametric EQ 곡선에만 의존합니다. 연속적인 각 처리 스타일 (Science > Mask > Helmet)은 적용되는 효과 음색의 양과 강도 측면에서 점진적으로 더 많이 처리됩니다. 또한 RTPC가 믹서 수준에서 사용되어 Effect를 우회하며 ( None 처리 Tag가 활성화되었을 경우) 볼륨 자동화를 적용하여 필터 효과를 적용할 때 약간의 전체적인 게인 손실을 보상합니다.
Effects Shareset와 매개 변수
이렇게 동적 런타임 VO 처리를 적용한 결과적 시스템은 유연할 뿐만 아니라 반복 작업이 수월했으며 궁극적으로 게임의 크기와 범위에 아주 좋은 역할을 했습니다. 추후 프로젝트에서 이 아이디어와 구현을 더욱 확장할 수 있는 부분이 정말 많습니다. 다음에는 McDSP와 같은 Wwise의 서드파티 플러그인을 사용하여 더욱 광범위한 VO 처리 스타일을 제작해봤으면 합니다.
공간화
아우터 월드의 오디오 풍경에서 전반적으로 가장 큰 변화를 준 것은 Spatialization(공간화)였습니다. 이를 통해 지리적으로 더욱 정확한 기능으로 훌륭한 청각적 해상도를 제공하여 전투와 은둔 도중 몰입감을 크게 높이고 정확한 전술 정보를 제공할 수 있었습니다.
참고로 프로젝트의 제한 사항으로 인해 Wwise CORE 기능의 구현을 조사 (혹은 최적화) 해보지 못했습니다. 대신 Wwise Spatial Audio가 제공하는 Room과 Portal 기능을 최대한 게임에서 전반적으로 심도 있게 사용하는 데에 전념했죠.
렇게 하기 위해서 먼저 게임 코드에 저희가 필요한 모든 구성 요소가 들어 있는 전체적인 클래스를 만들어야 했습니다. 이를 위해서 Unreal의 TriggerVolume에서 이어받은 코드 클래스를 만들어서 그 위에 AkLateReverbComponent와 AkRoomComponent를 추가하고 하우스 정보에 환경음/상태에 사용할 다양한 TArrays를 추가했습니다. 그리고 컨스트럭터에 일부 기본 충돌 속성을 구성하는 브러쉬 컴포넌트가 있는 (하지만 또한 Unreal에서 복잡한 볼륨 모양을 만들 수 있는) 논리를 추가했습니다. 이 클래스는 이제 공간적 기능과 환경음 (잔향 포함)을 제어하는 포괄적인 볼륨입니다. 저희는 이를AmbientSpatialVolume이라고 부릅니다.
그런 다음 게임에 Portal을 추가했습니다 (다음 단계에서 Room을 그리는 데에 도움을 얻기 위해 Portal을 먼저 추가했습니다).
그리고 저희 Room인 AmbientSpatialVolume을 영역에 추가해서 게임의 모든 맵에서 고도로 정확한 공간 풍경을 만들어냈습니다.
그뿐만 아니라, 이러한 볼륨을 어떻게 어디에서 그릴지를 완전히 제어할 수 있었기 때문에, 게임에서 Room과 Portal을 구현할 수 있는 창의적인 방법을 생각해봤습니다.
그 중 한 예시로, 저희는 복도와 같이 급격하게 꺾어지는 모서리가 있는 선형적 영역을 여러 개의 공간으로 분리하여 모서리를 돌기 전 복도의 한쪽 끝에 포털을 배치했습니다. 이렇게 하면 포털에서부터 소리가 나와서 모서리에 '숨을' 수 있게 되어, 플레이어가 모서리 뒤편의 어디에서 소리가 방사되어 나오는가를 더욱 정확하게 결정할 수 있게 됩니다. 그리고 플레이어가 숨어 다닐 때 일반 은둔 게임플레이 반복에 더불어 영역의 소리풍경 정보에 더 자세히 집중하게 해주죠.
Room과 Portal을 비일반적인 방법으로 사용한 또 다른 예시는 수직적인 실내 공간을 여러 바닥으로 나누어서 각 바닥마다 새로운 공간을 만들고 바닥 간의 열린 곳에 포털을 추가하는 것이었습니다. 이 방법은 사운드가 흘러나온 바닥으로부터 '물리적으로' 머물게 되어 사운드가 플레이어의 위에 있다는 것과 어디로 가면 사운드가 흘러나온 곳으로 시선을 맞출 수 있는지를 알려줍니다.
이 전체 과정 후에 저희는 게임에서 아주 깊고 견고한 소리풍경을 제작할 수 있었지만, 가혹한 교훈 없이 이루어 진 것은 아닙니다.
오토메이션:
AmbientSpatialVolume과 Portal을 전체 게임에서 추가하는 파이프라인은 수동적으로 이루어졌습니다. 이 과정은 시간이 아주 많이 걸렸을 뿐만 아니라 사람에 의해 오류가 발생할 확률이 높았죠. 이러한 과정의 모든 부분을 오토메이션 하는 데에 시간을 보낼 것을 강력히 추천합니다.
저희가 개발한 오토메이션 과정 중 한 예시는 문에 포털을 연결하여 작동 방식을 함께 연결하는 것이었습니다. 모든 문에는 열림/닫힘 작동 방식이 포털을 열고 닫을 수 있게 해주는 블루프린트 논리가 있었습니다. 하지만 이 논리는 저희가 처음에 손으로 연결되어야 했던 포털을 참조했죠. 이렇게 할 경우 포털 구현 시간이 훨씬 길어진다는 것을 알고 나서 저희는 문 블루프린트의 구조 스크립트에 일부 자동화를 추가하여 문으로부터 특정 범위에 있는 포털을 찾고 가장 가까운 포털을 문에 연결하도록 했습니다. 따라서 영역에 포털 추가를 마친 후에, 레벨에 있는 해당 블루프린트와 모든 문을 다시 컴파일하면 스크립트가 실행되어 가장 가까운 포털을 찾아 적용 가능할 경우 연결을 만들어낼 수 있었죠.
이 오토메이션은 변경 사항으로 인해 대량의 문과 포털이 이동할 경우 작업을 쉽게 만들어 주었습니다. 문이 옮겨질 경우 이동 과정 동안 구조 스크립트가 이미 실행되죠. 그리고 포털이 이동할 경우 (혹은 모든 것이 올바르게 연결되었는지 저희가 다시 확인하려는 경우) 이 블루프린트를 다시 컴파일링하기만 하면 되었습니다. 엔진 안에서 작업하는 모든 사운드 디자이너분들에게 이런 수동적 과정을 찾아서 똑똑한 자동화 기술로 구현 속도를 높이실 것을 적극 권장해드립니다.
최적화:
저희가 배운 또 다른 큰 교훈은 최적화입니다. 레벨의 정밀도에 맞게 공간적인 풍경을 제작하는 데에는 CPU가 상당히 소비되었습니다. 그래서 콘솔에서 Wwise의 Audio Thread CPU를 디버깅할 때 항상 100%가 넘어가더군요. 저희는 Spatialization을 지원할 수 있을 만큼 충분히 CPU를 확보하기 위해 게임의 모든 오디오 시스템을 계속해서 최적화 작업을 하는 데에 많은 시간을 쏟아부었습니다. 저희는 다음 내용을 최적화했습니다:
- 등록된 오브젝트 줄이기: Wwise 프로파일러에 따르면 최적화 이전에는 밀집한 지역에서 등록된 오브젝트의 수가 1000 개가 넘었습니다. 불행하게도 저희는 프로젝트의 제약으로 인해 Wwise로의 오브젝트 등록을 안전하게 처리하는 시스템을 제작할 기회를 가지지 못했습니다. 이런 공식적인 관리법 없이 저희는 게임에서 AkComponents를 제거 (따라서 등록된 오브젝트도 제거) 하고 등록된 오브젝트를 일시적으로 생성하는 PostEventAtLocation을 통해 사운드를 구현할 수 있는 곳을 찾았습니다. 이 방법은 대부분의 단발성 사운드에서 작동했지만, PostEventAtLocation은 반복 재생을 중단하려는 경우와 같이 후에 작동을 위해 오브젝트를 캐시로 보내지 못하기 때문에 반복 재생되는 사운드에서 사용하기에는 버그가 많았습니다. 전반적으로 저희는 문, 컨테이너, 단발성 VFX와 같은 모듈 게임 오브젝트에 이 방법을 상당히 적용하여 1000 개가 넘던 등록된 오브젝트의 수를 ~500 개로 줄일 수 있었습니다.
- 가상 보이스 제어: 저희는 처음에 가상 보이스로 보내는 보이스의 개수를 상관하지 않고 가상 보이스를 사용했습니다. 이는 결국 가상 보이스의 과도한 개수로 인해 가상 보이스 설정에 상관없이 CPU를 완전히 장악해버렸습니다. 가장 큰 문제는 저희가 환경에 생동감을 주기 위해 많이 사용해온 AkAmbientSound였습니다. 밀도가 높은 게임 영역에서는 AkAmbientSound의 개수가 300 개가 넘어서 가상 보이스의 수가 지나치게 많아졌죠. 이를 위해 저희는 프로그래머와 함께 '추려내기' 시스템을 만들어서 플레이어가 특정 범위 (해당 이벤트의 오디오 감쇠 반경 보다 약간 김) 안팎으로 오고 나갈 때 AkAmbientSound에서의 이벤트 재생을 관리했습니다. 이 이벤트 중단 관리 시스템은 여러 이벤트를 완전히 제거하여 가상 보이스가 차지하던 리소스를 다시 자유롭게 만들어줘서 AkAmbientSound에서의 가상 보이스 개수를 ~30개로 줄어주었습니다.
- 활성화된 보이스 제한: 마지막으로 저희는 최적화 이전에 활성화된 보이스 제한이 없었습니다. 그래서 이 개수를 제한하는 것은 CPU 사용을 자유롭게 해주는 주요 최적화 작업 중 하나였습니다. 하지만 활성화된 보이스 제한은 단지 Advanced Settings 탭에서 한 숫자를 설정하는 것이 아닙니다. 모든 Actor-Mixer가 전역적 제한을 준수할 수 있도록 Wwise Actor-Mixer Hierarchy를 구성해야 하죠. 그렇기 때문에 저희는 프로젝트를 재구성하여 사운드 인스턴스 제한이 있는 전반적인 Project 액터 믹서를 만든 후 모든 Actor-Mixer와 Wwise Work Unit을 이 Project Actor-Mixer 안으로 넣어야 했습니다. 그리고 필요한 대로 다른 Actor-Mixer와 특정 사운드 오브젝트에 필요한 경우 제한을 추가했습니다. 그뿐만 아니라 저희는 Playback Priority를 최대한 많이 사용하여 원래 있던 제한을 더욱 강화하여 플레이어로부터의 거리에 따라 특정 사운드를 우선시했습니다. 저희는 전반적으로 활성화된 보이스의 개수를 50으로 제한했습니다.
마지막으로 저희는 Spatialization(공간화)가 소리풍경에 깊이감을 훨씬 더해줘서 몰입감을 높이고 플레이어가 게임의 여러 영역을 여행하면서 게임플레이에 소리적인 요소를 더해준다는 것을 알아냈습니다. 아주 상세한 공간적 소리풍경을 개발하기 위해서 저희는 이러한 구현을 수동적으로 조정하는 데에 필요한 작업의 양에 대해 많은 것을 배웠으며 가능한 곳에 오토메이션이 필요하다는 것과 줄여야 하는 것 또한 깨달았으며 Spatialization 기능을 지원하기 위한 최적화 작업의 필요성을 느꼈습니다. 전반적으로 Spatialization은 오디오 팀 전체의 신호 표지와 같은 역할을 했습니다. 저희가 모두 함께 이 기능을 구현하고 최적화하기 위해 노력하면서 아우터 월드의 전체 소리풍경을 더욱 생동적으로 만들어주는 시스템을 구축해낼 수 있었죠.
결론
저희는 아우터 월드에서 저희가 해낸 작업이 아주 자랑스럽습니다. 작업하면서 정말 많은 교훈을 배웠고 실수가 정말 많았지만 예전과 달리 Obsidian에서 Wwise를 사용할 수 있었기 때문에 기술을 발전시키는 데에 도움을 받을 수 있었습니다. 특히 플레이어가 수많은 다른 결정을 내릴 수 있는 게임에서 수많은 세계를 제작하는 것은 쉬운 일이 아니었지만 저희 플레이어가 탐험할 수 있는 일관된 소리풍경을 만들어 낼 수 있었던 것 같습니다.
블로그 제 1부를 통해 여러분이 좋은 정보와 도움을 얻어 가시길 바라며, 적어도 게임의 여러 다른 부분에서 저희 작업 과정에 대한 통찰력을 얻을 수 있는 기회가 되셨기를 바랍니다. 시간을 내어 읽어주신 여러분들께 감사드리며 핼시언과 아우터 월드의 제 2부를 기대해 주세요!
팀 소개
저희 오디오 팀은 핼시언에 생명을 불어넣어 주신 사람들과 팀에게 감사하다는 말씀을 전해드리고 싶습니다. 오디오는 단지 한 개의 퍼즐 조각일 뿐이며 여러분의 지원과 재능 없이는 가능할 수 없었을 거예요.
- 아우터 월드의 QA, 나레이티브, 프로그래밍, 프로덕션, 게임 디자인, VFX과 애니메이션 팀
- Noiseworks(노이즈웍스)
댓글