게임에서의 음향은 다른 미디어와는 조금 다른 방향성을 가진다.
영화 포스트 프로덕션에서 사운드 디자이너는 어떤 특정 장면에 어떤 소리가 필요한지 충분히 이해하고 적절한 소리를 디자인해 넣을 수 있다. 가령 두 남자가 칼을 다투는 장면이라고 가정하면 칼 부딪히는 소리, 칼에 찔리는 살점과 피가 난자하는 소리 등을 디자인해 믹싱을 하면 매번 영화를 볼 때마다 만족할 만한 결과를 얻을 것이다.
그런데 게임에서는 전혀 다른 상황이 전개된다.게임 사운드에서는 플레이어의 시점과 행동에 따라 다른 청각 경험을 필요로 하기 때문이다.플레이어가 공격을 성공시켰을 때 상대가 어떤 재질의 갑옷을 입고 있느냐에 따라 다른 공격음이 나올 것이고, 어떤 방향을 바라보고 있느냐에 따라 다른 사운드가 필요할 것이며, 주변 환경에 따라 다른 공간음이 필요할 것이다.이처럼 사운드 디자이너가 게임의 전반적인 사운드를 디자인할 때 너무 많은 변수가 존재하기 때문에 이를 하나하나 고려하고 작업한다는 것은 불가능에 가깝다.따라서, 게임 사운드 디자이너가 「플레이어가 특정의 상황에서는, 어떠한 사운드를 하는가?」라고 하는 질문에 맞닥뜨렸을 때, DAW상의 작업만으로는, 그 무한한 질문에 대한 해결책을 제시할 수 없다.
이때 게임엔진이 사운드 디자이너에게 또 다른 길을 제시한다.
유니티 엔진
게임은 게임 엔진으로 불리는 소프트웨어를 활용해 개발된다. 게임엔진은 개발자에게 모든 종류의 게임에셋(assets)을 분류해 개발할 수 있는 도구를 제공한다. 물리 효과, 캐릭터의 움직임과 애니메이션, 그래픽 렌더링, VFX와 사운드까지다.
Sound Events
플레이어가 특정 상황(Event)일 때는 어떤 사운드가 나오나?사운드 디자이너가 게임의 플레이어가 어떻게 게임 환경과 상호작용할지를 정확히 예측하는 것은 불가능에 가깝다.따라서 사운드 디자이너는 플레이어의 다양한 행동에 따른 상호작용 사운드를 디자인해 놓는다. 그러면 게임 엔진은 어떤 상황에서 Sound Event를 실행시킬지를 결정한다. 그 판단의 근거는 게임 데이터에 의해서 정해진다.
게임 플레이 상황 (대기 중인가?) 전투 상황인가?) 전투 변수 (적의 숫자 등) 플레이어 데이터 (플레이어 위치 값, 체력 상황) AI 데이터 (인근 적의 상태) 세션 데이터 (저장 상태, 게임 진행도 등)
Game object and Compon ent Structures
사운드 디자이너는 이러한 데이터에 따라 다양한 사운드를 디자인하고 적용할 수 있다.유니티 엔진에서는 C# 언어를 통해 Objects 와 Component 에 스크립트를 적용 시킨다.
때로는 게임 내의 어떤 오브젝트가 특정 사운드만 낼 수도 있고 상황에 따른 다양한 상호작용에 대응하는 사운드를 낼 수도 있다.게임 오브젝트는 사운드를 발생시키는 Emitter와 사운드를 듣는 Listener로 구분된다.
Listener는 게임 Emitter가 발생시킨 사운드를 ‘듣기’ 역할을 수행한다. 보통 Listener는 게임월드 내에 하나만 존재하지만 게임 장르에 따라 게임의 카메라 혹은 플레이어 캐릭터, 드물게 특정 오브젝트가 되기도 한다.’듣는’ Listener와 ‘소리를 내는’ Emitter는 게임 내 상황에 따라 끊임없이 연산을 거친다.
그러나, 사운드 디자이너의 관점에서 보면, 모든 연산이 게임 엔진 내에서 행해지지만, 프로젝트가 커짐에 따라, 어셋 관리나 데이터 연산이 매우 복잡하게 되는 것이 상례이다.게임엔진도 오디오 개발자 입장에서는 반드시 편리한 것만은 아니다.
편리성을 높여 복잡한 어셋 관리를 서포트하는 프로그램이 있다.Middleware로 불리는 프로그램이다.
Wwise
위의 프로그램은 Audio Kinetic이 개발한 미들웨어인 WWise이다.이 미들웨어들은 사운드 디자이너들이 복잡한 물건을 쉽게 제어할 수 있다.
WWise는 게임 엔진과 오디오 사이에서 게임상의 사운드를 컨트롤 해, 게임 엔진에 적용시킨다.미들웨어는 게임엔진의 데이터를 이용해 사운드에셋을 변형한 뒤 그 결과물을 다시 게임엔진에 보낸다.이러한 방식에 의해 미들웨어는 Emitter와 Listener의 상호작용을 관리하는 데 최적의 편리성을 제공하는 것이다.
공부중