이 글은 고예산 게임을 제작할 때 제가 생각한 Wwise 사용의 장점을 간략하게 설명하고 있습니다.
먼저 프로젝트에서 오디오 미들웨어 사용의 장점을 요약해볼까요.
- 프로젝트 오디오의 품질이 더욱 높아집니다.
- 리소스를 더욱 효과적으로 사용하게 됩니다.
- 프로그래밍 시간이 줄어듭니다.
게임을 플레이할 때 오디오는 플레이어 경험의 절반을 차지합니다. 게임에서 오디오는 단지 사운드를 트리거하는 것만이 아닙니다. 안타깝게도 오디오에 대한 영역이 제한되어 있기 때문에 프로젝트가 끝나갈 때까지 아무도 오디오 구현 작업을 하고 싶지 않게 되어 버리죠. 오디오 프로그래밍은 그리 녹록한 작업이 아닌 데다가, 도와줄 리소스가 제공되지 않을 경우 문제를 일으키기 쉽습니다. Wwise는 위에서 제공한 세 가지 주요 장점을 최단 시간 안에 이끌어낼 수 있기 때문에 개발에 아주 중요한 도구입니다. 즉, Wwise는 오디오 파이프라인 구현을 향상시키고 전반적인 프로젝트의 품질을 높여줍니다.
프로그래밍 시간 절약
Wwise에는 자체적인 인터페이스가 있기 때문에 사운드 디자이너가 게임 엔진과 완전히 독립적으로 에셋을 구성하고 장치를 제작할 수 있습니다. 이 점은 사운드 디자이너가 프로그래밍 없이 아주 빠르게 복잡한 시스템을 구축할 수 있게 힘을 실어줍니다. 여기서 말하는 시간 절약은 스크립트를 맞춤 제작하는 시간과 이미 중요한 게임플레이에 집중하고 있는 프로그래머와 지속적으로 소통해야 하는 많은 시간을 절약할 수 있음을 말합니다. 이런 시간을 절약함으로써 보통은 프로그래머를 통해야만 하는 작업이 크게 줄어들며 사운드 디자이너가 이 모든 것을 직접 처리할 수 있게 됩니다.
1) Wwise의 기본 구현은 다음과 같습니다.
코드에서 가장 많이 사용하는 함수는 PostEvent입니다. 이 함수는 사운드 엔진에서 알맞은 Event와 Wwise에서 Event가 실행하는 다양한 작업을 호출합니다.
2) 두 번째로 가장 많이 사용하는 함수는 SetRTPCValue입니다.
시간을 절약해주는 또 다른 기능인 RTPC는 동적 오디오와 관련된 복잡한 시스템의 기초 역할을 합니다.
다음 예시는 Car.Speed를 연결하고 있는 모습입니다. Car.Speed는 코드 안에 있는 실제 값 (0~30 범위)이며 Wwise에서 제가 만든 RTPC인 SpeedBis와 연결됩니다.
그렇기 때문에 Car.Speed의 값이 변경될 때마다 소프트웨어에서 제 값이 실시간으로 업데이트됩니다. 그 결과 게임에서 자동차의 속도가 높아지면 값이 증가하면서 바람 소리 에셋이 점점 더 커집니다. 그런 다음 저는 게임을 플레이하면서 실시간으로 레벨을 수정합니다. 이 과정은 다해봤자 5분에서 10분 정도 밖에 안 걸려요!
3) 프로그래머와 소통해야 하는 유일한 경우는 제 장치에 어떤 값을 사용해야 하는지 묻거나 제 Event를 호출하기 위해 PostEvent 함수를 어디 넣어야 하는지 물어야 할 경우입니다. 이 부분은 단지 몇 분 밖에 걸리지 않을 뿐더러 스크립트도 필요가 없어요. 제가 완전히 고급 수준의 작업을 할 경우 프로그래머의 도움이 더 필요할 수도 있겠지만 그렇다고 하더라도 20~30분 밖에 걸리지 않을 겁니다.
간단한 예: 자동차가 환경과 충돌하는 경우 (맵에 4가지 텍스처가 있음). 충돌이 일어날 경우 (On Collision Enter) Event가 호출됩니다. 이 이벤트는 왼쪽에 있는 Switch Container를 검토하여 태그에 따라 재생할 알맞은 에셋을 선택합니다. 무리 없이 잘 작동하긴 하지만 Event가 스크립트가 연결된 Game Object에서 게시된다는 문제가 있습니다. 이 경우 자동차에서 제공하는 오디오가 공간화되지 않습니다. 저는 이 사운드가 3D이길 원하기 때문에 Event가 반드시 충돌 지점에서 트리거되어야 해요.
그래서 저는 프로그래머의 도움으로 커스텀 메소드을 제작했습니다. 충돌 지점에 Game Object를 만들고 사운드를 재생할 충돌 지점으로 objectHit를 설정한다는 태그 정보를 제가 이미 갖고 있던 메소드에 전송했습니다. 이런 방식을 통해 Wwise에서 설정한 3D 위치 지정*을 사용할 수 있었습니다.
다른 작업보다 시간이 더 걸리긴 했지만 20분이 넘지 않았습니다. 코드의 도움이 필요했지만 기능을 제작하는 것이 아니라 기존의 기능을 더 개선하는 작업이었기 때문에 재미있게 작업할 수 있었죠.
4) Wwise에서 두 번의 클릭만으로 설정할 수 있는 기본 기능을 스크립트로 작성하는 데는 많은 시간이 걸렸습니다. 예를 들어 랜덤화에 관한 요소, 부동 혹은 정수 값 연결하기, 오디오 에셋 선택에 관한 요소는 많은 시간을 필요로 했어요. 그럼에도 불구하고 커스텀 스크립트는 가끔 실패하거나 성능에 영향을 주기도 합니다. 누구든 Wwise 같은 사운드 엔진이 이미 실행할 수 있는 시스템을 개발하는 데 프로그래머들의 시간을 쏟기보단 게임의 주요 기능에 더 집중할 수 있기를 원하겠죠.
리소스를 더욱 효율적으로 사용하기
Wwise는 Unity 세션이나 심지어 빌드에 연결되었을 때 심도 있는 프로파일링을 제공합니다. 라이브 믹싱과 편집도 물론 제공해요. Unity는 라이브 믹싱을 허용하지만 런타임 때 값이나 오디오에 관한 매개 변수를 변경할 수는 없습니다. 프로파일러는 고급 데이터를 보여주어 CPU와 메모리 사용률을 최적화할 수 있게 해줍니다. 이렇게 Wwise는 코드 작성 없이 화려한 장치와 더 나은 음질의 시스템을 제공할 뿐만 아니라 최적화를 용이하게 해줍니다.
1) 메모리를 절약하려면 오디오 압축이 꼭 필요합니다. 각 대상 플랫폼에 가장 알맞은 설정을 선택할 수 있습니다.
프로젝트를 출시할 각 플랫폼에 서로 다른 압축을 설정할 수 있습니다. 뿐만 아니라 특정 플랫폼에서 필요하지 않은 에셋을 제외시킬 수도 있습니다.
2)SoundBank는 정말 유용합니다. 모든 작업물을 데이터 그룹으로 구성할 수 있다는 점은 오디오를 더욱 현명하게 배포할 수 있게 해줍니다.
이 말은 필요한 에셋만 특정 시점이나 맵 안에서 로드할 수 있음을 말합니다. 이로써 높은 수준의 제어를 통해 메모리 사용량을 완벽하게 최적화해 성능을 더욱 높일 수 있습니다. 뿐만 아니라 이미 내장된 기능인 언어 현지화도 아주 유용한 기능입니다. Unity나 Unreal은 다른 언어로 전환하거나 알맞은 현지화를 위해 대사나 음성을 교체하는 기능을 제공하지 않습니다.
3) 재생 제한 기능은 성능에 있어 필수적인 설정입니다. 이 설정은 자칫 잘못된 스크립트가 일으킬 수 있는 버그나 문제를 방지해줍니다.
스크립트가 특정한 이유로 Event를 수천 번이나 트리거하는 것에 대해 불평하지 않아도 됩니다. 대부분의 경우 파일/컨테이너의 재생 인스턴스의 수를 제한해서 직접 문제를 해결할 수 있습니다. 프로그래머의 시간을 절약해주기 때문에 곧 프로젝트 리소스가 절약는 셈이죠. 이 기능은 '꼭 필요하며' 만약 없었다면 정말 골치 아팠을 거예요.
사운드 인스턴스의 제한 개수에 도달하면 오디오를 가상 보이스로 전송할 수 있습니다. 이 경우 파일이 다시 필요하기 전까지 엔진이 오디오를 더 이상 처리하지 않고 볼륨 계산만 실행하기 때문에 리소스가 절약됩니다. 이 기능은 또한 프로젝트 설정에서 정한 볼륨 한계점이 있는 에셋에도 사용할 수 있습니다 (예: 리스너로부터 너무 멀리 있는 3D 오브젝트나 자동차 RPM 같이 지속적으로 재생되는 배경 오디오). 이 경우 파일이 들리진 않지만 계속해서 처리되면 하드웨어의 활성화된 보이스를 불필요하게 차지할 겁니다. 이렇게 '들리지 않는' 오디오를 가상 보이스로 전송합니다.
이런 기능을 변경하고 조절하면서 Wwise의 성능 설정을 최대한으로 사용하면 메모리와 처리량을 효율적으로 절약할 수 있습니다.
사운드 엔진 없이 게임 엔진을 사용할 경우 저희는 스크립팅에 의존해야 합니다. 그리고 오디오가 잘못 실행될 경우 게임 성능에 아주 치명적이라는 점도 우리 모두 알고 있죠.
오디오 품질이 더 높아집니다
디지털 오디오 편집 프로그램(Digital Audio Workstation, DAW)에서 최고의 사운드 라이브러리와 녹음을 활용하면 가장 멋진 오디오 에셋을 제작할 수 있습니다. 하지만 구현을 잘못할 경우 아무 소용이 없을 거예요. 좋은 도구를 사용하면 프로젝트의 품질이 자연스럽게 향상됩니다. 여러분의 작업물을 잘 제어하면 성능에도 그대로 반영이 되는 거죠.
프로그래머는 우리의 모든 요청을 들어주고 오디오 요구 사항을 충족시켜 줄 시간이 없습니다. 여러분이 사운드 디자이너라면 작은 것이라도 프로그래머에게 항상 부탁해야 하고 큰 그림에만 집중을 하도록 강요받아 주의가 필요한 상세한 것들을 무시해야 할 수도 있습니다. 예를 들어 Unity에서는 각 에셋의 볼륨을 조절할 수가 없습니다. 이 점은 한 음원을 공유하는 오디오 파일 어레이를 사용하는 커스텀 스크립트가 있을 경우 문제가 됩니다. 섬세함이 정말 중요하듯이, 좋은 작업을 위해서는 게임에 들어갈 모든 것을 주의 깊게 살펴봐야 합니다. 이러한 설정을 효율적으로 조절하지 않을 경우 믹스에 타격을 줄 수 있어요. 이 부분은 피치, 필터나 다른 효과의 경우에도 마찬가지인데, Unity에서는 이러한 효과를 믹서나 음원에만 적용할 수 있습니다. 음원을 최소한으로 해 파일을 개별적으로 제어하는 게 좋다는 것을 모르는 사람은 없을 겁니다.
저는 이 글이 최대한 다양한 위치에 계신 모든 분들께 관련되도록 상호적인 장점을 주로 언급했습니다. 물론 미들웨어가 사운드 디자이너에게 수많은 편리성을 제공하는 건 사실이지만, 반드시 Wwise를 사용하거나 많은 시간과 노력을 들어야지만 얻을 수 있는 것들도 있습니다.
대부분의 경우 작업 자체가 빠르고 쉬워야 결과물도 더 훌륭하게 나온다는 사실을 잊지 마세요!
더 많은 자료를 확인하세요!
댓글