Jak się robi muzykę do gier

Pisanie muzyki do gry wymaga trochę innych umiejętności niż komponowanie utworu, muzyki filmowej, ścieżki do trailera czy motywu do menu. Mówimy o muzyce, która reaguje na działania gracza, zmienia się wraz z sytuacją, przechodzi między stanami gry.

To jest tekst dla tych, którzy z produkcją audio do gier nie mieli styczności. Chcę pokazać w najszerszym zarysie, jak wygląda praca i jakich typów  narzędzi używa branża.

Dobrym sposobem myślenia o muzyce gameplayowej jest traktowanie jej jak serii mikrosoundtracków do małych scenariuszy. Osobny miniscenariusz dotyczy np. eksploracji opuszczonego budynku, skradania się obok przeciwników, narastającego zagrożenia, rozpoczęcia walki, zwycięstwa, porażki albo powrotu do spokojniejszego stanu. W grze sposób odtwarzania muzyki jest mało przewidywalny. Gracz może zatrzymać się w miejscu, wrócić do poprzedniej lokacji, wejść do walki wcześniej niż zakładano, unikać konfrontacji albo powtarzać tę samą sekwencję kilka razy. Przygotowując muzykę, trzeba brać pod uwagę wszystkie te warianty.

RÓŻNE GATUNKI, RÓŻNE PODEJŚCIE DO MUZYKI

Nie każda gra potrzebuje takiego samego systemu muzycznego. Inaczej tworzy się muzykę do shootera, skradanki, horroru, RPG czy strategii, ale najważniejsze jest nie samo określenie gatunku, ale zachowanie gracza i tempo zmian w rozgrywce. W grach akcji muzyka powinna reagować szybko: eksploracja może przechodzić w napięcie, walka w zwycięstwo lub porażkę. Dlatego często stosuje się warstwy intensywności, dodatkowe rytmy, perkusję, bas i krótkie akcenty. W skradankach muzyka informuje gracza, czy jest bezpieczny, podejrzewany, wykryty albo ścigany. Ważne są subtelne przejścia, narastające napięcie i miejsce dla dźwięków otoczenia. W horrorze muzyka korzysta z ciszy, dronów, szumu i drobnych zmian barwy. Ma budować oczekiwanie, nie zaś stale komentować akcję, dlatego przydają się warianty i losowość. W RPG i otwartych światach problemem jest powtarzalność, w strategiach natomiast muzyka reaguje wolniej, wspierając koncentrację i długofalowy „feeling” rozgrywki. Komponowanie muzyki gameplayowej zaczyna się więc od analizy działań gracza, a dopiero później przechodzi się do wyboru rozwiązań technicznych.

PO PIERWSZE WARSZTAT

Komponowanie jest jednocześnie pracą muzyczną i projektową. Kompozytor nie tworzy wyłącznie gotowego nagrania, ale projektuje system muzycznych zachowań: pętle, warstwy, przejścia, warianty, parametry i reakcje na zdarzenia w grze. W praktyce oznacza to pracę bliższą budowaniu interaktywnej struktury niż napisaniu linearnego utworu. Oczywiście każdy deweloper i każde studio mogą pracować trochę inaczej. Różne są silniki, narzędzia, budżety, procesy, podział obowiązków między kompozytorem, sound designerem, audio directorem a programistą. Jedne zespoły korzystają ze środowiska pracy FMOD, inne z Wwise, jeszcze inne budują własne systemy audio bez dodatkowego middleware’u (oprogramowania integrującego różne środowiska). Mimo tych różnic główna zasada pozostaje podobna: muzykę trzeba przygotować tak, aby mogła być sterowana przez rozgrywkę, a nie tylko odtwarzana obok niej. W tym tekście oprzemy się na organizacji pracy z FMOD, popularnym narzędziem pośredniczącym między programem do audio a silnikiem gry. Nie oznacza to jednak, że opisana filozofia dotyczy wyłącznie FMOD. Podobne myślenie pojawia się w bardzo popularnym Wwise, autorskich systemach audio i narzędziach budowanych bezpośrednio w środowiska robocze Unity czy Unreal Engine. Różnią się nazwy funkcji i szczegóły implementacji, ale podstawowa zasada pozostaje ta sama: muzyka do gameplayu musi zostać zaprojektowana jako system, którym gra może sterować.

