不是嗶嗶聲的音效

我們第一次在沒有檢查音效需求說明的情況下出貨遊戲，是一款港口管理模擬遊戲——起重機、貨船、一個小小的濱海小鎮——結果收集金幣的音效是一個正弦波音。並不是任何人特意選的；一個佔位用的「叮」音效在早期搭建架構時就進去了，之後一直沒被換掉，就像沒人留意的話，一張素材庫照片也會一路留到成品網站上。畫面其實沒問題，手繪的水面、海鷗，日落時分溫馨的小碼頭。但你一撿起一個貨櫃，遊戲就會發出像2007年網頁遊戲倒數計時器結束時的聲音。

我們把成品叫到共用螢幕上，想搞清楚問題出在哪裡，結果只花了大約四秒鐘真正用心聆聽——有人堅持要閉上眼睛聽，半開玩笑地說——全場就一致認同：整個遊戲聽起來就像微波爐。每一個成功提示音、每一個介面提示聲，全都是即時合成的，全都是同一種單薄的電子音色，不管配到哪個遊戲都一樣。一個溫馨的港口小鎮和一款賽博龐克射擊遊戲，會發出一模一樣的聲音。這就是破綻所在。正弦波不知道自己身處哪個世界。

於是我們開始尋找真正的解決辦法，結果那個辦法其實樸實到讓人安心：不再生成音調，而是改為錄製真實樂器。不是從別處授權來的取樣包，也不是調校得聽起來「溫暖」的合成近似音——而是真正的樂器，經過錄音，並在其音域範圍內取樣，讓每個播放出來的音符都是真正由樂手演奏出來的音符。我們花了幾週時間，建立出一個大到難以形容的樂器庫。

除了樂器之外，我們也另外單獨錄製了環境音，因為一個世界需要的是空氣感，而不只是一段配樂：

• 雨聲
• 浪濤聲
• 風聲
• 空間環境音
• 人群的低語聲

我們回頭找出那款港口遊戲，用上實際可用的樂器庫，從零重建了它的音效。碼頭下方的水波拍打聲、麥克風之外某處傳來的海鷗叫聲，而當你成功把貨櫃裝上船時，一支音條敲擊樂器——真正的樂器，錄下真實敲擊音條的聲音——會演奏出過去那個嗶嗶聲所在位置的音符。同樣的音符，遊戲流程裡同樣的時刻，卻是截然不同的遊戲體驗。這個對比正是整個論點的縮影：由馬林巴演奏的一段音效，和由振盪器演奏出完全相同音高的聲音，並不是「做出一個成功音效」這項任務下可以互換的兩種產出。它們是披著相同功能外衣的不同產品。

樂器庫建立之後，更困難的問題就出現了：樂器庫不會自己組合起來。原本的直覺做法會是建一個資料夾，裡面放滿罐頭式的音效素材，讓每個建構案都從同一堆裡拿——而我們刻意沒有這樣做。負責設定一個建構案配色方案的設計總監說明文件，同樣也設定了它的音效調色盤，因此組合過程是按每個遊戲個別進行的——一款黑色電影風格的偵探遊戲和一款農場模擬遊戲，不會拿到同一套樂器組合，就像它們不會用同一套字體一樣。音效的擺放邏輯也一路貫徹到每一個個別物件：這是什麼物件、它撞擊的是什麼表面、它有多大、場景是什麼氛圍。這跟我們對一個精靈圖或一段介面文案所堅持的細緻程度是一樣的，只是應用在一個人們習慣視為次要考量的環節上。

而正因為「次要考量」正是音效退化的根源，我們並沒有把它留作一項只能寄望能撐過死線的風格指南。它現在是驗證流程的一部分——成品上架前執行的瀏覽器內檢查會實際聆聽它，任何靜音的世界音層，或是因取樣載入失敗而悄悄退回到單純振盪器音的音效，都會像壞掉的按鈕一樣無法通過檢查。這不是寫在審查文件裡的一條備註，而是一個缺陷。不久前我們自己的一個建構案就因為這個原因被標記出來並自動修復；這個檢查機制的運作細節，請見建構案如何自我驗證。