설계 계기
저는 2015년에 오디오 게임 엔지니어로서 처음 일을 하게 되면서 그 당시 저의 아트 디렉터를 통해 Wwise를 접하게 되었습니다. 그전에 저는 게임 음악을 작곡하는 직업을 갖는 것이 제 목표였습니다. 저는 한동안 상호작용 음악, 음악 생성과 알고리즘 작곡에 관심이 있었습니다. 하지만 제가 어릴 적부터 좋아해온 게임에 이런 것들이 이미 존재한다고는 상상도 하지 못했죠.
게임에서의 상호작용 음악 설계에 대한 잠재적인 방법을 더 알아보는 동안 저는 Google(구글)과 Youtube(유튜브)를 통해 혼자서 이것 저것 배워보기 시작했습니다. 케제로(Kejero)가 운영하는 'Music By Kejero(케제로의 음악)'이라는 유튜브 채널은 당시 제게 큰 영감을 주었습니다. 초반에 저에게 많은 힘이 되었어요. 이 동영상 시리즈는 수직적 기법, 수평적 기법, 스팅어, 전환 효과 세그먼트, 하이브리드 기법과 같은 다양한 설계 방법을 체계적으로 설명해 주었습니다. 이러한 기법을 구현하는 법에 대한 케제로의 설명은 저로 하여금 설계 방법과 음악 구현 간의 관계에 대해 생각하게 해주었습니다. 다음 해, 저는 게임 상호작용 음악에 대해 유튜브에서 찾을 수 있는 모든 동영상을 보았습니다. 그리고 Audiokinetic 블로그, DesigningMusicNow, Melodrive 블로그 등 다양한 곳에서 해당 주제에 관한 대부분의 글을 읽었습니다. 이를 통해 저는 버저/칩튠에서부터 적응형 오케스트라, 하드웨어 FM 신시사이저, 알고리즘 퍼커션 (지능형 음악 시스템)까지 게임 음악의 개발 역사를 되돌아볼 수 있게 되었습니다. 바로 이때 저는 1991년부터 하이브리드 기법과 절차적 음향을 구현해온 Lucas Arts(루카스 아츠)에서 개발한 iMuse라는 천재적인 엔진에 대해 알게 되었습니다. 이 엔진에는 음악 설계에서 오디오 기반과 MIDI 기술을 조합할 수 있는 대담하며 기발한 방법이 있었습니다 (예: Get Even).
학습 자료
어떤 것을 배운다는 것은 저에게 참 기쁜 일입니다. 하지만 배운 지식을 실제로 적용하려고 할 때 다음과 같은 내용을 깨닫게 되었습니다.
- 게임 상호작용 음악을 다루는 학습 자료는 주로 게임 엔진에 의해 구동되는 음악 설계를 집중적으로 다루고 있었습니다. 오디오 엔진이 게임 엔진에 의해 구동되지 않는 상황에 대해서는 거의 언급이 없었죠.
- '하이브리드'라는 용어는 게임 오디오 설계에서 이에 관한 다양한 기법이 많았기 때문에 흔히 사용됩니다. 하지만 이 용어는 케제로(Kejero)와 올리비에 드리비에(Olivier Deriviere)에게 아주 다른 의미로 사용될 수 있습니다.
- 동일한 처리 방법이 다른 이름으로 불리고 있습니다. 예를 들어 '수직적 기법'은 '수직적 리믹싱'이나 '레이어링'이라고 불리기도 합니다. 심지어 몇몇 사람들은 '멀티 트랙'이라고 부르기도 하죠.
- 믹싱 기술을 사용한 상호작용 음악 제작에 대한 관심이 충분하지 않습니다. 이 방법은 올리비에 드리비에가 '하이브리드' (오디오 + MIDI)라고 말하는 것의 요점입니다. 이 방법을 기반으로 더욱 복잡하게 음악을 설계할 수 있죠.
(하이브리드 상호작용 음악에 관해 더 읽어보시려면 올리비에 드리비에가 쓴 이 두 개의 글을 읽어보세요 - 제 1부, 제 2부 )
저의 해결 방법
마이클 스위트(Michael Sweet)는 '...이 부분은 수많은 게임이 여러 가지 적응형 음악 기법을 동시에 사용한다는 점을 감안하지 않는다. 하지만 우리가 작곡가로서 더 나은 게임 음악을 제작하기 위해 각 기법의 사용에 대한 일반적인 가이드라인을 정리해볼 필요가 있다'라고 말한 적이 있습니다.
예술적 창조에 대한 잠재적인 접근 방식은 그야말로 무한합니다. 하지만 우리가 일상 작업에서 단축키나 프로젝트 템플릿을 사용하는 것처럼, 설계 방법을 요약해봄으로써 혼란을 어느 정도 방지하고 작업 과정을 최적화할 수 있습니다. 이러한 요약 작업은 시행착오를 줄이고 게임에 가장 적합하며 믿을 만한 음악 설계 해결책을 찾는 데에 아주 중요합니다. 이를 통해 복잡하고 정교한 구현 작업을 하는 데에 시간을 더욱 들일 수 있습니다. 이러한 이유로 저는 처리 방법을 분류할 수 있는 여러 표준을 만들어보았습니다. 저의 음악 설계 연습을 도와주기 위해 만든 것이지만 여러분에게도 도움이 되었으면 합니다.
사용자 구동 & 게임 구동
먼저 Wwise의 위치 지정과 보조 전송 개념을 기반으로, 게임 엔진이 음악 구현에 의해 영향을 받을 것인지의 여부에 따라 사용자 구동과 게임 구동이라는 두 가지 유형으로 처리 방법을 분류해보았습니다. 이렇게 하면 게임 엔진으로부터 독립적인 동적 음악 시스템도 충분한 관심을 줄 수 있습니다. 다시 말해, 좀 더 자세히 살펴보고 잘 개발될 수 있죠.
고정적 & 동적
그런 다음 구현 결과가 예상한대로 실행될지의 여부에 따라, 설계 기법을 고정적 방법과 동적 방법으로 구분했습니다. 이 방법은 선형적/비선형적 음악 설계를 더 잘 구분할 수 있게 해줍니다. 이를 통해 우리가 알맞은 처리 방법을 선택하는 데에 도움을 줍니다.
참고: 대부분의 경우 게임에서 플레이어의 동작을 예측하는 것이 불가능합니다. 그렇기 때문에 게임 구동 방법을 사용하여 설계된 모든 게임 음악은 '동적'이라고 할 수 있습니다. 하지만 실시간 컷씬을 동시에 사용하여 서로 다른 뮤직 세그먼트(Music Segment)를 구동하여 선형적인 방법으로 재생할 수 있습니다. 그렇기 때문에 음악이 오디오 파일로 렌더링되지 않더라도 게임 구동 방법 자체는 '고정적'이라고 간주할 수 있습니다 (그래서 '게임 구동 고정적' 방법이죠). 이러한 방법은 모두 게임 구동 방법이며, 유일한 차이점은 처리 방법이 선형적인지 아닌지에 있습니다. 그래서 따로 '고정적/동적'이라고 말하지 않았습니다 (아래 이미지 참고).
믹싱 & 전환 효과
DesigningMusicNow(디자이닝뮤직나우)에서 발간한 글에서, 마이클 스위트는 가장 많이 사용되는 여섯 가지 설계 방법을 두 가지의 주요한 범주인 수직적 리믹싱 (레이어링)과 수평적 리시퀀싱으로 분류했습니다. 이러한 용어는 사실 우리가 게임에서의 상호작용 음악에 대해 말할 때 보통 생각하게 되는 가장 일반적인 용어입니다.
수직적 리믹싱 (레이어링) 방법은 이름에서 알 수 있듯이, 기법이 얼마나 복잡한지에 상관없이 항상 믹싱과 연관되어 있습니다.
수평적 리시퀀싱 방법은 간략하게 말해 뮤직 세그먼트를 전환하는 법과 처리 과정 도중 전환하는 법에 대한 것입니다. 그렇기 때문에 저는 처리되는 내용에 따라 믹싱 방법과 전환 효과 방법으로 더 구분했습니다.
요약
위에서 제시한 분류 표준에 따라 다음과 같은 8 가지 처리 방법이 주어졌습니다.
- 사용자 구동 고정적 전환 효과법 - 게임의 상태에 영향을 받지 않으며 예측할 수 있는 결과로 뮤직 세그먼트를 처리하는 데에 사용됩니다
- 사용자 구동 고정적 리믹싱법 - 게임의 상태에 영향을 받지 않으며 예측할 수 있는 결과로 음악 믹싱을 처리하는 데에 사용됩니다
- 사용자 구동 동적 전환 효과법 - 게임의 상태에 영향을 받지 않으며 예측 불허한 결과로 뮤직 세그먼트를 처리하는 데에 사용됩니다
- 사용자 구동 동적 리믹싱법 - 게임의 상태에 영향을 받지 않으며 예측 불허한 결과로 음악 믹싱을 처리하는 데에 사용됩니다
- 게임 구동 (고정적) 전환 효과법 - 게임의 상태에 영향을 받으며 예측할 수 있는 결과로 뮤직 세그먼트를 처리하는 데에 사용됩니다
- 게임 구동 (고정적) 리믹싱 - 게임의 상태에 영향을 받으며 예측할 수 있는 결과로 음악 믹싱을 처리하는 데에 사용됩니다
- 게임 구동 (동적) 전환 효과 - 게임의 상태에 영향을 받으며 예측 불허한 결과로 뮤직 세그먼트를 처리하는 데에 사용됩니다
- 게임 구동 (동적) 리믹싱 - 게임의 상태에 영향을 받으며 예측 불허한 결과로 음악 믹싱을 처리하는 데에 사용됩니다
참고: 마지막 네 가지 방법은 모두 게임 구동이지만 선형인지 아닌지의 여부에 따라 차이가 있습니다. 그래서 따로 '고정적/동적'이라고 말하지 않았습니다 (아래 이미지 참고).
Interactive Music Hierarchy에서 구조적 단위
이 새로운 분류 표준을 사용하여 음악 설계를 실습해봅시다. 도구로는 Wwise를 사용해봅시다. 시작하기 전에 먼저 이 도구도 새로운 관점에서 살펴봅시다.
Wwise 상호작용 음악 시스템의 구조에 대한 저의 이해를 공유하기 위해 마인드 맵을 하나 보여드리겠습니다.
NG 파일을 원하시면 https://share.weiyun.com/5XNv7gf으로 가주세요.
위의 이미지에서 저는 서로 다른 색깔을 사용하여 음악 설계의 각 구조적 단위의 역할을 표시했습니다.
빨간색 상자는 사용자 구동법을 사용할 수 있으며 파란색 상자는 게임 구동법을 사용할 수 있음을 나타냅니다. 보라색 상자는 사용자 구동법과 게임 구동법을 모두 사용할 수 있음을 나타냅니다. 노란색 상자는 Transition Manager (Property Editor의 Transition 탭)를 나타냅니다. 전환 효과 관리자가 따로 열거된 이유는 사용자 구동법이나 게임 구동법 중 어떤 것을 사용하는지에 상관없이 모든 음악 설계법에서 사용될 수 있기 때문입니다. 초록색 상자는 2019.1.0 버전에서부터 제공되는 Music Event 기능을 나타냅니다. 이 기능도 음악 설계에 대한 잠재적인 접근 방식을 굉장히 증가시키기 때문에 별도로 열거했습니다. 이 부분에 대해서는 나중에 더 알아보도록 하겠습니다.
참고: 색깔로 표시하기 전에 저는 이 기법들을 각 구조적 단위의 중심 기능에 따라서 사용되도록 기술을 제한했습니다. 이렇게 하면 너무 복잡해지는 것을 막을 수 있습니다 (보통 믹싱과 연관됨). 'Mixing'이라고 적힌 작은 보라색 상자가 보이실 거예요. 이 상자는 Interactie Music Hierarchy의 중심 기능이 아닌 다른 것들 (예: State, RTPC, Positioning, HDR 등)을 고려하여 구현될 수 있는 잠재적인 처리 기법을 보여주도록 확장할 수 있습니다.
거시적 수준
Music Switch Container
먼저 Music Switch Container를 살펴봅시다. Music Switch Container Association Editor는 Music Switch Container 전용 편집창입니다. 이 창에서는 상응하는 재생 대상을 개별적 혹은 서로 합쳐진 Game Sync (Switch와 State)와 연결시킬 수 있습니다. Transition Manager는 전환 효과 구현법을 설정하는 데에 사용할 수 있습니다. 따라서 Music Switch Container는 게임 구동 전환효과법을 처리하는 데에 알맞은 구조적 단위입니다.
참고: Music Switch Container에서 사용할 수 있는 Game Sync가 State와 Switch인 것을 볼 수 있습니다. 두 게임 싱크 모두 전환 효과를 만드는 데에 사용될 수 있습니다 (중심 기능과 비중심 기능을 차별하지 않고). 하지만 State와 달리 Switch는 Game Parameter에 의해 구동될 수 있습니다. 그렇기 때문에 다른 상호작용 모드를 사용할 수 있습니다.
Music Playlist Container
다음으로 Music Playlist Container를 살펴봅시다. Music Playlist Container는 Playlist에서 Music Segment의 재생 순서를 제어합니다. 이 컨테이너는 랜덤 재생과 순차적 재생을 지원합니다. 그렇기 때문에 Music Playlist Container는 사용자 구동 고정적/동적 전환 효과법을 다루는 데에 알맞은 구조적 단위입니다.
참고: Sequence Continuous/Step은 선형적 사용자 구동 고정적 전환 효과법에 사용되며 Random Continuous/Step은 비선형적 사용자 구동 동적 전환 효과법에 사용됩니다.
요약
Wwise 상호작용 음악 시스템의 두 가지 구조적 단위 모두 전환 효과와 관련되어 있습니다. Music Switch Container와 Music Playlist Container를 사용하면 사용자 구동 (고정적/동적) 전환 효과법와 게임 구동 (고정적/동적) 전환 효과법을 잘 구현할 수 있습니다. 하지만 이 두 단위는 상호작용 음악 시스템에서 가장 큰 단위입니다. 다시 말해 가장 높은 수준에 위치해 있죠. 이 단위는 리믹싱 방법을 직접 구현하기에는 적절하지 않습니다. 경우에 따라 한 Event를 사용하여 여러 단위를 동시에 재생해야 할 수가 있습니다. 이 블로그 시리즈의 제2부에서는 여기에서 언급한 방법을 사용하여 Wwise에서 테리 라일리의 C 작곡을 생성하는 법을 보여드리겠습니다.
미시적 수준
미시적인 수준에서 살펴봅시다. 구조적 단위 (Music Segment, Music Track, Clip)이 보라색으로 표시된 것이 보이실 거예요. 다시 말해 이 단위는 사용자 구동법과 게임 구동법 모두를 구현하는 데에 사용할 수 있습니다. 또한 Music Switch Container와 Music Playlist Container와 달리 빨간색과 파란색으로 표시된 방법이 전환 효과에 관한 방법이 아닌 리믹싱에 관한 방법인 것을 보실 수 있습니다. 음악 설계에 대한 잠재적 접근법이 보다 높은 수준이 아닌 세부적인 수준에서 존재한다는 것을 분명히 볼 수 있습니다. 그리고 이러한 방법 모두 믹싱과 관련된 방법입니다.
Music Segment
먼저 Music Segment의 Transition Manager가 파란색으로 표시되어 있으며 'Transition Manager: No'라고 표시된 것이 보입니다. 그 이유는 Music Segment를 선택하려고 클릭하는 도중 Property Editor의 Transitions 탭을 볼 수가 없기 때문입니다.
Music Segment는 사실 Wwise 상호작용 음악 시스템에서 가장 특별한 단위입니다. 첫 번째로, Music Segment는 Sync Point를 가지고 있습니다 (Entry Cue, Exit Cue). 이 Sync Point는 하위 구조적 단위와 상위 구조적 단위 간에 서로 통신할 수 있게 해주는 데에 사용됩니다. 이 기능을 사용하면 전환 효과법이 올바르게 작동하도록 할 수 있습니다.
두 번째로, Music Segment와 Music Track 아이콘을 통해 Music Segment에 여러 Music Track이 담길 수 있다는 것을 볼 수 있습니다. 사실 Music Segment의 직접적인 하위 단위는 Music Track입니다. Music Track에는 세그먼트 전환 효과가 없습니다. 그렇기 때문에 Music Segment는 사용자/게임 구동 리믹싱법을 처리하는 데에 알맞은 구조적 단위입니다.
참고: '기존의' 수직적 기법 (게임 구동 리믹싱)은 Music Segment를 사용하기에 가장 알맞은 방법입니다.
Also, Entry Cue and Exit Cue are set in the Music Segments. To get a variable rhythm similar to the progressive rock, we need multiple Music Segments with different Bars/Beats or Entry Cue/Exit Cue settings.
Music Track
Music Track을 함께 살펴봅시다. Music Track은 Music Segment와 비슷합니다. 사용자 구동 리믹싱과 게임 구동 리믹싱법을 모두 구현하는 데에 사용할 수 있죠. 여기서 차이점은 Music Track이 재생 내용을 변경하여 믹싱 변주를 만든다는 것입니다. 사용자 구동 (동적) 리믹싱법은 Random Step/Sequence Step Track을 사용하여 구현됩니다. 게임 구동 리믹싱법은 Switch Track을 사용하여 구현됩니다. Music Track은 상호작용 음악 시스템에서 Voice와 같다고 생각하시면 됩니다. Transition Manager와 함께 사용하여 '별개의' 리믹싱을 구현할 수 있죠 (볼륨을 제어하는 RTPC로 '지속적' 리믹싱을 하는 것과 달리).
참고: Sequence Step Track은 고정적 리믹싱법을 구현하는 데에 사용될 수 없습니다. Sequence Step Track이 재생될 때마다 다음 Sub-Track으로 재생 내용이 전환됩니다. 그렇기 때문에 이 방법은 완전한 제어가 불가능합니다. 이 방법에서는 전환 순서만 설정할 수 있죠.
참고: Switch Track에서 사용할 수 있는 Game Sync가 State와 Switch인 것을 볼 수 있습니다. 두 게임 싱크 모두 전환 효과를 만드는 데에 사용될 수 있습니다 (중심 기능과 비중심 기능을 차별하지 않고). 하지만 State와 달리, Switch 변화는 Game Parameter에 의해 구동될 수 있습니다. 그렇기 때문에 다른 상호작용 모드를 사용할 수 있습니다.
Clip
이제 Clip을 살펴봅시다. Audio Clip의 경우, 사용자 구동 고정적 리믹싱법만 구현할 수 있습니다. 다시 말해 간단한 자동 볼륨, LPF, HPF만 편집할 수 있죠. MIDI Clip의 경우 다양한 방법을 구현할 수 있습니다. 하지만 사실 대부분의 방법이 사용자 구동 리믹싱법이나 게임 구동 리믹싱법을 사용합니다. MIDI 자체는 소리를 생성할 수 없습니다. 그렇기 때문에 Actor-Mixer Hierarchy에서 오디오 오브젝트를 트리거해야 합니다. 이 오브젝트는 음원 플러그인이나 샘플이 담긴 구조적 단위가 될 수 있습니다. MIDI 파일에 있는 CC 정보는 Game Parameter로 사용하여 Switch/Blend Container를 제어해서 사용자 구동과 같은 게임 구동 리믹싱법을 구현할 수 있습니다. 하지만 2019.1.0 버전부터 제공된 Music Event 기능을 사용하면, 사용자 구동법과 게임 구동법 간의 변환이 쉬워집니다. 작곡가의 경우 사용할 수 있는 사용자 구동법이 훨씬 더 많습니다.
참고: MIDI에 의해 트리거되는 음원, 샘플, 컨테이너 오브젝트의 믹싱은 Interactive Music Hierarchy에서 구조적 단위를 통해 구현할 수 없습니다. 대신 Actor-Mixer Hierarchy나 Master-Mixer Hierarchy에서 구현되어야 합니다.
MIDI의 장점
Music Event 기능이 가져다주는 새로운 가능성을 좀 더 잘 활용하려면, 기존의 MIDI 기술을 더 잘 살펴봐야 합니다. 사실 게임 음악의 초기 개발에 대해 말하려면 MIDI를 빼놓을 수 없습니다. 1980대 초반에 처음 출시된 후 MIDI는 다양한 플랫폼에서 컴퓨터 음악 개발을 위한 일반 정보 교환 프로토콜로 빠르게 사용되기 시작했습니다. 사실 LucasArts가 개발한 iMUSE 엔진도 처음에는 MIDI를 기반으로 했습니다 (하지만 나중에 MIDI 모듈이 제거됨). 하지만 CD 음원이 출시된 후에 MIDI의 인기가 떨어졌습니다. 가장 주된 이유는 작곡가가 플레이어의 장치에서 재생되는 MIDI 음악의 실제 구현을 정확하게 예측할 수가 없었으며, 믹싱 방면에서 MIDI 기법이 오디오 기반 기법보다 불편하기 때문입니다.
하지만 2014년 Wwise에서 MIDI 음악 기능이 제공된 후 (MIDI가 오디오 기반 프레임워크에 통합됨) MIDI의 장점이 다시 재발견되고 있습니다.
1. MIDI는 데이터 차지량이 작습니다. 오디오 파일과 달리 MIDI 파일은 전자 악기에서 사용되는 음악과 비슷합니다. 그렇기 때문에 오디오 에셋을 추가하는 것 보다 MIDI 에셋을 추가하여 음악 변주를 만드는 것이 훨씬 저렴합니다. 더 많은 음악 콘텐츠를 MIDI로 구현함에 따라 이 장점은 더욱 극대화됩니다. Remedy(레메디) 오디오 팀은 Wwise 투어 2018에서 컨트롤(Control)의 음악 설계를 공유했습니다. 파이썬을 사용하여 다양한 리듬 패턴을 일괄 생성한 대량의 MIDI 에셋을 보여줬죠. 전반적인 데이터 차지량에 최소한의 영향으로 거의 무한한 변주를 만들어 사운드를 세부화할 수 있었습니다. 자동화된 생성과 배포로 음악적 박자도 아주 간편하게 전환할 수 있죠. 사실 리듬 변주를 생성하는 이 방법은 피치가 있는 에셋에도 사용할 수 있습니다.
2. 음악과 미술적 방면에서 MIDI 에셋은 오디오 음을 렌더링하여 서로 다른 청취 목적을 달성하는 데에 사용할 수 있습니다. 또한 특정 상황에서 서로 다른 청취 목적 간에 내부적 연결을 유지 (예: 동기)하는 데에도 MIDI를 사용할 수 있습니다.
3. 모듈식 신시사이저의 관점에서, MIDI 음은 Wwise에서 Envelop Trigger로 사용되어 실시간 합성을 구동할 수 있습니다. 이렇게 하면 오디오 보다 더욱 유기적인 변주를 생성할 수 있습니다. 심지어 벨로시티가 다른 대량의 MIDI 트랙을 가변적 템포에서 실시간으로 음악을 합성하기 위한 클록 신호(clock signal)로 사용할 수도 있습니다 (올리비아 드리비에의 Audiokinetic 블로그 시리즈 참고), 또한 MIDI CC는 고정적 자동화를 위한 훌륭한 정보원이기도 합니다. MIDI 데이터에서 이 CC 정보를 사용하면 실시간 합성 매개 변수를 구동할 수 있습니다. 또한 게임에서 이 정보를 사용하여 예술적 표현을 렌더링할 수도 있습니다.
Music Event
이제 MIDI 장점을 알아보았으니 2019.1.0 버전부터 제공된 Music Event 기능을 함께 살펴봅시다. 이 기능을 글의 마지막 부분에 넣은 이유는 Music Event가 MIDI 음보다 더 강력하기 때문입니다 (MIDI 음은 Clip으로만 존재할 수 있음). Music Event는 Clip에 들어가지 않고 별도로 존재합니다. Music Event는 오디오 오브젝트가 아닌 다른 것을 재생하는 데에 사용할 수 있습니다. 사실 Event가 실행할 수 있는 대부분의 기능을 실행할 수 있죠. Music Event를 사용하면 사운드의 재생과 믹싱 및 사운드 엔진을 다양한 방법으로 제어할 수 있으며, 심지어 애니메이션도 구동할 수 있습니다. 최근 블로그 글에서 피터 'PDX' 드레셔(Peter "PDX" Drescher)는 Music Event와 애니메이션 시퀀스 간 상호작용하는 법을 설명해 주었습니다.
위의 이미지에서 저는 Music Event에 포함된 Action을 열거하고 음악 설계의 관점에서 간단하게 분류해보았습니다. 과거에는 Event를 트리거하기 위해 게임 엔진이 Game Call을 전송해야 했습니다. 음악 디자이너는 Music Callback/Custom Cue를 사용하여 Event를 트리거할 수 있지만, 여전히 Wwise 밖에서 다른 작업을 실행해야 했습니다. 다시 말해 프로그래머의 도움이 필요했죠. 하지만 이제는 Wwise 안에서 스스로 모든 작업을 완료할 수 있습니다. 이로 인해 효율성이 상당히 향상되었으며 다양한 창의적 가능성이 제공되었습니다.
예를 들어 Music Switch Container의 경우, 위의 이미지에서 볼 수 있듯이 RTPC와 State를 통해 믹싱을 제어할 수 있습니다. Music Event를 사용하면 Event Action에서 Set Game Parameter와 Set State를 선택할 수 있습니다. 이와 같이 음악 디자이너는 Music Event를 사용하여 믹싱 변주를 만들어서 사용자 구동 고정적 리믹싱법을 구현할 수 있습니다 (또한 Music Event가 Sample & Hold를 제어하도록 하여 사용자 구동 고정적 믹싱법을 구현할 수도 있습니다).
다시 Clip level로 돌아가 봅시다. Music Event의 경우 Switch Container와 Blend Container를 정확하게 제어할 수 있습니다. 음악 디자이너는 마치 DAW에서 처럼 Kontakt 악기를 게임에서 자유롭게 사용할 수 있습니다. (키스위치와 샘플 모핑을 게임에서 사용한다고 상상해보세요!)
이 블로그의 제 2부에서는 이 글에서 열거한 8가지 처리 방법의 장단점을 비교해보고, 모차르트 주사위 게임과 테리 라일리의 C 작곡을 Wwise에서 재구성해보려고 합니다. 그리고 제 3부에서는 컴퓨터 지원 작곡 도구를 사용하여 게임 음악을 제작하는 법을 보여드리려고 합니다. 기대해 주세요!
댓글