OD KOMPOZYCJI DO IMPLEMENTACJI 

Podstawową jednostką pracy jest event, czyli „pojemnik” z muzyką w różnych wariantach, który kod gry może uruchomić, kontrolować i zatrzymać. Event może zawierać pliki audio, logikę ścieżki czasu, warstwy, instrumenty, automatyzację i parametry. FMOD traktuje parametry jako zmienne pozwalające kontrolować projekt; kod gry może ustawiać ich wartości.

NARZĘDZIA AUDIO

W świecie deweloperów istnieje wiele rodzajów narzędzi do pracy z audio. Pierwsze to pełne middleware audio, czyli oprogramowanie pośredniczące między silnikiem gry a dźwiękiem. Takie narzędzia pozwalają przygotować muzykę i efekty w osobnym programie, a potem sterować nimi w grze. Oprócz FMOD i Wwise najważniejszym narzędziem jest CRI ADX/CRIWARE, szczególnie mocny w produkcjach japońskich i konsolowych. 

Historycznie ważny jest też Miles Sound System, dziś kojarzony raczej jako część historii branży. Elias warto znać przy muzyce adaptacyjnej, czyli takiej, która zmienia się zależnie od sytuacji w grze. Fabric to z kolei lżejsze rozwiązanie związane głównie z Unity. Druga grupa to narzędzia do spatial audio, czyli dźwięku przestrzennego. Ważne są zwłaszcza w VR i AR, czyli wirtualnej i rozszerzonej rzeczywistości. Tu pojawiają się Steam Audio, Meta XR Audio SDK i Resonance Audio. Nie są one pełnym zamiennikiem Wwise czy FMOD, ale specjalizują się w pozycjonowaniu dźwięku, symulowaniu akustyki pomieszczeń i tworzeniu wrażenia, że dźwięk naprawdę dochodzi z określonego miejsca w przestrzeni. Trzecia grupa to systemy wbudowane w silniki gier: Unreal Audio i MetaSounds w Unreal Engine, Unity Audio Mixer i DSPGraph w Unity oraz Godot Audio Buses w Godot. Ostatnia grupa to lżejsze, bardziej programistyczne biblioteki: miniaudio, SoLoud, SDL_mixer, OpenAL Soft i BASS. Są przydatne zwłaszcza w małych projektach albo własnych silnikach. Dają kontrolę nad odtwarzaniem i miksowaniem dźwięku, ale zwykle nie oferują wygodnego programu do pracy dla kompozytora czy sound designera.

PIERWSZY ETAP: ZROZUMIENIE SCENY

Kompozytor, audio director albo sound designer analizują fragment gameplayu: build gry, nagranie wideo, opis poziomu, dokument projektowy albo rozmowę z projektantem. Celem nie jest jeszcze odpowiedź na pytanie „jaka ma być muzyka?”, ale raczej „jakie sytuacje mogą tu wystąpić?”. Na tym etapie pojawiają się bardzo konkretne pytania, na przykład:

• Czy gracz może długo przebywać w tej lokacji?

• Czy scena ma wyraźny początek i koniec?

• Czy walka zaczyna się natychmiast czy napięcie narasta wcześniej?

• Czy gra wie, kiedy przeciwnik zauważył gracza?

• Czy muzyka ma reagować płynnie czy przełączać się między konkretnymi stanami?

Dopiero odpowiedzi na te pytania pozwalają określić strukturę muzyki. Przykładowy fragment gry może wymagać czterech podstawowych stanów muzycznych: eksploracja: spokojna pętla bazowa, napięcie: dodatkowe warstwy, mniej melodii, więcej pulsu i niepokoju, walka: mocniejszy rytm, większa gęstość, wyraźniejszy bas lub perkusja, powrót po walce: wyciszenie, krótki łącznik albo wersja eksploracji z innym stanem emocjonalnym. 

