Wwise 2022.1 Unreal 통합 안내
이 버전은 Wwise Unreal 통합의 주요 이정표입니다. Unreal 엔진 5가 엔진을 새로운 차원으로 이끌어주듯이 Audiokinetic의 Wwise Unreal 통합도 두 도구의 조화로운 사용 가능성의 한계를 넓혀줍니다.
변경된 내용은 1년 넘게 공들인 개발 작업과 Wwise 및 Unreal을 사용하는 개발자들과의 많은 토론을 걸친 결과입니다. 지난 몇 년 동안 개발 과정에서 점진적인 최적화와 기능 추가를 통해 많은 교훈을 얻었습니다. Audiokinetic의 궁극적 목표는 가능한 모든 작업 과정을 지원하여 커스터마이징 없이 모든 게임의 요구 사항을 충족할 수 있게 하는 것입니다. 다음 섹션에서 볼 수 있는 것처럼 이번 출시는 이 목표를 향한 큰 진전을 보여줍니다. 기쁜 마음뿐만 아니라 좌절감과 불편한 점에 대해서도 알려주신 Wwise 사용자분들에게 진심으로 감사합니다. 이 커뮤니티의 목소리는 우선 순위를 정하고 많은 사람들의 필요에 맞게 통합을 성장시키는 데 큰 도움이 되었습니다.
변경 사항 개요
우선 순위
Wwise 통합의 기반은 Sound Engine을 개발 엔진의 기본적인 한 부분으로 노출시켜주는 것입니다. 저희 코드는 이제 지속적으로 혁신적인 아이디어를 추구하는 여러 제품을 위한 효율적인 개발, 패키징, 오디오 에셋 재생에 중추적인 역할을 합니다. 처음 Wwise Unreal 통합 출시 이후 새로운 기술이 등장하고 개발되는 프로젝트의 규모가 상당히 커지면서 우선 순위가 바뀌기 시작했습니다. VR과 같은 기능 요구 사항부터 Legacy 작업 과정을 Event-Based Packaging으로 마이그레이션하는 등 프로젝트의 복잡성 패러다임 변화까지, 각 Wwise 릴리즈는 이전 버전을 크게 개선했습니다. Wwise 2022.1의 경우 현재 시점에서 각 사용자에게 정말 중요한 것이 무엇인지를 고민하고, 호환성과 기능 추가뿐만 아니라 Wwise 통합의 상태를 어떻게 개선할 수 있는지를 고려했습니다. 이러한 우선 순위 검토를 통해 현재 코드 베이스에 대해 중요한 깨달음이 있었죠.
안정성: 외부 음원 및 Event-Based Packaging
저희는 통합 개선을 위해 개발자에게 항상 중요하지 않은 복잡한 작업 과정을 비활성화하기 시작했습니다. 그 중 다수가 주요 안정성 문제를 야기했고, 일부는 똑같이 중요한 개발자 작업 과정과 충돌할 수 있었죠.
그 중 External Sources 시스템이 완벽한 예시입니다. 지난 몇 년 동안 모든 제품에 작동하는 단일한 시스템을 구현하려고 노력했으며, 하나 이상의 미디어 파일을 여러 개의 External Source와 연결하는 가능한 모든 방법을 추가했습니다. 또한 이러한 에셋의 패키징을 시스템의 일부로 처리하는 것 외에도 에셋이 제어된 수명을 가지도록 허용했습니다.
현실은 Wwise 사용자가 제작된 제품만큼 실제 External Source의 사용 용도도 그만큼 다양하다는 것이었습니다. 사실상 맞춤형 시스템이 개발자와 프로젝트 요구 사항에 맞게 다르게 처리된다는 것을 발견했죠. 제공된 시스템에 만족하는 개발자들도 있었지만 대부분의 개발자들은 이 시스템에 표함된 불필요한 복잡성이 구현 버그를 추적하기 힘들게 만든다고 생각했습니다. 이를 상쇄하기 위해 많은 개발자들이 특수한 조건에 맞게 저희 필수 코드를 적극적으로 변경했죠 .
복잡성 규모 조정의 또다른 예시는 Event-Based Packaging입니다. 이 시스템은 2019.2에서 처음 출시된 이후로 계속 성장하였으며 현재 Unreal 엔진과 Wwise Authoring이 서로 충돌하는 것처럼 느껴지는 상태가 되었죠. 2019.2와 2021.1 개발 과정을 통해 기능의 안정성을 확보했지만 시스템이 의도보다 복잡하게 되었습니다. 작업 과정에 Event-Based Packaging을 도입한 대부분의 개발자들은 구현에 성공하고 만족했지만 일부 팀의 작업 과정은 시스템의 부족한 유연성으로 인해 악화될 수 있습니다. Wwise 2019.2에서 소개되었을 때 알게된 Event-Based Packaging에 대한 혹독한 사실은 개발되는 게임만큼 에셋을 관리하는 방법도 그만큼 다양하다는 것이었습니다. 저희의 의도는 항상 간결하고 잘 작성된 코드를 적용하여 Wwise를 활용하는 모든 프로젝트를 지원하는 것이었습니다. 하지만 Event-Based Packaging이 복잡한 코드로 진화되어서 모든 플랫폼에서 모든 방면을 시험하기가 불가능했습니다. 게다가 Unreal 엔진의 참으로 무한하고 독특하며 복잡한 특성때문에 저희가 시스템에 내장시킨 자유로움으로 인해 특정 동작 그룹이 전체 시스템을 무너뜨릴 수 있는 상황이 발생할 수 있었죠. 이 복잡성은 시스템을 사용하려는 개발자들이 문제가 생길 시 Audiokinetic 지원팀에 문의할 수 밖에 없게 만들었습니다.
그럼에도 불구하고 저희는 '이벤트당 한 뱅크'라는 약속이 에셋 관리에 정말로 혁신적인 변화를 가져다 것을 믿으며 굉장히 복잡한 현대 제품을 개발할 때 필수적인 단계라는 것을 믿고 있습니다. Event-Based Packaging 도입으로 발생한 모든 문제를 해결할 수 없다는 것이 명확했기 때문에 Wwise 2022.1에서는 대부분의 작업 과정을 지원하면서 개발자들이 에셋 관리 솔루션을 마이그레이션하고 확장할 수 있게 지원하는 데 특별한 주의를 기울였습니다.
결과:
External Source는 이제 선택 사항입니다. 통합 데모의 일부로 External Source의 기본 구현을 제공하지만, 개발자들이 이제 원하는 방식대로 자체적인 버전의 External Source를 자유롭게 구현할 수 있습니다. 여기에는 발견 가능성, 패키징된 정보, 미디어 발견, 패키징도 포함됩니다.
Legacy 작업 과정과 Event-Based Packaging 작업 과정이 이제 하나로 통합되었습니다. 개발자 피드백과 저희 경험을 토대로 두 작업 과정에서 최상의 부분과 더 현대적이고 간결한 Wwise Unity Addressables 패키지 작업 과정을 통합했습니다. 충돌하는 여러 시스템을 지원하는 대신 이제 확장 가능한 하나의 시스템만 존재합니다.
확장성 및 코드 가독성
과거에 Wwise Unreal 통합은 Wwise Sound Engine을 Unreal 프로젝트에 연결하는 방법을 보여주는 예시로 시작되었습니다. 그 후 Unreal 통합은 게임과 함께 패키징할 때 Unreal 엔진의 제한에 대응하여 기본 작업 과정(Wwise 2019.2와 Wwise 2021.1에서의 Legacy 작업 과정)을 제공하기 시작했습니다.
Wwise 2019.2까지 통합 코드는 4개의 다른 부분으로 정의되었습니다.
- Wwise 사운드 엔진
- Unreal 엔진
- Wwise Unreal 통합
- 게임 코드
Wwise Unreal 통합 코드가 게임의 통합이나 예상된 작동 방식과 일치하지 않을 때마다 이에 대한 답변은 '스스로 수정할 수 있습니다. 제공된 코드는 단순히 예시일 뿐입니다'였습니다. 약간의 복잡성이 숨겨진 코드 구간이 있었지만 여전히 비교적 이해하기 쉬운 것으로 간주되었죠.
Wwise 2019.2에서 Event-Based Packaging이 시작되면서 Wwise Unreal 통합 코드가 굉장히 복잡해졌습니다. Unreal Editor에서 실행되는 처리, Wwise Authoring과 네트워크를 통한 연결, 작업 과정 복잡성, 메모리 관리, 에셋 관리 및 처리, 에셋 복사, 광범위한 마이그레이션 단계와 같은 요소들이 '단순히' Wwise를 Unreal에 통합하는 데 필요한 작업량을 높였습니다. 이 시점에서 Wwise Unreal 통합을 더 이상 단순한 중간 다리나 예시로 간주할 수가 없었죠.
과거를 돌아보면 이는 Wwise 사용자들의 사고 방식에 근본적인 변화를 가져왔습니다. 개발자들이 고유한 파이프라인 특정 문제를 스스로 해결하도록 저희가 간단한 솔루션을 제공하는 대신, 그들이 Wwise Unreal 통합을 시작할 때 즉시 지원을 요청하기 시작했죠. 이 기간 동안 저희는 유능한 많은 개발자들과 협력하여 복잡성이 증가한 작업 과정을 지원했습니다. 내부적으로는 당시의 제약 내에서 작업하려는 시도로 인한 도전 과제가 보이기 시작했죠.
저희는 기존의 네 가지 기본 핵심 요소에 의존하는 대신 'Wwise Unreal 통합으로의 User Extension'이라는 다섯 번째를 추가해야 했습니다. 이는 게임 코드 자체의 일부이기 보다는 팀이 안에 있는 코드를 변경하지 않고 아주 하위 레벨에서 Wwise Unreal 통합의 작동 방식을 변경하고 확장할 수 있는 방법입니다. 이를 위해 저희는 코드 가독성에 집중해야 했습니다. Unreal Coding Standards(언리얼 코딩 표준)부터 시작하여 코드를 논리적인 부분으로 나눠서 명확하고 간결한 제작 요소를 만들어야 했죠. 마지막으로, 저희는 코드를 다른 시각으로 바라보기 시작했습니다. 주어진 요소를 문서에서 어떻게 설명할 수 있을까요? 코드 자체만으로 설명이 될 뿐만이 아니라 코드가 간단하게 설명되어야 할 것입니다.
수천 개의 외부 프로젝트에 의해 사용된 수십 년 간의 코드를 변경하는 것은 쉬운 일이 아니었지만 현재 시점에서 꼭 필요한 작업이었죠. 그래서 Wwise 2022.1에서부터 저희는 사용자 대면 코드는 거의 변경하지 않고 복원 과정을 시작하고 있습니다. 에셋 정의는 대부분 내부적으로 변경되었죠. 현재 Audio Device라고 불리는 곳에서 몇 가지 함수가 제거되었는데, 지난 몇 년 동안 개발자들이 접근할 수 있는 작업 목록의 절반이 이 Audio Device 안에 있었습니다. 여기서부터 저희는 하위 레벨 코드를 사용자가 변경할 수 있는 모듈로 작성하기 시작했습니다. 이러한 모듈은 변경과 미래 확장성에 대한 접근성을 제공합니다..
이 겸손한 첫 걸음을 시작으로 Wwise Unreal 통합의 다양한 영역에서 제공되는 기능 요약을 살펴보겠습니다.
이제 개발자들이 접근할 수 있는 여러 개의 하위 레벨 모듈이 제공되며, 각 모듈은 확장 가능합니다 (최하위 레벨에서부터).
- Wwise Sound Engine: 대부분의 SoundEngine API 작업에 대한 하위 레벨 접근입니다. 이전에는 AkAudio 외부의 코드에 접근하는 것이 불가능했습니다. API가 동일한 동적 라이브버리에서 접근되어야 했기 때문이죠. 이제 이 모듈을 통해 AkAudio 외부 코드에 직접적이고 안전하게 접근할 수 있습니다.
- File Handler: Unreal 엔진과 Wwise 사운드 엔진 간의 런타임 파일 브릿지입니다. 두 엔진 모두를 만족시키려고 노력하죠. Wwise 스트리밍 I/O Hook, SoundBank 로딩 관리자, Media 로딩 관리자를 포함합니다. 또한 External Source를 사용하려는 게임에서 구현해야 하는 External Sources 관리자 스텁도 들어 있습니다.
- Resource Loader: 각 Wwise 에셋 타입에는 해당 에셋을 로드하는 데 필요한 Load Data 구조체가 있습니다. 상위 레벨 컴포넌트가 요청하면 Resource Loader 모듈은 File Handling 모듈에 대한 필요한 내용을 열거하고 언로딩시 다시 처리합니다. 마찬가지로 선택적인 Switch Container 최적화도 처리합니다.
- Project Database: Unreal Editor 안에서 사용하도록 Wwise 프로젝트의 정보를 로드합니다. Event, Aux Bus의 목록, Switch, State 등 Wwise 프로젝트에서 제공하는 모든 데이터 지점의 목록을 포함합니다.
- Resource Cooker: 에셋 정보를 검색하여 앞서 언급한 Load Data 구조체를 생성하고, Wwise Generated SoundBank 바이너리 파일을 패키징 중에 준비하여 Resource Loader 및 File Handler에서 사용할 수 있도록 합니다.
이 모듈은 기존의 AkAudio 와 AudiokineticTools 모듈과 함께 Wwise Plug-in 안에 추가됩니다 .
저희 통합 코드는 이제 Wwise를 게임 엔진과 통합할 때 개발자들이 종합적인 결정을 내릴 수 있도록 여러 가지 접근 방식을 거쳐왔습니다. 초기 예시에서부터 사용자가 무한히 수정할 수 있는 코드로, 그리고 단일 작업 과정으로 제한된 시스템으로, 사용자 커뮤니티에서 요청한 다양한 작업 과정을 활성화하는 방식까지 말이죠.
작업 과정 간소화: SSOT 및 패키징
Wwise 2022.1의 Unreal 통합에서는 개발자와 사운드 디자이너들이 개발 과정에서 효율적으로 작업할 수 있도록 명확한 통합 경로를 제공해드리고 싶었습니다. 안정적이고 확장 가능하며 가독성 있는 코드를 통해 개발자들이 고유한 파이프라인과 작업 과정에 적합한대로 복잡한 선택 없이 경계를 넓힐 수 있는 데 힘이 되기를 바랍니다.
Wwise Unreal 통합 배경
Wwise 2019.2와 2021.1에서 Wwise 에셋은 다른 위치에 있습니다. 먼저 Wwise 프로젝트 자체에 있었지만, 그 후 보호된 Content 폴더 내에서 Unreal Asset으로 복제되었죠. 또한 Wwise와 Unreal 간의 변경 사항은 Wwise Authoring API (WAAPI)를 사용하여 동기화되거나 Wwise Work Unit에서 파싱되어 Wwise 프로젝트 파일에 접근하는 의존성을 만듭니다. 모든 정보가 다른 곳에서는 접근할 수 없기 때문입니다.
이러한 다양한 음원의 중첩은 특히 Unreal Editor가 닫힌 상태에서 내용이 변경될 경우 문제를 일으킬 수 있습니다. 로딩시 에셋의 우선 순위와 동기화는 제작 및 편집 중 불필요한 지연과 불확실성을 초래합니다. Wwise에서 한 루트 폴더의 이름을 변경하는 간단한 작업만으로도 엔진 간에 수천 개의 이름 변경 작업이 발생하여 각각 몇 초의 시간을 소모할 수 있죠.
실제로 많은 사람들은 이 방법론이 소규모 프로젝트에 편리하다고 생각하지만 대규모 프로젝트에서는 '단순함'을 위해 지불하기에는 높은 비용입니다.
이러한 에셋을 최종 제품으로 쿠킹할 때 Wwise Unreal 통합의 첫 번째 버전에서는 사용자가 항상 SoundBank와 Media 파일을 포함하는 폴더를 추가해야 했습니다. 불행히도 이 폴더에는 게임 크기를 증가시키는 보충 메타데이터 파일도 포함되어 있었으며, 악의적인 사용자들이 해킹하기 더욱 쉬워질 가능성도 있었죠.
Wwise 2019.2부터는 Legacy 작업 과정을 사용하지 않는 한 이러한 Wwise 에셋이 대량의 바이너리 데이터로서 필수 Unreal 에셋으로 묶이게 됩니다. 이 방법이 기능적이더라도 원칙적으로는 1:1 Unreal 에셋당 Media/Bank 에셋이 필요합니다. 또한 Unreal과 해당 에셋 수명 주기에 의존해야 하기 때문에 열악한 상황이죠.
Single Source of Truth (단일 진실 공급원, SSOT)
Wwise 에셋과 프로젝트 데이터 베이스는 Generated SoundBanks 폴더라는 한 곳에 배치됩니다. 바로 이 곳이 이제 Single Source Of Truth(단일 진실 공급원, SSOT)가 되죠. 생성된 바이너리 파일과 Wwise 프로젝트 및 해당 출력을 이해하는 데 필요한 모든 정보가 담긴 생성된 JSON 파일이 여기에 있습니다. Unreal 에셋은 이제 선택 사항이며 어떤 Wwise 에셋이 참조되는지를 알 수 있는 식별 데이터만 포함하게 됩니다.
Wwise Picker는 이제 Wwise Project가 아닌 Generated SoundBanks 폴더와 연결됩니다. Legacy 작업 과정의 경우 Unreal Editor에서 재생되는 내용이 Generated SoundBanks 폴더나 Event-Based Packaging 작업 과정의 일부로서 UObject 안에 있었습니다. 이러한 상황에서 Wwise Picker를 통해 표시된 것은 이전에 Wwise 프로젝트에 저장된 내용인 또 다른 반쪽자리 진실 공급원이었죠. Source Control에서 정보를 가져올 경우 Generated SoundBanks 폴더 안에 있는 내용과 동등한 경우가 많지만 이 가정을 확인할 수 있는 방법이 없었습니다. 이제는 Wwise 프로젝트가 통합에 의해 완전히 무시되며 Generated SoundBanks 폴더만 Wwise Picker에 의해 사용됩니다.
WAAPI Picker는 이제 Wwise 프로젝트의 뷰포트 역할만 하게 됩니다. Wwise에 의해 생되고 Generated SoundBanks 폴더에 배치된 에셋 및 미디어가 이제 프로젝트의 '진실'을 나타냅니다. 이러한 에셋이 Unreal 통합의 일부로서 표시되며 재생됩니다. 하지만 편의를 위해 여전히 Unreal Editor에서 WAAPI Picker를 사용하여 Authoring에서 Wwise 프로젝트와의 작업을 처리할 수 있습니다. 이것이 '진실'은 아니지만 편의를 위해 제공되죠. Wwise Authoring 변경을 에디터로 가져오려면 반드시 뱅크를 재생성해야 합니다.
Sound Designer는 Wwise에 대해 알지만 모든 개발자가 이에 대해 알 필요는 없습니다. Wwise Authoring을 설치하고 Wwise 프로젝트 전체에 접근하는 편리함은 좋지만 모든 프로젝트의 개발자가 Wwise에 대해 알아야 하거나 이를 설치해야 할 필요는 없습니다. 이제 Wwise 2022.1 작업 과정은 Wwise Authoring이나 게임에 대한 전체 Wwise 프로젝트 없이도 Wwise가 포함된 Unreal 프로젝트의 일부로 개발할 수 있도록 최적화되었습니다. 이제 Wwise Unreal 통합과 (해당 Sound Engine SDK도 함께) Generated SoundBanks 폴더만 필요하며, 이는 간편하게 이동할 수 있습니다. 이로 인해 Generated SoundBanks 폴더는 더 이상 Unreal 프로젝트의 Content 폴더 안에 있을 필요가 없으며 원하는 위치로 옮길 수 있습니다.
Wwise 바이너리 에셋이 트리 쉐이킹되어 필요한 파일만 패키징된 프로젝트 안에 복사됩니다. Wwise 2022.1에서는 Legacy 시스템으로 돌아가서 에셋이 런타임에 소비되도록 루즈 파일로서 복사됩니다. 이 시스템은 Unreal 에셋의 수명에 구속받지 않는 최상의 방법입니다. 하지만 또한 저희는 Event-Based Packaging 시스템에서 사용할 파일을 Unreal Asset 사용에 따라 스테이징하는 방법을 배웠습니다. 이 플러그인은 Ak Component를 사용하여 최종 스테이징에 사용되는 항목을 결정하여 일반 Unreal 에셋을 사용하는 제품에서 매끄럽게 작동됩니다. 마지막으로 이제 이러한 작업을 오버라이드할 수 있기 때문에, 개발자들이 전체 통합 코드를 다시 작성할 필요 없이 필요한 경우 파일을 다르게 처리하거나 파일의 여러 버전을 자체적으로 제어할 수 있는 특별 작업을 수행할 수 있습니다.
Wwise Authoring은 디자인 도구입니다
과거 몇 년 동안 Unreal 통합은 기본적으로 Wwise Authoring 안에서 SoundBank Generation을 우회하는 작업 과정을 제안해왔습니다. 여전히 오늘날에도 이 방법이 프로젝트에 적합한 이유는 여러 가지가 있죠. Authoring은 초기에 단일한 SoundBank들을 포함하는 폴더를 통해 파일을 제공하도록 개발되었지만 더 빠른 저장 공간 접근과 디스크 드라이브에서 솔리드 스테이트로로 옮겨오면서 이제 일반적으로 미디어에 대한 더 나은 랜덤화된 접근을 지원합니다. SoundBank를 통해 프로젝트에 정보를 제공하는 것은 복잡한 복잡한 프로젝트를 처리하기 위해 여전히 가장 효율적인 방법이지만, 전반적인 업계에서는 파이프라인의 일부로 독립적인 필요에 따른(on-demand) 에셋을 요청하기 시작했습니다. 이에 대한 저희도 Event-Based Packaging을 첫 단계로 하여 Authoring을 Unreal 사용자들로부터 점점 더 분리하기 시작했죠.
하지만 사운드 디자이너를 위한 별도의 특화된 도구를 갖는 개념과 이상은 효율성뿐만 아니라 간소함에 대해서도 여전히 유효합니다. 3D 아티스트가 별도의 도구로 3D 에셋을 그리고 유지하는 것처럼 게임 오디오도 게임 자체와 병렬로 개발할 수 있게 해주기 때문이죠. 이 개념의 장점은 여러 버전을 거치며 서서히 무너졌고 재고와 우선 순위 재조정이 필요했습니다.
Wwise 2022.1에서는 이제 Auto Defined SoundBank를 Wwise Authoring 안에서 직접 제공합니다. 이 옵션을 사용하면 Wwise Event의 일부 혹은 전부 독립적인 SoundBank로 정의할 수 있습니다. 이를 통해 Event-Based Packaging의 강력함을 커스텀 통합뿐만 아니라 Unreal로 가져올 수 있으며, 어떤 게임 엔진에서든 Event-based Soundbank와 해당 미디어에 대한 세밀한 관리가 간소화됩니다.
이 근본적인 변경으로 인해 Unreal 작업 과정이 예전 방식으로 돌아가게 되었습니다. 이전 작업 과정을 제거하고 사운드 디자이너가 SoundBank를 관리하기 위해 Wwise Authoring을 사용하는 개념으로 돌아갔죠.
이제 저희는 이전에 잊고 있던 두 가지 유형의 개발자들을 대상으로 합니다.
- Wwise를 전혀 사용하지 않는 개발자 (Game Play, AI, GFX, 3D)
- Wwise만 사용하며 Unreal Editor가 전혀 필요 없는 사운드 디자이너
이를 통해 Wwise 안에서 에셋 크기와 메모리 사용을 관리해야 하는 책임이 다시 사운드 디자이너에게로 돌아갔습니다. 이전 버전의 Wwise Unreal 통합에서는 누락된 내용이었죠. SoundBank 생성 정보 패널에 이제 접근할 수 있기 때문에 특히 작은 플랫폼에서 게임의 리소스 요구 사항에 맞추기가 더 쉽습니다.
나머지 작업 과정은 Event-Based Packaging을 기꺼이 받아들이고 개발 도중 Unreal Editor와 Wwise Authoring을 상호 교환하며 작업하는 테크니컬 사운드 디자이너에게 집중합니다. Wwise와 Unreal을 번갈아가며 사용하는 사람들에게 이 새로운 작업 과정은 속도와 일관성이라는 두 가지를 측면을 가져다 줍니다. Wwise와 Unreal 간의 동기화를 지속적으로 유지할 필요를 제거했으며 정확히 언제 동기화가 필요한지를 이제 알게 되었습니다. 이로 인해 몇 시간의 지연이 필요한 작업(예: 앞서 언급한 루트 폴더 이름 변경 작업)을 발생시키지 않고 작업할 수 있습니다.
Unreal과 다른 게임 혹은 미들웨어용 오디오 개발 간에 작업 과정 차이가 없습니다. 이제 사운드 디자이너는 직접 Wwise Authoring에서 게임을 위한 최상의 오디오 경험을 제작하는 데 집중할 수 있습니다. Unreal 엔진으로 게임을 개발한다고 해서 특별한 기능이나 에셋을 관리할 필요가 없습니다.
Wwise Project 폴더는 Unreal Editor에서 작업하는 데 필요하지 않습니다. SoundBank를 별도의 폴더에서 직접 생성할 수 있기 때문에 이것이 최종 게임에 오디오를 포함시키는 데 필요한 유일한 요구 사항이 되었습니다. SoundBank가 Wwise에서 올바르게 생성되기만 하면 게임을 패키징하기 위한 별도의 작업이 필요하지 않습니다.
Unreal 프로젝트에서 Commandlet을 관리하기 위한 야간 작업이 없습니다. 이 작업은 때때로 사운드 디자이너가 변경 작업을 할 경우 Unreal의 Asset 변경이 거대해지기 때문에 필요한 작업이었습니다. 이제는 SoundBank Generation이 사운드 디자이너 컴퓨터에서 직접 이뤄지거나 서버에서 오토메이션될 수 있기 때문에 Generated SoundBanks 폴더만 변경됩니다. 마찬가지로 팀 간 공유를 위해 Wwise 프로젝트의 Cache 폴더를 소스 컨트롤에 공유해야 할 필요가 적어졌습니다. 왜냐하면 이제 사운드 디자이너가 Wwise 프로젝트에서의 출력을 독점적으로 제어하기 때문이죠.
시험 가능
Wwise와 Unreal 엔진 모두 어마어마한 양의 커스터마이징을 허용합니다. Audiokinetic에 전문적이고 경험이 풍부하며 숙련된 품질 보증팀이 있는 것은 사실이지만 개발자들이 Wwise로 할 수 있는 모든 경로의 품질을 보증하기란 불가능합니다. 대부분의 소프트웨어는 천 개의 오디오 에셋으로 충분할 수 있지만 일부 소프트웨어는 백만 개가 넘어가는 오디오 에셋이 포함되어 있죠. 뿐만 아니라 일부는 플랫폼 제약으로 인해 모든 것을 재생하지 못할 수 있고, 12개 이상의 언어를 포함하고 있을 수도 있으며, 여전히 스트리밍 미디어의 한계를 뛰어넘을 수도 있습니다. 또한 단일한 Event가 1만개의 선택적인 오디오를 포함할 수도 있고, 맵을 동적으로 스트리밍할 수도 있으며, 다른 누구도 사용하지 않는 난해한 Unreal 기능을 사용하고 있을 수도 있죠. 또한 특정 요구에 맞게 Audiokinetic 코드와 Unreal을 확장하고 수정하는 멋진 팀들도 있습니다. 상대적으로 규모가 큰 팀들은 Unreal 엔진의 자체적인 커스텀 버전을 생성하는 경우가 많아 직접 커스텀 코드로 여러 버전을 병합해야 하기 때문에 특정 Unreal 버전을 지원하는 것도 일반적이지 않습니다.
이제 저희는 시험을 거친 중간 지점에 집중하려고 하고 있지만 고유한 제작을 위해 Wwise Unreal 통합을 다운로드하는 팀이 저희가 전혀 상상해보지 못하며 시험해보지 못한 극단적 상황에 부딪힐 수 있다는 것을 알죠.
이 첫 번째 버전의 Wwise 2022.1 Unreal 통합은 한 걸음 물러난 동시에 큰 발전을 가져다줍니다. 초기 최적화가 올바른 코드와 완전히 적대적이라는 것을 모두 알고 있지만, 저희는 대부분의 게임에서 만족할 만한 합리적인 최적화 수준을 유지하고 있습니다. 과거에 복잡한 코드 경로로 인해 부담을 받았던 모든 것들이 단순화되었죠. 로그가 추가되었으며 코드 품질이 향상화되습니다.
도구 및 프레임워크
또한 저희는 전체 Wwise Unreal 통합을 더욱 쉽게 테스트할 수 있도록 기본 도구와 프레임워크를 개발하기 시작했습니다. 모든 내용을 즉시 제공해드릴 수는 없지만 완전히 테스트할 수 있는 Wwise Unreal 통합에 대한 약속은 여러 해동안 지속될 것입니다. 이 방향을 위한 첫 번째 단계는 Gyms의 개발입니다.
이 외부 프로젝트의 목표는 다음과 같습니다.
- Wwise 프로젝트, Unreal 프로젝트, Unity 프로젝트가 포함된 제품.
- 각 맵에 관한 단일 개념을 쉽고 효율적으로 설명하는 여러 개의 작은 맵을 가지고 있음. 사용자가 따라해볼 수 있는 예시.
- 각 작은 맵마다 극단적인 상황과 함께 긍정적/부정적 통합을 단위 테스트하기 위한 연결된 코드 부분들이 있음. 이 모든 것들이 미들웨어에서 선호하는 단위 테스팅 체계를 사용함.
- 외부 개발자가 접근할 수 있음. 따라서 개발자가 커스터마이징된 흐름을 테스트하고 추가 반복 작업을 위해 재현 사례를 맵으로 공유할 수 있음.
저희는 Gyms를 서드 파티 저장소를 통해 접근 가능하게 하고 Wwise 2022.1부터 관리할 예정입니다.
그 외에도 하위 레벨 모듈의 확장성 디자인 자체를 포함한 테스팅을 위한 여러 개선 사항이 예정되어 있습니다. 다음 메이저 버전부터 이러한 단위 테스트 모듈을 제공하여 개발자들이 이해하기 쉬운 방법을 사용하여 자체적인 엔진 변경 사항을 시험할 수 있기를 바랍니다.
결론
Wwise는 10년 전과는 전혀 다릅니다. Unreal 엔진 또한 지난 몇 년간 굉장히 발전되었죠. 단순히 호환성을 유지하고 몇 가지 기능을 추가하는 것만으로는 뒤쳐질 수 밖에 없을 것입니다. 개발자가 사용하기 좋은 제품을 만들어내야 하죠. 수년 간 Wwise 통합을 사용하는 팀들은 저희가 성능, 안정성, 기능 면에서 최고의 제품을 만들 수 있도록 힘을 실어달라고 요청해왔습니다.
이 첫 번째 글에서는 Audiokinetic의 사고 방식 전환과 이 변화에 수반된 높은 요구 사항을 다루었습니다. '우선 순위는 무엇이고 이 순위를 어떻게 지킬 수 있는가'라는 질문을 통해 Audiokinetic 내에서 통합을 바라보는 방식을 바꾸는 과정을 시작했죠. 이는 Wwise를 Unreal에 맞게 적응시키고 처음부터 강력한 기반을 다시 구축하는 것을 의미했습니다.
이제 Wwise 통합 2022.1을 통해 Audiokineitc은 개발자와 사운드 디자이너 모두가 성공적인 작업을 만들 때 도움이 되는 새로운 현대적 시스템의 기반을 마련하고 있습니다. 이 안정적인 기반은 이전 제품과의 호환성을 유지하면서도 미래의 도전에 대응할 수 있을만큼 현대적일 것입니다.
댓글