다른 게임 엔진들과 마찬가지로 Wwise는 숫자 식별자 (ID)를 사용하여 프로젝트의 에셋을 관리합니다. Wwise는 프로젝트 에셋에 두 타입의 ID를 부여합니다. 한 타입은 Wwise Authoring 애플리케이션 (wa)이 사용되며 다른 한 타입은 Wwise Sound Engine (wse)이 사용됩니다. Wwise는 프로젝트가 편집되는 동안 이 ID를 부여하고 업데이트합니다. 이 작업은 백그라운드에서 진행되기 때문에 보통 팀원들이 신경 쓸 필요가 없습니다. 하지만 게임 수정이나 확장 등 차후 업데이트가 있는 게임 프로젝트의 경우, Wwise가 어떻게 에셋 ID를 부여하고 사용하는지 아는 것은 훨씬 더 중요할 수 있습니다. 대부분의 경우 게임 업데이트를 가능한 한 최소화하는 편이 좋습니다. 오디오 에셋 (.wem 파일)은 Wwise 프로젝트에서 가장 큰 부분을 차지하기 때문에, 업데이트에서 오디오 파일의 수를 제한하는 것이 좋습니다. 따라서 오디오 에셋을 다시 배급할 필요 없이 재사용할 수 있도록 프로젝트 오디오 에셋의 ID를 변경하지 않는 것이 중요합니다.
Wwise가 프로젝트 에셋에 ID를 부여하는 법을 설명하기 위해 아래 있는 간단한 프로젝트를 사용해봅시다. 이 프로젝트는 다음으로 구성되어 있습니다.
Hello.wav라는 한 오디오 에셋;
해당 오디오 에셋을 참조하는 Hello라는 Sound 오브젝트;
재생 동작이 지정되어 있으며 게임이 오디오 에셋의 재생을 트리거하는 데에 사용되는 Play_Hello라는 Event 오브젝트.
이미지: Play_Hello 이벤트와 대상 사운드 Hello.
Default Work Unit의 내용을 살펴보고 Wwise가 해당 Sound 오브젝트에 무엇을 할당했는지 확인해봅시다. 다음은 해당 Work Unit 파일에서 Sound 오브젝트의 항목입니다 (.wwu). 보기 쉽도록 관련 없는 Sound 오브젝트 항목은 제거되었습니다.
Wwise가 해당 Sound 오브젝트에 ID와 ShortID라는 두 ID를 부여한 것을 볼 수 있습니다. 각 ID를 좀 더 자세히 살펴봅시다.
이 ID는 Sound 오브젝트의 Wwise Authoring ID입니다. 128 비트의 전 세계적 단일 식별자 (GUID)이며 항상 단일합니다. 이 ID를 간단하게 줄여서 GUID라고 부르겠습니다. Wwise Authoring이 GUID를 사용하는 이유는 전역적 단일성 때문입니다. GUID를 사용하면 다음 작업이 훨씬 쉬워집니다.
편집 소프트웨어가 수행해야 하는 다양한 작업 관리;
여러 팀원들이 사용할 수 있는 프로젝트 관리;
워크 유닛 간의 오브젝트 참조.
Event 오브젝트 Play_Hello's Work Unit을 살펴보면 Sound 오브젝트 Hello를 참조하는 것이 보입니다.
하지만 Wwise Sound Engine에서 GUID를 사용할 경우, 프로젝트의 에셋 개수를 고려했을 때 크기가 너무 크기 때문에 다소 비실용적입니다.
Work Unit에서 특정 오브젝트에 주어지는 또 다른 ID는 32비트 정수인 ShortID입니다. 이 ID는 프로젝트의 SoundBank에 저장되는 유일한 식별자이며 Wwise Sound Engine에 의해 사용됩니다. 보기 쉽도록 이 ID를 ShortID라고 줄여서 부르겠습니다. 프로젝트 전체를 통틀어 단일하게 식별하는 GUID와 반대로 ShortID는 해당 ShortID 범위 내에서 단일하게 식별합니다. 따라서 오브젝트의 ShortID는 동일한 ShortID 범위를 가진 다른 오브젝트 사이에서만 단일하죠. ShortID의 범위는 세 가지가 있습니다.
1. Explicit ID - Sound Engine의 SDK 함수를 통해 접근할 수 없는 오브젝트입니다
이러한 오브젝트는 사용자 코드에 의해 참조될 수 없습니다 (예: Actor-Mixer 오브젝트). 이 범위는 오브젝트 타입으로 더 나뉘어집니다. 오브젝트의 ShortID는 해당 오브젝트 타입 안에서만 단일합니다. 다음은 오브젝트 타입의 예시입니다.
Actor-Mixer와 Interactive Music 오브젝트 (Sound, Container)
Bus 오브젝트 (Bus, Aux Bus)
Effects
ShortID는 오브젝트 생성 시 할당되는 랜덤 숫자입니다. 이 값은 랜덤이기 때문에 각 오브젝트의 ShortID는 각 Work Unit 항목에서 명시적으로 추적됩니다.
2. Implicit ID - Sound Engine의 SDK 함수에서 접근할 수 있는 오브젝트입니다 (예: Event, State, Switch).
이 오브젝트는 이름으로 SDK 함수에 의해 참조될 수 있기 때문에, 이러한 오브젝트는 특정한 ShortID 값이 할당됩니다. ShortID는 해당 오브젝트 이름의 해시에 의해 생성됩니다. 다음과 같은 이유 때문입니다.
두 오브젝트가 동일한 이름을 가질 수 없습니다.
두 오브젝트가 동일한 ShortID를 가질 수 없습니다.
(위에 있는) 명시적 ShortID와 마찬가지로 이 범위에서의 오브젝트는 종류별로 묶어집니다. 다음은 오브젝트 타입의 예시입니다.
Events
Switches
States
RTPC
ShortID는 랜덤이 아니라 오브젝트의 이름에 의해 암시적으로 결정되기 때문에 프로젝트의 Work Unit에 의해 추적되지 않습니다. 위에서 Play_Hello 이벤트의 Work Unit의 항목을 보면 Play_Hello 이벤트에 ShortID 항목이 없는 것이 보입니다.
3. 미디어 에셋 (.wem 파일)
모든 미디어 에셋에는 저마다 명시적인 ShortID가 주어집니다. 따라서 이 아이디는 랜덤 숫자이며 Work Unit에 의해 반드시 추적되어야 합니다. 위의 예시를 보면 Sound의 미디어가 AudioFileSource 오브젝트를 통해 추적되며 미디어에 부여된 ID는 MediaID 항목을 통해 추적됩니다.
Wwise Authoring은 오브젝트가 생성됨에 따라 ShortID를 부여하여 단일하도록 해줍니다. 하지만 수많은 팀원들이 새로운 에셋을 추가하는 경우, ShortID가 겹치는 문제가 발생할 수 있습니다. 다음 상황을 고려해봅시다.
프로젝트에 ShortID가 12345678인 오브젝트 A가 있습니다.
팀원 중 한 명이 별도의 Work Unit을 만듭니다.
이 새로운 Work Unit은 프로젝트에 오브젝트 A가 생기기 전에 만들어졌습니다.
새로운 Work Unit에 동일한 ShortID를 가진 오브젝트 오브젝트 B가 있습니다.
새로운 Work Unit이 프로젝트로 복사됩니다.
이 경우 동일한 ShortID를 가진 두 오브젝트가 생겨서 ShortID가 충돌하게 됩니다. Wwise는 두 오브젝트 중 하나에 새로운 단일한 ShortID를 부여하여 충돌을 해결합니다. Wwise는 충돌을 일으키는 오브젝트에 새로운 ShortID를 부여합니다. 즉, 첫 번째로 로드된 오브젝트의 ShortID가 유지되며 그 후에 충돌하는 오브젝트의 ShortID가 변경됩니다.
그렇다 해도, 다른 모든 에셋이 로드된 상태에서 새로운 오브젝트가 Wwise에 추가되는 한 문제는 생기지 않습니다. DLC가 있는 게임의 경우 프로젝트에 새로운 에셋을 추가할 때 반드시 이미 배급된 에셋 (예: 프로젝트 Work Unit)이 항상 로드되어 있어야 합니다. 이렇게 하면 새로운 에셋이 기존의 / 배급된 에셋과 충돌하는 것을 방지할 수 있습니다. 새로운 에셋이 다른 새로운 에셋과 충돌할 경우, Wwise는 새로운 에셋이 합쳐질 때 충돌을 해결합니다.
참고: Wwise가 충돌하는 오브젝트의 ShortID를 변경하여 ShortID 충돌을 해결할 경우 SoundBank에 있는 ShortID도 변경됩니다. 이 경우 SoundBank를 반드시 재생성해야 한다는 로그 메시지가 뜹니다.
Wwise가 오브젝트에 ShortID를 부여하여 오브젝트를 단일하게 식별하는 법을 살펴보았습니다. 미디어 에셋도 동일한 개념으로 식별된다는 것을 보았습니다. 하지만 미디어 에셋은 다른 모든 오브젝트와 다른 아주 중요한 차이점이 하나 있습니다. 바로 다시 사용될 수 있다는 점입니다. 우리가 사용한 간단한 프로젝트의 업데이트된 버전을 살펴봅시다. 이 버전에서는 Hello.wav를 사용하는 두 번째 Sound 오브젝트를 만들었습니다. 다음은 Default Work Unit에서 두 Sound 오브젝트와 관련된 내용입니다. 보기 쉽도록 미디어 에셋 ShortID를 MediaID라고 줄여 부르겠습니다.
두 Sound 오브젝트에 모두 동일한 MediaID가 주어진 것이 보입니다. 그 이유는 두 Sound 오브젝트가 모두 완전히 동일한 미디어 에셋을 사용하기 때문입니다. 게임을 출시할 때 동일한 미디어 에셋의 여러 복사본을 내보낼 필요는 없습니다. 동일한 오디오 에셋의 두 인스턴스는 .wem 파일이 동일한 경우에만 동일하다고 고려됩니다. 이 말은 다음 사항을 의미합니다.
두 인스턴스가 변환 전에 동일함:
미디어 에셋은 변환 전에 Source Editor를 통해 변경됩니다;
파일 변경의 예시로 파일 잘라내기, 페이드 추가하기 등이 있습니다;
이 예시에서는 두 Sound Object가 파일을 변경하지 않습니다.
변환 후에 두 인스턴스가 동일함:
Conversion Setting은 Conversion Settings Editor를 통해 편집할 수 있습니다;
이 예시에서는 두 Sound Object가 모두 동일한 Conversion Setting을 사용합니다.
두 Sound 오브젝트가 동일한 MediaID을 가졌던 예시에서 Hello.wav 오디오 에셋을 살펴봅시다. 프로젝트를 다시 편집해서 HelloAgain에 서로 다른 변환 설정을 지정해봅시다. 다음은 업데이트된 Work Unit입니다. 다시 말하지만 이 예시와 관련 없는 항목은 제거했습니다.
HelloAgain 이 다른 Conversion Settings를 사용하기 때문에 .wem 파일이 달라지게 되고, 이에 따라 또 다른 MediaID가 부여됩니다. 또한 Hello가 아닌 HelloAgain 에 새로운 MediaID가 부여되었다는 점을 참고해 주세요. 그 이유는 Hello 에서 미디어 에셋이 변경되지 않았기 때문입니다.
Wwise는미디어 에셋이 생성되거나 편집될 때 항상 MediaID를 재평가합니다. Wwise는 MediaID가 가능한 한 동일하게 유지되도록 합니다. 그렇지 않을 경우 생성/편집된 에셋에만 새로운 MediaID가 부여됩니다.
Wwise에서 프로젝트가 완전히 로드되고 편집되는 한, Wwise는 변경되지 않는 미디어 에셋이 자신들의 MediaID를 유지하도록 합니다. 하지만 프로젝트의 MediaID 일관성을 유지하기 위해 프로젝트 팀이 알아야 할 다른 고려 사항이 있습니다.
Wwise는 미디어 에셋의 모든 인스턴스를 살펴보고 두 개 이상의 인스턴스가 동일한 변환 미디어를 사용할 경우 MediaID를 재사용하는 방식으로 MediaID를 부여합니다. 그러기 위해서는 Wwise가 반드시 미디어 에셋의 모든 인스턴스를 파악해야 합니다. 하지만 일부 인스턴스가 Wwise에 로드되지 않았을 경우 어떻게 될까요? 한 에셋 인스턴스가 로드되지 않은 Work Unit인 경우를 예로 들 수 있습니다. Work Unit이 로드되면 Wwise는 충돌이 없는지 확실히 하기 위해 Work Unit 안에 있는 모든 MediaID를 재평가하여야 합니다. 다시 말하면, Wwise가 각 변환된 미디어에 고유한 MediaID가 단 한 개만 부여된 것이 맞는지 확실히 해야 한다는 뜻입니다. 이때 고려해야 할 두 가지 상황이 있습니다.
프로젝트 불러오기
Wwise는 모든 Work Unit이 로드되자 마자 모든 MediaID를 평가합니다. 충돌이 있을 경우, 어떤 MediaID가 유지될 것인지 예측할 수가 없습니다. 예를 들어, 여러 팀원이 프로젝트에 새로운 Work Unit을 만들 경우 이러한 문제가 생깁니다. 예시:
팀원 1이 Example.wav라는 미디어가 있는 NewWorkUnit1을 만듭니다;
팀원 2가 마찬가지로 Example.wav를 사용하는 NewWorkUnit2를 만듭니다;
두 개의 새로운 Work Unit이 포함된 전체 프로젝트가 Wwise에 로드됩니다.
이 경우 MediaID 충돌이 생기며 Wwise가 해결하게 됩니다. 여기서도 고려해야 할 두 가지 상황이 있습니다.
Example.wav 는 새로운 에셋일 경우. 이 경우 나머지 프로젝트에 영향을 주지 않습니다. Wwise가 단순히 새로운 Work Unit 중 하나의 MediaID를 유지합니다.
Example.wav 가 기존의 에셋일 경우. Wwise가 해당 Work Unit이 두 팀원에 의해 로드되었다는 가정 하에 기존의 Work Unit에서 MediaID를 가져오게 됩니다.
Work Unit 로드하기
프로젝트의 일부 Work Unit이 프로젝트에 로드되지 않을 수 있습니다 (더 자세한 내용은 “Loading/unloading Work Units from your project” 참고). 위와 동일한 예시를 약간 변경해서 사용해 봅시다:
Example.wav 가 이미 프로젝트의 Work Unit OldWorkUnit 안에 있습니다;
팀원 1과 2가 둘 다 새로운 워크 유닛을 만들어서 Example.wav가 생기고 OldWorkUnit 이 언로드됩니다.
이 경우 OldWorkUnit의 MediaID를 인지하지 못한 채, 새로운 Work Unit에 각각 MediaID가 부여되는 위험이 있습니다. 그렇게 되면 OldWorkUnit 이 로드될 때 충돌이 생기며 Wwise가 NewWorkUnit1 이나 NewWorkUnit2의 MediaID를 유지하여 충돌을 해결합니다. 하지만 OldWorkUnit이 이미 출시된 에셋에 들어 있을 경우 어떻게 될까요?
어느 경우든, 팀원이 실수로 프로젝트의 MediaID 지정을 변경할 확률이 높습니다. 다음 작업 과정을 실행하면 이 문제를 방지하는 데에 도움이 됩니다.
MediaID를 올바르게 부여하려면 Wwise가 전체 프로젝트의 MediaID 할당을 알아야 합니다. 이전 섹션에서 보았듯이, 한 개 이상의 Work Unit이 언로드될 경우 Wwise가 모든 할당을 파악하지 못하게 됩니다. 이를 위해, Wwise는 단일한 파일을 사용하여 프로젝트의 MediaID 할당을 관리할 수 있는 방법을 지원합니다. 단일 파일 MediaID 관리 작업 과정을 사용할 경우
MediaID가 더 이상 Work Unit에 저장되지 않습니다.
전체 프로젝트의 MediaID가 'project-name.mediaid'라는 별도의 파일에 저장되며 프로젝트의 메인 파일인 'project-name.wproj' 옆에 배치됩니다.
WwiseConsole.exe와 다음 전달인자를 사용하면 Wwise가 MediaID를 관리하는 법을 선택할 수 있습니다 (Work Unit vs. 단일 파일):
move-media-ids-to-single-file: 기존의 'MediaIDs in Work Units' 작업 과정에서 단일 파일 작업 과정으로 변경합니다. 이 작업은 명령줄로부터 전체 프로젝트를 로드하며 .mediaid 파일을 생성하고 Work Unit 파일에서 MediaID 항목을 제거합니다.
move-media-ids-to-work-units: 단일 파일 작업 과정에서 'MediaIDs in Work Units' 작업 과정으로 변경합니다. 이 작업은 명령줄로부터 전체 프로젝트를 로드하며 MediaID를 .mediaid 파일로부터 알맞은 Work Unit 파일로 옮기며 .mediaid 파일을 삭제합니다.
update-media-ids-in-single-file: .mediaid 파일의 내용물을 업데이트합니다. 이 작업은 명령줄로부터 전체 프로젝트를 로드한 후 업데이트된 MediaID를 .mediaid 파일에 작성합니다.
계속해서 예시 프로젝트인 WwiseIDs를 사용하여, 다음 명령어를 실행하여 MediaID를 단일 파일로 변경해봅시다.
WwiseConsole move-media-ids-to-single-file WwiseIDs
다음은 WwiseIDs.mediaid의 내용입니다.
다시 말하지만 예시 프로젝트에는 두 개의 음원 인스턴스를 가지는 Hello.wav라는 단 하나의 미디어 에셋만 있습니다. Hello.wav의 각 인스턴스의 경우
인스턴스의 항목이 음원의 GUID (Authoring ID)로 색인됩니다.
인스턴스에 MediaID가 부여되어 있습니다.
MediaID가 부여될 때 인스턴스에 의해 사용되는 Conversion Settings를 표시하는 해시 값이 있습니다.
MediaID 파일은 프로젝트 로딩 동안 Work Unit이 로드된 후에 로드됩니다. MediaID 파일은 어느 Work Unit이 로드되었는지와 상관없이 로드됩니다. MediaID 파일을 로드할 때, 오디오 파일의 각 인스턴스의 Conversion Setting이 해시되며 파일에서의 해시와 비교됩니다. 해시가 서로 일치하지 않을 경우 인스턴스에 새로운 MediaID가 부여되며, 필요할 경우 이전 섹션에서 열거한 동일한 규칙을 사용합니다. 프로젝트가 로드되면 로드된 Work Unit에서의 모든 인스턴스에 알맞은 MediaID가 부여됩니다. 하지만 나중에 더 많은 Work Unit이 로드될 경우, MediaID가 재평가됩니다.
MediaID 파일을 사용하여 Wwise 프로젝트를 마일스톤과 동기화할 수 있습니다. 각 마일스톤에서 Wwise 프로젝트의 MediaID 파일은 WwiseConsole.exe update-media-ids-in-single-file을 통해 이전 마일스톤의 MediaID로 업데이트됩니다. 업데이트된 MediaID 파일을 통해 전체 프로젝트가 새 마일스톤으로 태그됩니다.
팀이 Wwise 프로젝트의 미디어 에셋 ID를 관리하는 방법은 팀과 프로젝트의 규모와 범위에 따라 달라집니다.
소규모 프로젝트를 작업하는 소규모 팀의 경우, 각 팀원이 전체 Wwise 프로젝트를 로드한 채로 작업하는 편이 더 관리하기 쉽습니다. 버전 관리 소프트웨어를 사용하여 프로젝트를 관리하면 MediaID가 충돌하지 않도록 할 수 있습니다. 버전 관리 소프트웨어는 확장 배포를 하는 프로젝트의 경우 꼭 필요합니다. 각 배포시에 버전 관리 소프트웨어를 사용하여 프로젝트를 잠그면, 배포된 에셋을 변경하지 않은 상태로 유지할 수 있습니다.
프로젝트의 범위가 넓으며 여러 팀원이 새로운 Work Unit을 동시다발적으로 만들고 작업할 경우, 더 나은 접근 방식이 필요합니다. 새로운 Work Unit을 별도로 개발할 수 있지만, 이 경우 팀원이 전체 Wwise 프로젝트를 로드한 채로 개발해야 하며, 새로운 Work Unit을 프로젝트에 하나씩 도입해야 합니다. 이러한 경우 단일 파일을 사용하여 프로젝트의 MediaID를 관리하는 것이 좋습니다.
이 페이지가 도움이 되었나요?
작업하는 프로젝트에 대해 알려주세요. 언제든지 도와드릴 준비가 되어 있습니다.
프로젝트를 등록하세요. 아무런 조건이나 의무 사항 없이 빠른 시작을 도와드리겠습니다.
Wwise를 시작해 보세요