PROJEKT MUZYCZNY: CO GRA MA POWIEDZIEĆ MUZYCE

Kolejny etap to ustalenie, jakie informacje gra może przekazać do systemu audio. Robimy to przez znane nam już eventy i parametry.
Przykładowo, zamiast przygotowywać osobne pliki: eksloracja.wav, walka.wav, zagrożenie.wav, zwycięstwo. wav, można przygotować jeden event muzyczny, na przykład: Muzyka_Poziom_1 Wewnątrz tego eventu muzyka może mieć kilka warstw i sekcji, a gra steruje nimi za pomocą parametrów, takich jak: - poziom napięcia, na przykład od 0 do 100, - stan walki: brak walki, zagrożenie, aktywna walka, boss, - zdrowie gracza, które może wpływać na filtr, puls albo dodatkową warstwę, - informacja czy gracz został zauważony, - aktualna część lokacji. Ten etap jest bardzo ważny, bo pokazuje granicę między kompozycją a implementacją. Kompozytor może wymyślić, że muzyka ma narastać wraz z niebezpieczeństwem, ale gra musi mieć sposób, żeby to niebezpieczeństwo zmierzyć i przekazać do FMOD. Jeżeli gameplay nie daje takiej informacji, trzeba uprościć system albo dodać odpowiedni parametr. W dobrze działającym zespole powstaje więc rodzaj małego projektu muzyczno-technicznego. Dokumentacja projektowa nie musi być bardzo rozbudowana, ale powinna zawierać przynajmniej: nazwy eventów, listę parametrów, zakresy wartości, opis stanów muzycznych, informację kiedy gra uruchamia i zatrzymuje event, zasady przejść między sekcjami, wymagania dotyczące loopów i ścieżek (stemów). Dopiero wtedy kompozytor może zacząć pisać materiał.

KOMPONOWANIE MATERIAŁU: PĘTLE, WARSTWY I SEGMENTY

Kiedy wiadomo już, jak muzyka ma zachowywać się w grze, można przejść do komponowania. Ten etap odbywa się najczęściej w DAW-ie: Reaperze, Cubase, Logic Pro, Abletonie, Pro Toolsie albo innym narzędziu. Niektórzy twórcy oczywiście wolą partytury i nagrywanie żywych instrumentów, ale obróbka i tak odbywa się w DAW-ie. Niezależnie od procesu, kompozytor od początku pisze muzykę z myślą o późniejszym rozłożeniu jej na elementy. Najważniejsze są trzy pojęcia: pętla, warstwa i segment. Pętla musi działać przez dłuższy czas bez irytowania gracza. To oznacza, że nie zawsze powinna mieć bardzo mocną melodię. Czasem lepiej sprawdzają się ambienty, tekstury, puls, prosty motyw rytmiczny albo harmonia, która może „oddychać” przez kilka minut. Warstwa to element, który można dodać lub zdjąć bez niszczenia całości. Na przykład eksploracyjna baza może składać się z ambientu i delikatnego pulsu. Przy większym napięciu dochodzi niski dron. Przy walce dochodzi perkusja, bas i agresywna warstwa syntezatorów. Wszystkie te elementy muszą być zgodne rytmicznie, harmonicznie i technicznie. Segment to większy fragment muzyczny: eksploracja, napięcie, walka, boss fight, outro po walce. Segmenty mogą być osobnymi częściami ścieżki czasu albo osobnymi eventami, zależnie od przyjętej struktury. To nie są jeszcze ostateczne „utwory”. To części systemu. Bardzo ważne jest, aby pliki były przygotowane precyzyjnie. Wszystkie ścieżki powinny mieć ten sam punkt startu, tę samą długość, tempo i przestrzeń. Jeżeli warstwa perkusji zaczyna się kilka milisekund za późno albo pad ma źle ucięty pogłos, problem może być niewidoczny w DAW-ie, ale stanie się słyszalny po implementacji.

PIERWSZA IMPLEMENTACJA W FMOD 

W FMOD kompozytor lub sound designer tworzy event, importuje stemsy i układa je na timelinie albo w polach parametrów. Następnie definiuje logikę: które warstwy grają zawsze, które pojawiają się przy określonej wartości określonego parametru, które mają się zapętlać, które są jednorazowymi akcentami, a które pełnią funkcję przejść. Nasz przykładowy event Muzyka_Poziom_1 może działać następująco: 
przy Intensity = 0-25 gra tylko warstwa ambientowa i lekki puls, przy Intensity = 25-50 dochodzi ciemniejszy ton syntezatora, przy Intensity = 50-75 pojawia się rytmiczna warstwa powodująca wzrost napięcia, przy Intensity = 75-100 wchodzą elementy walki: perkusja, bas i agresywniejsza harmonia. Gdy CombatState zmienia się na Boss, timeline przechodzi do osobnego regionu z inną dramaturgią. Gdy walka się kończy, system nie ucina muzyki od razu, tylko przechodzi przez przygotowany fragment wygaszający Gra nie musi odtwarzać wielu plików i pilnować każdego przejścia czy wyciszenia. Może ustawiać parametry, a FMOD interpretuje je według logiki zapisanej w evencie. Dokumentacja FMOD opisuje eventy jako jednostki dźwiękowe wyzwalane i kontrolowane z kodu gry, a banki jako kolekcje eventów i plików audio przygotowane do użycia w grze. 

BUDOWANIE BANKÓW I PODŁĄCZENIE DO GRY

Sama implementacja w FMOD Studio nie wystarczy. Żeby gra mogła używać przygotowanych eventów, projekt FMOD trzeba ułożyć w banki. Banki są paczkami zawierającymi eventy i pliki audio w formie przygotowanej do użycia przez grę. Po zbudowaniu banków gra może je ładować i odtwarzać eventy, na przykład przez integrację z Unity, integrację z Unreal Engine albo bezpośrednio przez API FMOD. Na tym etapie praca zwykle przechodzi z FMOD Studio do silnika gry. Programista, technical sound designer albo audio implementer podpina event pod konkretną sytuację: - gdy gracz wchodzi do lokacji, uruchom Music_Forest_Level, - gdy wzrasta zagrożenie, podnieś Intensity, - gdy przeciwnik zauważa gracza, ustaw CombatState, - gdy walka się kończy, obniż Intensity, - gdy gracz ginie, uruchom Death_Stinger, - gdy gracz opuszcza lokację, zatrzymaj event z fade-outem. W teorii brzmi to prosto. W praktyce właśnie tutaj zaczyna się najważniejsza część pracy: iteracja. 

ITERACJE: MUZYKA SPRAWDZANA W GRZE

Muzyka do gameplayu bardzo rzadko działa idealnie po pierwszej implementacji. Nawet jeżeli brzmi świetnie w DAW-ie i zachowuje się poprawnie w FMOD, dopiero gra pokazuje, czy system naprawdę działa. Pierwsze testy często ujawniają problemy, których nie dało się przewidzieć podczas komponowania. Pętla, która w DAW-ie wydawała się subtelna, po dziesięciu minutach eksploracji może stać się męcząca. Przejście do walki może następować za późno, bo gracz już jest w centrum akcji, a muzyka dopiero się rozpędza. Z kolei powrót do eksploracji może następować za szybko, przez co muzyka traci naturalną dramaturgię. Czasem warstwa perkusji brzmi dobrze sama, ale w miksie gry konkuruje z efektami broni, krokami albo dialogiem. Dlatego iteracja nie polega tylko na poprawianiu kompozycji. Często poprawia się cały system.
Możliwe przykładowe zmiany po pierwszym teście: - skrócenie intro, bo gracz szybciej wchodzi w akcję, - dodanie łagodniejszego stanu pośredniego między eksploracją a walką, - zmiana zakresu parametru Intensity, - wolniejsze narastanie warstw, - szybsze wejście perkusji, - dodanie transition stingera, - wyciszenie melodii, która zbyt często się powtarza, - przeniesienie części efektów z plików audio do miksu w FMOD, - zmiana kompresji lub głośności po testach w silniku, - ograniczenie liczby jednocześnie grających warstw ze względów wydajnościowych. Czasem problem nie leży po stronie muzyki, ale po stronie danych z gry. Jeżeli parametr Intensity skacze z 0 do 100 i z powrotem, muzyka będzie reagować nerwowo. Wtedy trzeba wygładzić zmianę parametru, dodać opóźnienia, złagodzić progi wyzwalania albo zmienić logikę po stronie gameplayu. To dobry przykład sytuacji, w której kompozytor, sound designer i programista muszą pracować razem.

TYPOWY CYKL PRACY

W praktyce workflow muzyki do rozgrywki można opisać jako powtarzalny cykl: Brief gameplayowy – zespół ustala, co dzieje się w danej scenie, jakie są emocje, jakie stany rozgrywki i jakie informacje może wysyłać gra. Projekt systemu muzycznego – powstaje plan eventów, parametrów, warstw, segmentów i przejść. Kompozycja w DAW-ie – twórca pisze materiał muzyczny, ale od początku myśli o loopach, stemach, wariantach i modularnej strukturze. Eksport zasobów – ścieżki są eksportowane w jednym tempie, długości i formacie. Przygotowuje się też stingery, przejścia i warianty. Implementacja w FMOD – materiał trafia do eventów. Dodaje się parametry, automatyzację, logikę timeline’u, warstwy, pętle, snapshoty i routing. Build banków – projekt FMOD jest budowany do banków, które gra może załadować i wykorzystać. Integracja w silniku gry – programista lub implementer podpina eventy do konkretnych sytuacji gameplayowych. Test w grze – muzyka jest sprawdzana podczas prawdziwej rozgrywki. Poprawki – zespół zmienia muzykę, parametry, miks, przejścia albo logikę gameplayową. Kolejny test – proces powtarza się aż do momentu, gdy muzyka nie tylko brzmi dobrze, ale też zachowuje się dobrze. Ostatnie rozróżnienie jest kluczowe. W muzyce do gameplayu nie wystarczy, że fragment brzmi dobrze po naciśnięciu „play”. Musi jeszcze dobrze reagować na gracza. To, co warto zapamiętać, to fakt, że praca przy g rze jest zespołowa i wymaga równie wiele talentu, co umiejętności komunikacji z resztą teamu – od programistów do prawników.

Chcesz poczytać więcej? 

• https://www.gamemusic.pl/muzyka-adaptacyjna/
  Przystępny tekst o tym, czym jest muzyka adaptacyjna i jak wpływa na doświadczenie gracza.

• https://dev.epicgames.com/documentation/pl-pl/fortnite/adaptive-music
  Krótkie, polskojęzyczne omówienie muzyki adaptacyjnej w dokumentacji Epic Games, z wyjaśnieniem podejścia poziomego i pionowego.

• https://www.fmod.com/studio/docs
  Oficjalna dokumentacja FMOD Studio: eventy, parametry, banki, integracje z silnikami i podstawy budowania systemów adaptive audio.

• https://www.audiokinetic.com/library/
  Oficjalna dokumentacja Wwise, szczególnie przydatna przy zgłębianiu interactive music, RTPC, przejść, warstw i struktury projektu audio.

• https://game.criware.jp/manual/native/adx2_en/latest/index.html
  Dokumentacja CRIWARE/ADX, czyli middleware’u audio używanego m.in. w produkcjach konsolowych i japońskich.

• https://www.gamedeveloper.com/audio
  Dział serwisu Game Developer poświęcony audio w grach: praktyce produkcyjnej, sound designowi, muzyce adaptacyjnej i narzędziom.

• https://arxiv.org/abs/1907.01154
  Artykuł naukowy „Adaptive Music Composition for Games” o systemach muzycznych, które dynamicznie reagują na działania gracza i kontekst świata gry.